CodeReviews Using SlickEdit Tools

The guys at SlickEdit make a great set of tools for devs, both standalone and VS plugins.  Scott Hackett wrote a really interesting post on using SlickEdit to do a code review.  It's a pretty good read and shows a nice way to use the tools to help narrow down who wrote what code.

There are a number of ways to skin the code review cat; this is a nice option and worth the read.

(Reminder disclaimer: I got SlickEdit tools for free because they advertise on The Lounge.  I wrote about my thoughts on SlickEdit in an earlier post.)

Virtual Server Admin Page Error 400

Problem: The Virtual Server admin page (:1024/VirtualServer/VSWebApp.exe">http://<hostname>:1024/VirtualServer/VSWebApp.exe?) on a multi-homed host system isn't accessible if one network card goes down.  You get lovely HTTP Error 400 pages.

Solution:  Check that the IIS Virtual Server site isn't bound to one specific network adapter.  IIS manager -> Web Sites -> Virtual Server -> Properties ->IP Address.  You can bind the site to one specific IP address, or simply select "(All Unassigned)" in which case you're not dependent on one NIC.

Yay.

404.3 Errors for WCF Services

Today I ran into 404.3 errors when trying to hit a .svc file on my recently re-imaged system.  I beat my head against my console chasing IIS setup configuration, directory rights, and a number of other things.

Finally I ran across David Waddleton's post detailing a solution.  Whew.  Back moving forward again.

Culture, Productivity, Environment

I'm re-reading a few of my favorite older blog posts and reading a few new ones.  A couple great articles are worth passing on links to:

• Steve McConnell's Measuring Productivity of Individual Programmers.  Avoid stupidity like lines of code, and don't focus on just one measurement.
• Steve McConnell's How to Scale Up Quickly. Offshoring doesn't work, keeping the quality is terribly difficult, keeping the culture even harder.
• Joel Spolskey's The 12 Steps to Better Code.  Way back in 2000, just after Al Gore invented and implemented the Internet, Joel wrote a nice post on things some folks were already discussing.  Critical things for you and your team.
• Scott Hanselman's Sharpen the Saw for Developers. Getting management support for ongoing training at a consulting company can be like pulling teeth.  With a tow cable.  Look to Scott's post for some good ideas he's invented and consolidated from other places.
• All of Sara Ford's Tip of the Day and Did you know... series.  I read 'em all again just now.  No, really.
• Josh Holmes's series on good presentations.

There you go.  Just a few of my favorites.

Book Review: C# In Depth

C# in Depth by Jon Skeet, pub. Manning Press, ISBN 1933988363.

This book is a tremendous work for understanding how the most important features of the C# language work.  Skeet's been a prolific poster in the C# forums on MSDN for some years now, providing answers, tips and tricks, and in-depth advice to a large number of forum visitors.  This book wraps up his great knowledge of the inner workings of C# and hands it over to readers in a well-written, concise, usable book.

Skeet uses a very nice formula for the features of C# 2 and 3: he starts with demonstrating solutions to practical problems in C# 1 then shows the progression of that same solution through C# 2 and C# 3.  His walk through of the evolution of delegates through 1, 2, and 3 is a perfect example of this: start with the very wordy, somewhat clunky handling in C# 1 and end up with C# 3's lamba expressions.

One of the many fine things about this book is Skeet's ability to clearly cover complex topics like Lambdas and expression trees at exactly the right level.  Readers will be able to pick up the power, complexity, and benefits of language features because Skeet's kept the examples practical and the text conversational.  With potentially complex topics it's too easy for authors to fall into trivial examples, or dive into overly academic discussions; Skeet does neither.  He also does a terrific job of covering the cons of particular issues -- something I'm a big fan of since it helps me make informed decisions.

Part of the book's success is Skeet's solid focus on the book's topics.  He stays directed on to language features and doesn't digress into software engineering or construction.  As a result, in roughly 360 concise pages he's able to hit all the major goodies like generics, delegates/lambdas, nullable types, extension methods, and LINQ.  He closes the book with a nicely laid out, thoughtful discussion of C# 3's benefits and its possible future.

This is a great book for understanding how some of the more fundamental features of C# are implemented, and how to best use them.  This book definitely belongs on your bookshelf, right next to Bill Wagner's Effective C# and More Effective C# .

(I'd love to see Wagner and Skeet in a room full of VB6 programmers, diving into a deep discussion of anonymous methods, expression trees, and lambdas.  Watching all the VB6ers heads explode would be great entertainment.)

Test Execution Problem in VS2008

A nasty bug slipped through the cracks in VS2008's test execution engine.  The problem is rooted in the whole test deployment concept in Visual Studio 2005 and 2008 where all assemblies are copied to a folder underneath the TestResults folder, then executed from there. 

I think this is a silly, overly complex way to execute tests, and it's particularly a problem in VS2008 because the test runner doesn't execute with that folder as its base path.  A bug in VS2008 causes the AppDomain.CurrentDomain.BaseDirectory property to be set to C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE instead of the proper subfolder under TestResults.

There's some good detail and a possible fix in this MSDN post.  Unfortunately, this doesn't work in my environment because the resolver's assembly path property value ("Public Assemblies;Private Assemblies") also gets appended to the path, further borking things up for me.

I'm moderately narked about the bug with the BaseDirectory slipping through, but I can understand it.  Bugs happen, they get fixed.  Hopefully there's a workaround for the bug while a real fix is being created.

I'm more narked about the underlying decision to have tests run from a location different than the project's build directory.  The overall concept is brittle and has too many moving parts.  I have to fool around with DeploymentItem attributes in code, I have to fool around with Deployment Item settings in the test configuration.

The idea of a TestResults folder is great if it were limited to, like, holding results. Reports, working files, etc., would all be appropriate for that folder.  Copying all the binary bits and test support files to that folder, then running everything from that target isn't the way a real unit test framework would do it.

Unfortunately, this bug is a complete show-stopper for me because I can't work around it.  The specific issue for my current project, based on VS2005, is a crapload of tests reliant on our NHibernate infrastructure.  NHibernate's Cfg.Configure() command, invoked with no parameters, attempts to load the hibernate.cfg.xml file from the current folder of execution.  Sure, you can specify a directory path to load that file from, but I'd have to do significant amounts of code ugliness to alter that input path based on production, test, dev environments.

I'm waiting on more help from Microsoft on this bug, but for now it means we can't proceed with moving up to VS2008 for this phase of the project.  I'm bummed.

VS2005 -> VS2008 Conversion Wizard Runs Every Time

I'm working through a few minor nits with a moderately sized solution (23 projects) that I've just converted from VS2005 to VS2008.  One nit is the conversion wizard runs every time I open the solution.  Irritating.

Answer found after trolling through some MSDN posts: Test projects appear to have a few hitches during the conversion process, one of which is the FileUpgradeFlags element in the .csproj file failing to properly update.  This causes the wizard to re-run every time you open the solution containing the project.

To fix, find the element <FileUpgradeFlags>.  It will probably look like

<FileUpgradeFlags>0</FileUpgradeFlags>

Remove the zero in the element content, leaving an empty element:

<FileUpgradeFlags></FileUpgradeFlags>

Do this for every test project in your solution.  Save 'em all, re-open the solution and you should see no conversion wizard.  Yay!

(Original MSDN post here.)

Now if I could just get MS Test to play nicely with my hibernate.cfg.xml files in the MS Test deployed location.  I continue to search for a rational explanation of why MS Test insists on copying all binaries to a location separate from the build location in order to run its tests, forcing you to deal with "DeploymentItem" attributes and test configuration shenanigans.  I've run in to a number of PITA issues with this separate-but-equal concept, and I'm having a hard time understanding the reasoning for creating a second environment that's not treated the same as the solutions' build environment.  Brittle, complex, and more moving parts than necessary.

Yet another reason for preferring MBUnit for a test framework that helps, not hinders, all the testing I like to do.

Shout Out: More Effective C# Rough Cuts Available

Bill Wagner's Effective C# is one of the books you absolutely need to have living on your bookshelf if you're working in .NET. Bill's book is crucial to understanding how certain things in .NET and C# work, and it's full of great examples on why you need to do things in a particular fashion.  He goes in to exactly the right level of detail to make you understand things like the as/is keywords, and why you really need to think hard about how to implement equality checking.

Effective C# covered C# 1 with just a nod to 2.0, so it's good to hear Bill's nearing completion of his work More Effective C#, updated for all the goodness of C# 2.0 and 3.0.  You can pre-order through Amazon, and it's also available on Rough Cuts where you can get read the chapters as they're going through the editing process.

I'm really looking forward to getting a copy of this when the dead tree version comes out in November.  (Hey, maybe a birthday present for myself!)

Meme: How I Got Started Programming

Tim whacked me with his post, so here goes.

How old were you when you started programming?

High school, 1979.  Age of 16 or so.  Radio Shack TRS-80 with a cassette tape drive for its storage.  Not quite punch cards, but damned close.  A buddy whose parents had gobs of money bought him one. (A tape drive, for cryin' out loud!  They must have been rich!)  He and I were in a D&D group together, so naturally a geeky computer attracted us.

How did you get started in programming?

I went enlisted in the Air Force in the general electronics field.  I could have ended up stringing telephone cables, but got lucky and landed a position in school for repairing massive aircraft radar systems.  I got even luckier by landing a slot for doing inflight repair, fulfilling a dream of flying I'd had since I was a kid and my dad used to take me out flying over rice fields in central California.  I digress.  At tech school in Biloxi, Mississippi, I got the chance to start programming 6502 processors using octal assembly code.  A complete PITA, but it rekindled the interest I'd found from the TRS-80 years earlier.

I got my first real computer a year or so later when I hocked the new aluminum wheels on my '67 convertible Camaro in order to buy an Apple //e computer complete with 32K of memory and a 64K video card.  Man, that was the cat's ass!  (I see Wingfield had a 128K expansion card.  He must have been living the high life, I tell you.)

I progressed to dropping in a Non-Maskable Interrupt card so I could hack into various wargames that were kicking my then bony ass.  I eventually did such crazy stuff like soldering together EPROMs onto a single socket with a DIP switch so I could toggle between the //e and ][+ BIOS sets.  I hung around a guy who wrote a voice driver for his modem to have his computer call up folks at random times, say "Asshole", and hang up.  Somewhere along the line I wrote some code that manually moved my 5.25" floppy drive's head around.

That interest slowly progressed as I was posted to Anchorage, Alaska, where I bought a 286 system from Radio Shack and started fooling around with Borland Turbo Pascal, then Turbo C++.  I eventually bought a generic 386 system from some company that went out of business the week after I bought the box.  So much for tech support.

The Air Force was kind enough to pay for 75% of my schooling while I was active duty, so I started taking night school courses at a branch of  Chapman University (then just "College").  I hit Pascal, more assembler, threw up through one Cobol course, and did some C++.

All that was just some background until I left the Air Force, wandered 'bout for a number of years, and eventually worked my way into cutting code for a living.  More or less.

What was your first language?

Whatever the variant of BASIC on that TRS-80.

What was the first real program you wrote?

Tough to nail that one down.  I remember starting one on the TRS-80 which was supposed to compute catapult damage to a castle wall (D&D, remember?), but I can't remember if we finished it.  Most likely it was some octal exercise on the 6502 in tech school.

What languages have you used since you started programming?

Surprisingly, not as many as some others: BASIC, AppleSoft BASIC, Pascal, Cobol, Assembly on a number of different procs, C++, Perl, Java, C#.  Suffered through Lisp just enough to be able to configure JDEE when I was doing Java work.

What was your first professional programming gig?

I did some writing of Perl modules for managing servers and accounts when I was a network admin, but that's utils, not cutting code.  My first "real" programming gig was as part of a team working on tools to convert SGML to HTML and XML.  (Yes, kiddies, let old fart Jim tell you about when you needed a PhD to understand stupid markup made when single characters counted so everything was implicit, not explicit.  Try figuring out an implied element closing when you're five layers deep.  Obviously I'm still scarred.) 

I only wrote code around the edges of that, so maybe maybe my first gig was actually writing tools to strip out metadata from DTED terrain data files and stuff all that in a database for use by a really cool system designed to figure out where bad guys hide so you can more easily find them and blow them up.  I wrote some code around the edges of that one, too, as well as built tools to create database schemas in Sybase 11 and Oracle 7 for the system's underlying datastores.

If you knew then what you know now, would you have started programming?

Hell yes!  I love what I do!  I wish I could have done more of this over the years, but I've had a somewhat eclectic career due to following my wife around for her military assignments.  (Germany, Alaska, Washington DC.  It's not been bad...)

If there is one thing you learned along the way that you would tell new developers, what would it be?

Learn to learn, don't just learn technology.  What you knew five years ago is laughable now, and what you knew last year likely isn't a higher on the scale.

One more thing: Learn to have the confidence to say 1) "I don't know" and 2) "Man, that code I wrote last year/last week/this morning really sucks.  But I've learned how to write better code, so I'll do better." 

#1's never been a factor for me because I follow with "But I can find out.". 

#2 has only just started to get somewhat easier after reading blogs or hearing podcasts from folks like Atwood, Ching, Miller, Haack, and a bunch of other industry leaders.  If those guys can be up front about their weaknesses then why should the rest of us not be?

What's the most fun you've ever had ... programming?

I'm torn between two things.  First off, watching the head of a hard drive move back and forth as you're stepping through some driver code you've written really is cool.  SOOO much of what we do is nebulous, which I think is part of the reason we like writing unit tests: a green indicator comes on.  Seeing your code make something physically move  is just plain wicked cool.  That bit of fun was, uh, many years ago but I still remember it vividly.  (I also remember having to repair the armature after some bad code...)

The second bit of fun would be a space of a couple months after I'd joined Quick Solutions last year.  I came on board with the expectation from my boss that I'd quickly jump into a leadership role and help drive business, lead teams, write offerings, etc.  But... for my first couple months I just got to sit my kiester in a chair and code.  It had been YEARS since I'd been able to have no responsibilities but write tests, write code, geek out with other smart folks.  One of the most refreshing times of my life, and exactly what I needed after coming out of a less than optimal situation.

Passing on the love (or, tag, you're it)

Jason Haley

Ben Carey

Drew Robbins

Leon Gersing

Dave Donaldson

Shout Out: XNA and Robotics Studio Event, 19 June in Cincy

Mike Wood and the gang at the Cincinnati .NET User Group are putting on an XNA and Robotics Studio event on 19 June at 6pm.  The event will be presented by Microsoft's Bill Steele. 

Bill, if you don't know him, is a certifiable nut who does all sorts of crazy things like run MSDN events in the Heartland region, play around with Robotics Studio, write games in XNA, and has invented a system for displaying small aircraft's flight information on the virtual surface created by the spinning propeller blades.

Seriously, Bill's a wicked smart, passionate guy who will definitely entertain and educate you.  Make it a point to stop by on the 19th if you're at all interested!

Playing with SlickEdit

The folks at SlickEdit provided copies of their cool Visual Studio tools to folks like myself who are members of The Lounge.

Being a tool geek I couldn't resist installing it and fooling around a bit.  I've not spent a whole lot of time with the tools, but have already found some cool bits.  The window below shows a cool documentation preview in MSDN style, a nice compliment to what I get from ReSharper's Ctrl-Q.  There's also a nice regex evaluator which can generate code for you to paste in as needed.

The "Quick Profiling" bits require you to get some trace handling in your code, so I'm not sure how far I'll go with that, but it may be an interesting thing to experiment around with.

There's also a very nice comparison tool as part of the Versioning Toolbox.  There's some interesting visual sugar for version graphs, history, and visualizations.  The graphs are pretty cool, and the list of providers is very competent: SVN, CVS, TFS 2005/2008, and VSS (barf).

Perhaps one of the best widgets in the versioning toolbox is the DIFFzilla window:

This is nearly as good as my favorite comparison tool Beyond Compare 2.  Love that directory compare feature, and you can quickly get file comparisons by double-clicking a set of the files in this window.

Overall I like what I see so far.  While I've got access to other tools which fit a lot of these needs, it's really nice to have all this wrapped inside Visual Studio.