# Thursday, October 05, 2006
Someone asked me today if there was a way to test the default statement in this piece of code:

public enum AEnum
{
    One,
    Two,
    Three
}

public void DoStuff(AEnum e)
{
    switch (e)
    {
        case AEnum.One:
            Console.WriteLine("AEnum.One");
            break;

        case AEnum.Two:
            Console.WriteLine("AEnum.Two");
            break;

        case AEnum.Three:
            Console.WriteLine("AEnum.Three");
            break;

        default:
            throw new Exception("Unhandled enumeration value");
            break;
    }
}

Unfortunately I don't see any way to do it without changing the design to something very wrong and ugly like:

public void DoStuff(Enum e)
{
    AEnum ae = (AEnum)e;

    switch (ae)
    {
        case AEnum.One:
            Console.WriteLine("AEnum.One");
            break;

        case AEnum.Two:
            Console.WriteLine("AEnum.Two");
            break;

        case AEnum.Three:
            Console.WriteLine("AEnum.Three");
            break;

        default:
           
throw new Exception("Unhandled enumeration value");
            break;
    }
}




Thursday, October 05, 2006 4:50:25 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, October 04, 2006
Sometimes it's useful to debug third party libraries without actually building them locally.  For instance with NHibernate.  This may seem trivial, but I actually don't do it very often; hence I'm writing it down here.

Right click the Solution in Visual Studio's solution explorer, select property pages.  Under common properties select debug source files.  Add the root source code folder to the list (subfolders seem to be automatically included).  Ensure the PDB for the assembly your are debugging is in the bin folder you are running from.  Visual Studio should step right into the third party library now.

Wednesday, October 04, 2006 4:49:51 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, September 28, 2006
I'll have to add to this in the near future.  From Jeff Atwood: http://www.codinghorror.com/blog/archives/000666.html

  1. Every programmer shall have two monitors

    With the crashing prices of LCDs and the ubiquity of dual-output video cards, you'd be crazy to limit your developers to a single screen. The productivity benefits of doubling your desktop are well documented by now. If you want to maximize developer productivity, make sure each developer has two monitors.

  2. Every programmer shall have a fast PC

    Developers are required to run a lot of software to get their jobs done: development environments, database engines, web servers, virtual machines, and so forth. Running all this software requires a fast PC with lots of memory. The faster a developer's PC is, the faster they can cycle through debug and compile cycles. You'd be foolish to pay the extortionist prices for the extreme top of the current performance heap-- but always make sure you're buying near the top end. Outfit your developers with fast PCs that have lots of memory. Time spent staring at a progress bar is wasted time.

  3. Every programmer shall have their choice of mouse and keyboard

    In college, I ran a painting business. Every painter I hired had to buy their own brushes. This was one of the first things I learned. Throwing a standard brush at new painters didn't work. The "company" brushes were quickly neglected and degenerated into a state of disrepair. But painters who bought their own brushes took care of them. Painters who bought their own brushes learned to appreciate the difference between the professional $20 brush they owned and cheap disposable dollar store brushes. Having their own brush engendered a sense of enduring responsibility and craftsmanship. Programmers should have the same relationship with their mouse and keyboard-- they are the essential, workaday tools we use to practice our craft and should be treated as such.

  4. Every programmer shall have a comfortable chair

    Let's face it. We make our livings largely by sitting on our butts for 8 hours a day. Why not spend that 8 hours in a comfortable, well-designed chair? Give developers chairs that make sitting for 8 hours not just tolerable, but enjoyable. Sure, you hire developers primarily for their giant brains, but don't forget your developers' other assets.

  5. Every programmer shall have a fast internet connection

    Good programmers never write what they can steal. And the internet is the best conduit for stolen material ever invented. I'm all for books, but it's hard to imagine getting any work done without fast, responsive internet searches at my fingertips.

  6. Every programmer shall have quiet working conditions

    Programming requires focused mental concentration. Programmers cannot work effectively in an interrupt-driven environment. Make sure your working environment protects your programmers' flow state, otherwise they'll waste most of their time bouncing back and forth between distractions.


Thursday, September 28, 2006 5:24:01 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
Jeff Atwood pointed out a very interesting XP change diary by James Shore

"It was 2002. The .com bust was in full slump and work was hard to find. I had started my own small business as an independent consultant at the worst possible time: the end of 2000, right as the bubble popped. I had some noteworthy successes doing what I loved: coaching agile Extreme Programming (XP) teams in doing great work for a valuable purpose. And then the work dried up.

Eventually I admitted that I was going to have to find some "real" work to fill the gap. I took a contract job as a programmer on a team customizing some web software for a large institutional customer. This team was the opposite of agile. I was bored and frustrated. It didn't take me long to remember Martin Fowler's advice. As a peon, could I make the kinds of changes I made as a (damned good!) XP coach? Or would they kick me out, causing me to change organizations a little more abruptly?"


The full diary can be found here: http://www.jamesshore.com/Change-Diary/.  I highly recommend reading it, even if you aren't that interested in XP.

Thursday, September 28, 2006 5:20:14 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, September 27, 2006
After moving the CruiseControl.NET server to a virtual instance of Windows Server 2003, we've been having problems with NDoc hanging.  I've noticed previously that NDoc was apparently leaking memory thus forcing me to reboot the server every night.  I think it may be opportune time to swap out the alpha version of NDoc we've been using up to this point for Sandcastle, Microsoft's (beta) code documentation generator.

Wednesday, September 27, 2006 6:22:32 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Saturday, September 23, 2006

The idea was to make the autobuild system hardware independant, which I think we achieved, however I wonder if it was worth the extra effort. I think it will be beneficial in the long run since the build is dependant upon the following apps/tools which are not is source control: .NET 2.0, a local SQL Server 2005 instance, CruiseControl.NET, and Perforce.

So far I'm pretty impressed with Virtual Server, especially the ability to mount ISO images directly to the guest CD drive. I can't believe I haven't used VS before today.

The only strange issue we ran into was a "VMRC Negotiate Authentication" problem. Everytime we tried to reconnect to a instance authentication would fail. Setting the authentication mode from Automatic to NTLM fixed this issue for us.

Saturday, September 23, 2006 5:09:30 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [1]  | 

Note: For visitors of your site, this entry is only displayed for users with the preselected language English/English (en)

It only took me several years to get around to it, but I finally did it; I installed a blogging package, dasBlog!

I'm not sure why it took me this long, but I hope to use this space as a centralized storage of random thoughts and notes for future reference for myself - and anyone else if they're interested.

Saturday, September 23, 2006 4:42:43 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, July 20, 2005

After logging in, be sure to visit all the options under Configuration in the Admin Menu Bar above. There are 26 themes to choose from, and you can also create your own.

 

Wednesday, July 20, 2005 7:00:00 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, June 26, 0002
I just relearned a valuable lesson today, make sure when you are using multiple libraries in your C++ project, that they all use the same runtime library.  For instance, if you have one library set to use the Multi-threaded (/MT) runtime library, then make sure the consuming project also is set to use the Multi-threaded (/MT) runtime library.

C++
Wednesday, June 26, 0002 4:23:25 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  |