Overly Large Solutions

There's been some interesting discussion on having too much in your App_Code folder as well as dealing with solutions holding large numbers of projects.  I find it pretty amusing that some folks are complaining about performance in Visual Studio when they're working in solutions containing 50 to 70 projects.

50 to 70 projects?  That's Just Plain Bad for any number of reasons.  First, you're definitely degrading your build times in Visual Studio.  Secondly, you're probably killing your performance in Visual Studio as Guthrie mentions in his post.

More important is the impact on your ability to keep your head wrapped around what's going on with your code.  My initial query to folks running solutions with that many projects in them runs along the lines of "What the hell are you thinking?!?"  It's nuts to have that many projects wrapped in to one solution.  How in the world are you going to be able to wade through all that code and keep everything straight?

Do yourself a favor and look hard at breaking out chunks of those projects into sensible blocks of separate solutions.  Worried about dependencies between components you've broken out into different solutions?  Use NAnt or MSBuild to manage your build process and keep all those dependencies straight.  (You ought to be using one of those anyway, especially for larger systems!)

Sure, there are edge cases where something really funky might force you to work with a silly number of solutions in one project -- but those are few and far between.  Do your work up front and think how such a massive system should be laid out.  Do your refactoring as you work and move out logical chunks of functionality to external libraries.

Your life will be much simpler and you'll have better performance in your development environment.

Book Review: Effective Use of Enterprise Library

I haven’t made it all the way through this book, but thought I’d go ahead and scratch out a quick review on it anyway.

Effective Use of Microsoft Enterprise Library by Len Fenster.  Addison-Wesley, 2006, ISBN 0321334213.

This book covers the June, 2005 release of Enterprise Library, but it’s still a worthwhile read.  It’s concise and clearly written, and it’s well-structured with each chapter laying out the background, design, and usage of a particular library block such as Configuration, Data, or Logging.  The examples are in both C# and Visual Basic, and the examples are to the point and usable instead of some throw-away, unrealistic snippet.

Fenster does a nice job of talking about the configuration advantages of EL blocks, such as the ability to define your logging in code, yet have an administrator use configuration files to control how and where logs are actually handled.

I’ve found this book a solid intro to Enterprise Library, even though it’s already outdated.  It’s a good starting point for reading before jumping into the docs for the latest release of EL.

Tell Me Again How Firefox is More Secure?

Via Slashdot, an interesting article on the number of security vulnerabilities in Firefox and Internet Explorer.  I luvs me Firefox, but have never, ever bought the argument that it's a much more secure browser than IE.  Firefox is great stuff, but its marketshare, and corresponding exposure to hackers, has been much smaller than IE's.

As usual, the commentary from ABM (Anything But Microsoft) folks in the /. community is pretty hysterical.  There are an amazing amount of excuses for Firefox's numbers in the Symantec study.  Dudes, be honest about your (and my) browser of choice: it's a great tool, but it's not some Holy Grail or universal panacea.

Good SharePoint 2007 Tech Refresh Resources

Keeping up with patches and updates to beta software can be a PITA, particularly when a lot of different products are wrapped around each other like Microsoft Office SharePoint Server (MOSS), Windows Workflow, etc. are.

The Tech Refresh for MOSS was released a week or two ago.  Installing it can be a bit tricky, but the SharePoint Team Blog has a great list of resources, including walk-throughs of the install process complete with screenshots.  Useful stuff!

Working Through iPod Woes

My iPod has been crapped out for several months and I’ve not taken time to try and get it running.  It won’t update, the Updater’s Restore function bugs out, and life is generally unhappy.

SpinRite is a killer disk tool for non-destructive, hard-core disk repair.  I’ve used it since something like its version 2.0 back in 1990.  It’s time-consuming, but it’s recovered data from drives I was certain were dead, and it’s ressurected drives I was certain were bound for the waste basket.

Unfortunately I’ve had bumpkis for luck trying to get it to run on the iPod via USB.  I’ve gotten boot disks built to recognize the iPod via USB, but SpinRite barfs and hangs despite my best efforts at tweaking CONFIG.SYS file settings.  (Man, it’s been a long time since I’ve done that!)

I’ve got a couple nifty adapters on the way to let me hook my iPod’s drive to an IDE connector, so I’m hoping that will let me get this thing back in working order!  I’ve got lots of road time back and forth from Cincinnati for work, so I’m desperate for some nice podcasts to listen to.  (Not to mention my cuts for The Black Keys, Longwave, Molly Hatchet, Prokofiev, and Gordon McRae, among others)

I knew there was a secret disk diagnostics menu around, but never could find it until I stumbled across this post at Command-Tab.com where I also found great info on the adapters for hooking up the iPod’s disk to my computer. 

Hopefully I’ll get this little beast back in working order quickly!

Book Review: Visual Studio 2005 Unleashed

Visual Studio 2005 Unleashed by Lars Powers and Mike Snell (Sams, 2006, ISBN 0672328194)

This is a pretty impressive book, albeit a bit lengthier than it needed to be.  There's tremendous coverage of everything, and I mean everything, in Visual Studio 2005.  If you're new to VS 2005 then you'll find this a great guide to getting the most out of your environment.  If you're fairly familiar with VS 2005 then you may still find a few goodies hidden away here too.

One thing I didn't care for the was the large amount of material that would have been better summarized or flat out omitted.  Did I really need pages and pages of screenshots of each and every menu in Visual Studio?  Probably not.  Did I really need to see six pages listing a single project file, with little discussion on the details of it, or three pages of code auto-generated by the forms designer?  Probably not.  There's a lot of this kind of stuff, but in reality it's an annoyance and not a fatal flaw.  ("Dude, didn't you just finish writing a book 1300 pages long?" Uh, let's leave that off for now, eh?)

What you'll find in the book is a wealth of details on useful stuff like moving around your document with bookmarks, getting the most from VS2005's search capabilities, or how to best use features like the XML editor -- which is discussed in great depth with examples in the Data View and Schema editor.  The book's smattered throughout with useful tips on avoiding gotchas, such as dealing with issues in the Refactoring's Promote command.

Several of the chapters, such as the ones on VS's Automation Object Model and Writing Macros, left me a bit underwhelmed; however, the majority of chapters give great value.  The chapter on Refactoring, in particular, is a terrific walkthough with great examples.  The chapter on Debugging is another good walkthrough, with a nice discussion of setting up for debugging a modestly complex scenario of a web application.

The sections on Team System features are a nice introdocution to getting the most out of the three VSTS products (Architect, Developer, Tester).  There's also solid coverage of working with issue tracking, VSTS's source control, and dealing with VSTS projects.  The information here is from the basic useage viewpoint, so you'll need something like Guckenheimer's Software Engineering with Visual Studio Team System to get the most out of VSTS.

Overall this is a solid book that's very useful introduction for novices and intermediate VS2005 users.

I've Written Another MbUnit Piece

The Greater Dayton IT Alliance is a great resource trying to boost the Dayton-region's IT base.  They do a lot of great things in the region and have been a great help for our .NET DevGroup here in Dayton.

They also put out a monthly newsletter with business and tech-related articles.  I wrote an article on reducing unit test complexity via MbUnit for this month's newsletter. 

I think I did a good job on the article, but made one of my most-hated grammar errors and used "it's" as a possessive instead of "its."  Feh.

Changing Jobs? Evaluate Where You're At (And Fix It!)

Over the last week I've been doing a lot of interviewing of potential candidates (yes, while I was sick -- but via the phone) for some of the open slots we've got with NuSoft in our Cincinnati office.  The task has made me reflect on the journey I've been taking over the last couple years as I set out to get back into fun stuff like development instead of the QC, customer relations management, and project management roles I'd been in.

Several years ago I decided I wanted out of that line of work, but I had to take a hard look at my skillset and fess up that, well, it sucked.  Furthermore, the environment I was in offered few opportunities for me to instigate a sea change in what I was doing and how the folks I worked with were doing their development.  I knew I needed to start getting some facts and cases together, so I began exploring new things by doing a great amount of reading.

That reading led me to discover a wealth of new horizons, all of which were completely unknown in the environment I was working in.  Test Driven Development?  The guys I was working around weren't even writitng unit tests and had no clue what any of the xUnit frameworks were. (Nor were they overly interested.)  Agile or lean development?  I was in a horrid, process-bound environment that valued production of mountains of documentation more than production of solid code -- one of the hazards of having to deal with department of defense agencies.

All of this reading kicked me in the butt.  I was letting others have far too much control over what I was able to do with my skills.  You are the one who controls your life, and you have control over what you can do to better position yourself as you look around for an escape from the environment you're currently in.

Suggestion one: Your skills suck?  Get reading (books).  Do the folks around you not care about quality development?  You're in a lousy place and you need to get yourself out of there, but you'll need to get yourself exposed to some critical works on writing good code like McConnell's Code Complete, Kernighan and Pike's Practice of Programming, and Maguire's Writing Solid Code.

One of the best guides I found was the career ladder at Steve McConnell's company Construx (registration required).  This is an old version, but the works listed there are gold, absolute gold, and can get you pointed to many other works as well.

Don't leave off at writing solid code.  Continue your reading by hitting some of the great works on methodologies: Beck's Extreme Programming, Subramaniam's Practices of an Agile Programmer, and Beck's Test Driven Development or Newkirk's version in the .NET world.  Learn how to change your development practices, even if the folks around you can't or won't.

Suggestion two: Your skills suck?  Get reading (blogs).  You're already here so at least you know what a blog is.  You're wasting time if you're not using an RSS reader/aggregator, so go look at something like Omea, Bloglines, or any of the other tools.

Use your time in blogs wisely.  Think hard about forcing yourself to do an end-of-month purge of your blogroll: cut one or two every month, forcing yourself to keep only the cream.

Suggestion three: Your skills suck?  Get involved.  Find a user group in the technology you're interested in.  You'll be surrounded by other folks who are passionate and interested in good software.  You'll (hopefully) get great presentations tossed at you to spark your interest in learning even more.

No good user groups around you?  Start one.  I started the Dayton .NET Developers Group because I got tired of driving over to Columbus to hit the Central Ohio .NET group. 

You need some additional motivation to keep increasing your skills?  Run a User Group and stand in front of a group of folks once a month.  There's no better motivation to boost your skills than the motivation to avoid showing your ass...

Suggestion four: Your skills suck?  Get developing.  You can't get your management team to buy off on moving to newer technologies?  Well, they may not see the value proposition in that, and that's certainly their perogative.  But you need something to cut your teeth on to help you boost your skills.

Go find a great open source project like MbUnit, NUnit, NAnt, TortoiseSVN, or any of the many other great tools around.  Grab the source code and start digging through it.  Learn how Really Smart Folks like Charlie Poole write code.  Take the next step: join the development team and see if you can't start out helping knock off some low-hanging fruit.  Can't do complex stuff?  Maybe you can do smaller tasks that let the more experienced folks focus on that complex stuff.

You'll be learning, and you'll be boosting your resume with some good work.

Suggestion five: Your skills suck?  Get writing (or presenting).  I'm a firm believer in the adage that you don't really know something until you can teach it to someone else. 

Start a blog.  Write about some tech geeky thing that interests you.  Write about how you're solving problems on the open source stuff you're helping develop.  Write about what you're learning.

Write an article.  I was lucky enough to hook up with James who invited me to start writing pieces for his VisualStudioHacks.com site.  Find your own places to submit articles to.  Code Project, O'Reilly's various sites, any number of other places.  Who knows what will happen?  Maybe you'll get lucky like I did and fall into a serious writing project.

Want to really learn the guts of something?  Develop a 60 - 90 minute presentation around it, complete with good technical demonstrations.  Give that at a User Group and answer the questions that pop up about your talk.  Showing others requires you to have your stuff seriously together!

Suggestion six (the last!): Your skills suck?  Get real.  Take the long view, set priorities, and set goals. 

My skillset dropped because my wife and I decided our priority was to have me home with my daughter instead of in an office cutting code ten hours a day while my wife travelled extensively for her job.  That would have meant my daughter would have been in way too much daycare for our tastes.  Because of that I had to take positions I wouldn't have otherwise.  Some of them weren't exactly what I wanted to be doing, but I've found they've given me a great breadth of experience in everything from extensive writing to project management to estimation.  I spent a lot of time in front of customers which has turned out to be invaluable.

Keep your priorities straight.  Maybe life won't let you make a change right now, but you can certainly start building your foundation so that you'll be ready when life lets you.

Keep your goals set, and within reach.  Dreams are great, but goals are what let you reach those dreams.  Set goals for finishing books.  Set goals for learning bits of technology.  Set goals for certification tests.  ("Hey Jim, how's that MCSD coming along?"  Uh, we'll talk later.)

In Closing...

All this has been bouncing around in my head for quite some time; long before I started my new job.  I hope I've managed to convey a few important bits and pieces in this post.

You've got to take matters into your own hands if you're going to break out of whatever rut you're currently in.

I'll turn off the Doctor Phil mode now...

Despite Rumors To The Contrary, I Am Still Here

Yeesh, it's been over a week since I've blogged.  I've never had that kind of gap unless I was on vacation.

I get a bit of a pass, though, due to an absolutely hideous flu bug that knocked me on my proverbial and literal ass for five days.  I've never been konked like that, ever.   Chills, sweats, splitting headache (and I'm a vetran of migranes, so I know bad headaches), and a cough so bad I strained an eye muscle and my abs.  (OK, straining my abs isn't much considering the shape they're in...)  A tough way to lose eight pounds over a weekend.

Thankfully I'm back in good shape now except for a bit of the cough remains.

I'm in good enough shape that I'm finally busting out on a development project at work.  Whoopeee!  There wasn't really any guidance on how to head off with unit testing, so I chose my own toys and am getting to play more with MbUnit, my framework d'jour. 

I'm also going to be making use of dotTrace from the wicked smart folks at JetBrains, my first foray into that product.  I'm looking forward to playing around with it and learning its ins and outs.

Other nice toys I'm getting good use of:

• Jeffrey Palermo's article "Bread and Butter Resharper", a killer guide to real-world use of ReSharper.
• Scott Bellware's fine Code Snippets for NUnit.  Shhh.... They work just fine for many MbUnit chores.
• GVim.  Can't stop the signal.  Vim Rulz.
• Sql Server Management Studio.  I'm finding more and more nice things for working in this.  Nothing earth-shattering, just nice stuff.

Serious Goodness on Testing, Coverage, Assertions, and Llamas

Eric Sink has a terrific article on unit testing and code coverage.  He nicely talks about the tools he uses, how he got a particular library project to 100% coverage, and why that's a good idea in some cases and not so good in others.

His section on using assertions is a particularly good read.  Assertions make good sense in a number of cases and Sink does a nice job of pointing out where.  (Lowy's Programming .NET Components, 2nd ed. lays out good info on that, as does the much older and still useful Writing Solid Code from Maguire.)

Sink's article also hits a couple good points: regression testing and why 100% code coverage isn't a panacea.  You still need good tests.

Check it out.  Like almost everything else he writes, this article's a good read.

(Actually, there are no llamas mentioned in Eric's article.  He's not hung up on them like this guy.)

Updated:  Fixed missing link to Eric’s article.  Ooops.  Sorry!

A Different Schedule These Days

Just a few months ago my daily schedule mostly looked like this.  Now that I’m employed it looks a lot like this:

Soon there will be more blocks in there title something like “Heads Down Coding” which will be very nifty.

I’m busy, I’m working, I’m talking to Big People instead of my kids (who I still get to see plenty), and I’m working with a lot of wicked smart folks.

It’s a nice change after six years of trying to juggle part-time work and playing Mr. Mom.

Dayton DevGroup: Important September Meeting News!

The Dayton .NET Developers Group has an off-schedule meeting this month.  We're meeting next Thursday, September 14th, at 6pm.

Critical Info: We're meeting at Max Training's Miamisburg facility, not our usual New Horizons location. This isn't a permanent move, just a temporary one.

Please make sure to let your friends, colleagues, and other members know about the oddball schedule and location.

The one-time upheaval is worth it: we've got Julie Lerman, a great INETA speaker, coming to talk about web services security.

Make sure to show up if you're in the Dayton region and are interested in great .NET content!

Outlook 2007 Add-Ins and Crashes

It looks like the SnagIt add-in for Outlook doesn't play nicely with Outlook 2007 -- I was having constant crashes when trying to open Calendar entries.  That stinks.  Acrobat 6 may also cause problems.

Unfortunately, it appears that Microsoft has left add-in management out of Outlook 2007.  The only way to disable misbehaving add-ins is hack the registry.  Open RegEdit and browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins\SnagItOfficeAddin.Connect.  Set the LoadBehavior key value to 0.

Things seem to be behaving a bit more nicely now.

(Hat tip: Slipstick.com.)

Thursday is an Ugly Day (Politics)

My blog's had a higher-than-usual ratio of politicial odds and ends lately, but there have been a lot of things finding their way under my skin.  (Plus, quite frankly, I've been so swamped with work and recovery from my book that I've not had the energy to post much technical stuff...)

In particular, this Thursday marks an unprecedented day for free speech in our nation.  Thanks to John McCain and Russ Feingold all broadcast advertising critical of any candidate for federal office will be whisked off the air and blocked until after the election. 

McCain-Feingold is nothing more than a blatant incumbent protection act, and I couldn't care less what McCain's intentions were.  He was an honorable man during his service and captivity, but his political life has been full of junk like this bill and his episode as one of the Keating Five.  (Forgot about that, perhaps?)

I know that many campaign ads are ugly and distorted, but if you can't understand the hit your first amendment rights have taken because of McCain-Feingold then I encourage you to spend a bit of time in reflection or research.

Interesting commentary from an active duty Army guy, some funky UML guy with a Tablet, and another guy with a scathing pen.

Book Review: Managing Agile Projects

Managing Agile Projects by Sanjiv Augustine.  Prentice Hall PTR, 2006, ISBN 0131240714.

This is a solid book, but suffers from a very slow start. The first quarter of the book seems filled with too much mystical hand waving and too many buzzwords. The entire opening quarter of the book is stuffed with referenecs to "chordic edges" and "holographic formal structures." A few of the buzzwords get defined and used later on, but the overabundance of them was like fingers on a chalkboard. It got so bad that I almost put the book down and walked away from it.

There are also a few irritants such as charts with poor explanations, or the assertion that test-driven development is an approach "specific to XP." Much of the book is from a pure XP approach, but that's not surprising because the author's been in a full XP environment for five years.  That part wasn't bothersome.

Things pick up greatly after chapter 3, however. The remainder of the book is solid, very useful, and full of great information for building and maintaining a solid development team. There's a lot of great focus on bringing value to the customer, and there are practical examples for all of the various aspects of running an agile project.

I liked the author's breakdown of categories into leadership and management roles.  The two aren't the same, and I get irritated with books which treat them as such.  There's also a good bit of focus on what's necessary to help keep teams and the individuals making up those teams in good working order.

You'll find handy tables and explanations detailing estimation, task backlogs and job jars, and several great discussions on how to keep communication flowing with your customer. The sections on clearly establishing service criteria at the start of the project, and the clever use of sliders to help define success critieria, were nicely done.

Overall it's a very good book. The opening three or four chapters drag down what's otherwise a solid addition to my bookshelf. I'll get a good amount of use out of the book as a reference for future projects.

Multiple Monitors, Multiple Systems

I’ve got four systems hooked together through a Belkin KVM switch (fair at best, BTW), and I’m actually able to get two of them in a dual-screen setup.  The middle screen is the one shared via the KVM switch.  My main dev box, one I built last year when I started Iterative Rose, ties the middle and left monitors together.  My nice laptop from NuSoft is on the right and is tied with the middle monitor.  That setup isn’t the best since resolutions differ, but it’s a lot better than a single monitor!

Yes, yes, my workplace setup sucks, but sometimes you just have to put up with lousy stuff for the short-term.  (OK, “short-term” has been the case for six years…)  The current workspace, as you can see, is a hodgepodge of hacks trying to keep it as ergonomically friendly as possible.  The entire setup is due for a replacement in a month or so, and the new setup is going to be seriously cool.

Thumbing One's Nose at Read-Only PDF Forms

Hah!  I scoff at the asinine folks at the Ohio Secretary of State's office who made their PDF form for Articles of Incorporation a read-only form.  Who the heck thinks it's useful to create such a form, then disallow saving of it? 

Frankly, I think it's another one of Ken Blackwell's rotten decisions, which is among the reasons I won't vote for him come the Govenor's election in November.  (Yes, I'm absolutely sure he personally came into the SOS office, right after repressing Democratic voters across the state in the 2004 election, and said "Hey, I really dislike that Holmes guy over in the Dayton region.  Make this form read-only so he can't save all the effort he put into filling it out.")

OK, so maybe there are some reasons why PDF forms should be read-only, but I can't think of any right now

But back to the main point of my post: Foxit Reader is a killer replacement for Acrobat Reader.  Small, stable, free, and with lots of nice features like filling out text on plain ol' PDF forms.  The smart folks at Foxit have gone one better in their beta 2 version: you can fill out and save PDF forms which won't save in Acrobat Reader.

Three cheers for Foxit!

You can find v2.0.0609 on filehippo.com.

Clearing Out The Bookshelf

It's time to get rid of a few older, unused books from the shelf so I can make room for more books which will sit around, rarely used while they gather dust. 

Truth be told, I'm actually pretty good about keeping only books which I get some value out of on a regular basis.  I tend to keep two categories of books: long-term methodology-based books like DeMarco and Lister's Peopleware or MacGuire's Writing Solid Code, and short- to mid-term technology books like James's Visual Studio Hacks or Hiller's SharePoint.

The five books purged this round and headed for our library's book sale are:

• Friedl's Mastering Regular Expressions.  First edition -- I've had this great book for eight or nine years.  The only reason it's getting replaced is because I've gotten a copy of his just-released fourth edition.
• Learning Perl.  This hurt to pull off the shelf because I love Perl's simplicity and elegance.  Perl source code can also quickly get the appearance of garbled modem traffic.  (You young whippersnappers probably don't even know what modems were, you lucky saps.)  I haven't written any Perl in years, so it was time to go.  I may reapproach Perl again for its ease when writing website hacking tests.  (See Writing Secure Code, 2nd ed. for examples of that.)
• .NET Framework Essentials, 1st ed.  Outdated, time to go.
• C# Essentials, 1st. ed.  Ditto on this one.
• SGML for Dummies.  I despise the "for Dummies" series.  Why the hell do I want to buy a book whose cover insults me before I even open it up?  The few books in this series that I've browsed through all seemed vapid and shallow.  The only reason I bought this particular book was because I was less than intelligent on SGML and a colleague said he'd had good luck with this title.  Good intro, good info on SGML; however, I've been away from SGML for several years and won't be going back.  (I hope I hope I hope I hope.)

So that's my dirty laundry heading for the local library's used book sale.  Got any unused titles on your shelf you're willing to fess up to?