Another DevTeach has come and gone. I had an awesome time. I enjoyed hanging out with old friends and meeting some new ones. I saw a lot of great sessions, but the best part, as always, is the hallway and bar conversations. (No, I still haven't quite figured out Metastones, even after playing for hours.) I wanted to especially thank everyone involved in the agile track - both presenters and attendees. I have received a lot of positive feedback on the track. Given that I organized the track, I am immensely pleased with its success.

You can download my slides and demos from here or the DevTeach site.

Achieving Persistence Ignorance with NHibernate (2.6 MB)

Taming Software Dependencies with DI and IoC (20.9 MB)

I have started keeping my latest presentations online in Google Code's Subversion repository.

svn checkout http://jameskovacs.googlecode.com/svn/Presentations/

Take a look in the tags to get the slide deck and demos for a particular event. For example, you'll find tags/DevTeachToronto2008 contains the version from - surprise, surprise - DevTeach Toronto 2008. If you have any questions or comments on slides, demos, or techniques, please don't hesitate to email me.

DevTeach is returning to Montreal on December 1 to 5, 2008. I'll be the Agile Track Tech Chair again. Jean-Rene will be putting out a call for sessions in the near future and you should find the announcement here. If you are interested in speaking in the Agile Track, feel free to email me. If you attended any sessions in the Agile Track and have suggestions for things that you'd like to see again or suggestions for improvement, email me!

...a ReSharper Jedi, that is. I am making no claims about my own ReSharper Jedi abilities. JP and Oren are known ReSharper Jedi Masters. I feel more like Luke Skywalker when he first landed on Dagobah in comparison. Back to the point of this post...

Many developers don't see the value of JetBrains' ReSharper until they've seen it in action. So I'm putting together this screencast series to show off my favourite ReSharper features. My goal is to keep each screencast to 5 to 10 minutes and focus on a related set of capabilities. In the first episode, I look at ReSharper's Code Browsing - CTRL-N, CTRL-B, CTRL-ALT-B, ALT-F7, and related.

Streaming: Becoming a Jedi - Part 1: Code Browsing (requires Silverlight 1.0 or higher)*

Download: Becoming a Jedi - Part 1: Code Browsing (via Live SkyDrive)

Before someone makes a snarky comment about my coding speed, I'm intentionally taking the time to explain the features. That and I'm not as adept as some at coding and talking at the same time. Hopefully I'll improve with practice as this screencast series progresses. Any constructive feedback on the content or presentation style is appreciated. Enjoy!

* I am encoding the series using Silverlight 1.0 for two reasons:

1. In my tests with Camtasia, the Silverlight version scaled better than the Flash version. Text in Visual Studio remained clearer as the video was resized. The original recording is at 1024x768, but is still legible when scaled to 640x480 or smaller.
2. I can host the content on Silverlight Streaming for free. When you sign up for an account, you get 10 GB of storage and 5 TB of bandwidth per month. The videos are distributed by Microsoft's content delivery network and streamed from a server close to the viewer. As an author you simply upload your videos to Silverlight Streaming and Microsoft does the rest. I also don't run the risk of blowing the bandwidth allotment at my hosting provider and incurring charges for bandwidth overages.

The following is a list of excellent books that every developer should read. I have focused on technology-agnostic books as I find them the most valuable. I have read every book on this list and recommend them without reservation. As I read more, I'll update this list. At bottom, you'll also find a list of books that I'm currently reading. The worthy ones will gradually appear in the main list, while the others will ignominiously disappear.

Full Disclosure: The book links below are through the Amazon Affiliates Program. If you buy a book through a link, I get more books from Amazon to sate my hunger for knowledge.

Becoming a Better Developer

• The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas
  • In terms of biggest bang for your reading buck, The Pragmatic Programmer tops my list. This book is a timeless classic originally published in 1999. It will introduce you to such fundamental concepts as the evils of duplication, orthogonality, design by contract, testing, refactoring, and more. Many of the core development concepts that agile/XP/lean developers take for granted are laid out in this book.
• Release It!: Design and Deploy Production-Ready Software by Michael Nygard
  • How often have you seen the disclaimer, "This isn't production code." Ever wondered what production-ready code looks like. In this book, Michael Nygard clearly documents what it means to be production-ready and how to get there. He discusses common concerns that often get forgotten by developers, such as how is the IT department going to support and monitor the application once it goes live. A must-read for any developer who aspires to have their code deployed into production.

Design Patterns

• Head First Design Patterns by Eric Freeman and Elizabeth Freeman
  • This book offers deep insight into core programming concepts in a playful, approachable way. Although it is written for Java developers, it is equally applicable to and comprehensible by C# developers. It covers the classic "Gang of Four" software patterns, but frames them in within actual problems so that you can see how to apply them. You understand the power of coding to interface not implementation, why we favour composition over inheritance, and how to apply the open-closed principle. Even if you have read the GoF, I would highly recommend this fun read!
• Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides (aka The Gang of Four)
  • Another classic, it provides an invaluable reference, but is one of the worst ways to learn design patterns. Often considered a cure for insomnia, it takes a real geek to read this book cover-to-cover. (Yes, I read it cover-to-cover.) If you're looking to learn design patterns, you would be better served picking up Head First Design Patterns first (see above).
• Patterns of Enterprise Application Architecture by Martin Fowler
  • This book is a fantastic compendium of patterns for building real applications. It covers everything from data access (unit of work, table data gateway, repository, lazy loading) to business (domain model, null object, value objects) to UI (MVC, front controller, MVP).
• Applying Domain Driven Design and Patterns by Jimmy Nilsson
• Domain Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
  • Domain driven design is all about how to build applications where the most important part of the application is your domain or business logic, not the libraries and frameworks on which it is built. How can we structure our code to shield ourselves from the UI, database, logging frameworks, and other concerns? The purpose of erecting these anti-corruption layers is not to live in an ivory tower, but to allow us to focus on the unique aspects of our application - its business logic. Eric Evans provides valuable insights into how to build better software, but many people find his book a difficult introduction to the subject. Jimmy Nilsson's book provides a practical guide to using DDD concepts along with patterns from Patterns of Enterprise Application Architecture. I personally found Evans book easier to understand after reading Nilsson's. I heartily recommend both books.
• Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf
  • If you're building a distributed system, then this is a must-read book. It doesn't matter whether it will be based on a commercial EAI product (BizTalk, Tibco, ...) or plain old .NET/Java/... code. This book documents common patterns for building distributed applications.

Refactoring

• Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
• Refactoring to Patterns by Joshua Kerievsky
  • Refactoring isn't a discrete task in your development schedule. It is a continuous activity to improve your codebase as you add features. With a good suite of tests around your code, you can safely refactor it as you add features. If you do not refactor, you build up technical debt where each new feature takes longer and longer to implement as the codebase becomes more and more unwieldy. These books provide a catalogue of refactorings to solve common development challenges. Kerievsky's book continues on where Fowler's book left off. Both are excellent reads.
• Working Effectively with Legacy Code by Michael Feathers
  • The one big assumption that both Fowler's and Kerievsky's books make is that you've got a solid suite of tests around your code. But what if you don't yet? That is where Michael Feathers' book comes to the rescue. It provides excellent strategies and patterns for safely implementing tests around untested code, which is crucial in order to make non-breaking changes to an existing application AKA refactoring. If you can refactor your code, you can improve your code.

Agile Practices

• Implementing Lean Software Development by Mary and Tom Poppendieck
  • What a fantastic book! Have you ever needed to convince a management type why iterative development, continuous integration, refactoring, or other agile technique was important? Then this is the book for you. Lean development takes its cue from lean manufacturing as pioneered by Toyota and applies the same ideas to software development. It provides a solid grounding in business principles for agile development without the dogma often encountered in other methodologies. If you're going to read one book on how to manage agile projects, this has to be it.
• Extreme Programming Explained: Embrace Change by Kent Beck and Cynthia Andres
  • Ever wondered how a development team should work on a day-to-day basis? Then this is the book for you. It provides a list of values, principles, and practices for the agile team. It is light on the overall management of a project, but you can look to Lean or Scrum to fill in the gaps.
• Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
  • A good introduction to the Scrum methodology. Scrum is primarily concerned with providing structure between a project team and management. It doesn't address how a development team should run day-to-day. So it dovetails nicely with Extreme Programming. The book provides lots of anecdotal success stories, which are fun reads. Keep in mind that it recommends an iteration length of one month, which is too long in my opinion. One to two weeks provides a much better feedback loop.
• User Stories Applied by Mike Cohn
  • Use cases and requirements documents are seldom read and often misinterpreted. Is there a better way? For agile projects, look no further than user stories. User stories are a lightweight technique for capturing and prioritizing end user requirements. Mike Cohn provides a great description of the technique and practical advice on how to apply it.
• Agile Estimating and Planning by Mike Cohn
  • Project estimation is hard. Very hard. Every project is different from the last. If it wasn't, you'd just pop a blank DVD-R in your burner and copy the previous solution. This book provides practical advice for how to estimate projects, especially agile ones. One of the big revelations for me was the distinction between absolute and relative size of tasks/stories/epics. Humans are fantastic at estimating relative size, but horrible at absolute size. Quick - order these dogs from largest to smallest: Terrier, Poodle, Great Dane, German Shepherd, Chihuahua. Probably not too difficult. Now how tall is a Chihuahua at the shoulder? You're probably a lot less certain. Mike makes a convincing argument for using story points (comparative estimates of size) combined with velocity (story points completed per iteration) to drive planning. This is a must-read for any developer who ever has to answer the questions "How long is this going to take?" and "When is this going to be done?"

Currently Reading (in no particular order)

• Refactoring Databases by Scott W. Ambler and Pramodkumar J. Sadalage
• Continuous Integration by Paul Duvall, Steve Matyas, and Andrew Glover
• Implementation Patterns by Kent Beck
• xUnit Test Patterns by Gerard Meszaros

DevTeach is happening May 12-16, 2008, this time in Toronto, Canada. DevTeach is a fantastic conference and that's not because I'm speaking there or organizing the Agile Track - though those are good reasons too. Just take a look at the line-up of internationally known speakers. Attendance is purposely capped in the hundreds to encourage speakers and attendees to meet, chat, dine, drink, and otherwise talk tech in a relaxed atmosphere. For those interested in agile development, the Agile Track has been expanded to 17 sessions over the full three days. There is also Party with Palermo, a keynote by Scott Hanselman (Microsoft), and .NET Rocks Panel Discussion with Scott Bellware, Ted Neward, and Oren Eini. If you've been itching to learn about TDD, Silverlight, WPF, SQL CLR, or other topics, there are one-day pre-/post-conference sessions available at reasonable prices. DevTeach is a fun and amazing learning experience. Hope to see you there! You can register here.

This morning I was getting ready to record a screencast about ReSharper 4 EAP. To make it easier for people to follow along, I launched Roy Osherove's excellent utility, Keyboard Jedi. Rather than the expected result, this friendly dialog box greeted me:

Living La Vida x64

My main development machine is running Vista x64. I've used KeyJedi frequently on my Vista x86 laptop and never had a problem. So I immediately suspected a 64-bit compatibility issue. KeyJedi is a .NET 2.0 application, which means that it will execute on the 64-bit CLR if available. (The 64-bit CLR was introduced with .NET 2.0. You don't have to do anything special. If you install .NET 2.0 or higher on 64-bit Windows, the 64-bit CLR is installed automatically.) The 64-bit CLR uses a 64-bit JIT compiler, which produces x64 (or IA64)* machine code. This is why things like Paint.NET's Gaussian Blur, which involves a lot of 64-bit arithmetic, run faster on 64-bit Windows. The MSIL is identical, but on 64-bit platforms, the JIT produces 64-bit optimized code. For example, a 64-bit ADD can be done in a single instruction on 64-bit hardware, but requires multiple instructions on 32-bit. (N.B. If you're running 32-bit Windows on 64-bit hardware, there is no way to access the 64-bit capabilities of the chip as the OS thinks it's running on a 32-bit chip.)

* x64 is the 64-bit enhanced, x86-compatible instruction set introduced by AMD. IA64 is used by Intel's Itanium processors and is incompatible with x86. So you have to recompile the world to use IA64. Once Intel realized that not everyone on the planet was willing to recompile their programs, they introduced EMT64 for the Pentiums and Core chips. EMT64 is functionally identical to x64 from AMD.

WoW

So on Vista x64, KeyJedi is running on the 64-bit CLR. But that doesn't explain why it fails. Most programs, like Paint.NET, just work. What is KeyJedi doing that is special and incompatible with 64-bit Windows? It is registering global system hooks to capture keyboard and mouse messages. Registering hooks and receiving messages involves Win32 calls, which are handled by Michael Kennedy's Global System Hooks in .NET library. This library includes both managed (Kennedy.ManagedHooks.dll) and unmanaged (SystemHookCore.dll) code. SystemHookCore.dll makes 32-bit Win32 calls and receives 32-bit callbacks. You cannot make 32-bit Win32 calls directly to the 64-bit Windows kernel. You need a translation layer, which is the Windows-on-Windows or WoW layer.

The WoW layer marshals 32-bit Win32 calls to and from their 64-bit equivalent, translating data structures on the way in and out. This marvelous piece of magic is built into 64-bit Windows and allows most 32-bit programs to execute on 64-bit Windows without problem. The WoW layer sits below all 32-bit processes happily marshalling system calls back and forth. If you're running in a 64-bit process, such as the 64-bit CLR host, there is no WoW layer beneath you. So you cannot load 32-bit DLL, such as SystemHookCore.dll. (This is also why 32-bit kernel-mode drivers don't work on 64-bit Windows. There is no WoW layer in the kernel. It exists between user and kernel mode.)

Now we know the problem. The question is how to fix it. We could create a 64-bit version of SystemHookCore.dll, but that would involve a lot of spelunking and debugging of unmanaged C++ code. Not exactly how I want to spend my morning. The other option is to force KeyJedi to run on the 32-bit CLR even on 64-bit Windows. Then we would have the WoW layer beneath us and SystemHookCore.dll could merrily assume that it is running on 32-bit Windows while the WoW layer takes care of all the 32-bit to 64-bit Win32 marshalling. So how do we force a managed application to run on the 32-bit CLR...

Any CPU vs. x86

The easiest technique is to modify your project settings in Visual Studio. Just go to Project Properties... Build... Platform target and change it from Any CPU to x86.

Now you might think, "Wait a second. I'm compiling to MSIL, which is processor independent." Yes, you are, but when you select Any CPU (the default), your program will load on the 64-bit CLR if available. By selecting x86, you are forcing the program to run on the 32-bit CLR. Then just recompile your program and problem solved. Just one problem... Roy never released the source. (Yes, I've emailed Roy and asked him to do recompile with x86 as the target platform.)

No Source, No Problem

We don't want to modify the application, just ask it to run on the 32-bit CLR. Turns out that the project settings above just twiddle the CORFLAGS inside the PE file header of the executable. The .NET Framework SDK ships with a program called corflags.exe for just this purpose:

You'll notice that 32BIT has a value of 0, which means Any CPU. We want to twiddle this to 1. One little problem. The assembly is signed. Twiddling even a single bit will invalidate the signature and the CLR loader will prevent the application from loading. If the assembly weren't signed, you could just execute:

corflags KeyJedi.exe /32BIT+

ILDASM to the Rescue

Time to bring out the big guns. We're going to disassemble KeyJedi.exe into MSIL. Hold onto your hats...

ildasm /all KeyJedi.exe /out=KeyJedi.il

This produces three files:

KeyJedi.il

KeyJedi.res

Osherove.KeyJedi.MainForm.resources

Time to hack some MSIL... Open KeyJedi.il in your text editor of choice and search for ".corflags". Change the line to:

.corflags 0x0000000b    //  ILONLY 32BITREQUIRED

We can't compile the code yet because we don't have the private key that matches the public key embedded in the MSIL. Search for .publickey and delete it. (You could change it to your own public key generated with sn -k, but there's no reason that we need to sign the assembly.) Now we can re-compile the MSIL using ilasm:

ilasm /res:KeyJedi.res KeyJedi.il /output:KeyJedi-x86.exe

If we execute KeyJedi-x86.exe, we get:

Success!!! KeyJedi is now running on Vista x64.

Postscript

I'm not going to redistribute the recompiled binary because KeyJedi is Roy's baby and the fix is really straightforward for him to make. Look to his blog for an update. My main purpose was to help people better understand 64-bit compatibility issues and some tricks that 64-bit Windows does so that, in most cases, you aren't forced to recompile the world to run the programs you've come to depend on.

Earlier today, an unknown hacker exploited a security vulnerability in ScrewTurn Wiki and replaced the altnetpedia site with pron links. I have restored the site and upgraded to the latest version of ScrewTurn, which is v2.0.30. (We were running v2.0.21 and the vulnerability was fixed in v2.0.24.) My bad for not keeping the site updated with latest. I apologize to the ALT.NET community for not being more vigilant with patches to the wiki software. I've added the ScrewTurn RSS feed to my reader to keep me apprised of future fixes.

To the unknown hacker, I hope that you're satisfied. I had booked the afternoon off to take my two boys (ages 3 and 5) to the Science Centre, but instead spent it undoing your evil.

Today at lunch* I'll be joining Glen Gordon and Lynn Langit on geekSpeak to talk about Taming Your Software Dependencies. Specifically I'll be talking about moving from tightly-coupled to loosely-coupled architectures using dependency inversion, dependency injection, and inversion of control containers. geekSpeak is an interactive LiveMeeting driven by audience questions with no PowerPoint and lots of code. Come and geek out with me on geekSpeak! Register here.

* Today at lunch == Wednesday, March 26, 2008 from 12-1pm PST or 1-2pm MST or 2-3pm CST or 3-4pm EST or ...

My latest article just hit the web in the March 2008 issue of MSDN Magazine. Loosen Up: Tame Your Software Dependencies for More Flexible Apps takes you on a journey from a highly-coupled architecture, which we're all familiar with, to gradually more loosely-coupled ones. First stop is the problems inherent in highly-coupled applications. To start solving those problems, I look to dependency inversion and service location. Next stop is poor man's dependency injection and then a simple, hand-rolled inversion of control (IoC) container. From there, I look at the features provided by full-fledged IoC containers and use Castle Windsor as an example, along with some Binsor thrown in for configuration goodness. My goal was to help developers understand the benefits of dependency injection and IoC containers by showing them the problems solved at each stage of the journey.

A big thanks to Howard Dierking, MSDN Magazine editor extraordinaire, for his encouragement and not having an issue with using Windsor for the advanced examples. Thanks to Oren Eini for help debugging a Binsor configuration problem in one of the examples. And an especially big thanks to my spouse and two young sons for their patience while I was writing.

Thanks in advance for reading the article. I welcome your feedback and questions.

DISCLAIMER: For the agilists reading this post, there is nothing new here. I just hear a lot of misconceptions around terms like YAGNI and wanted to provide my own take on things.

YAGNI is an acronym for "you ain't gonna need it". You often hear it bandied about agile shops. One developer suggests an over-architected solution and the other cries out YAGNI. For example:

Dev#1: We can transfer that file using BizTalk!

Dev#2: YAGNI. We can download it using HttpWebRequest.

I'm not knocking BizTalk here. My point is that if all you need to do is transfer a file from point A to point B, BizTalk is an awfully complicated and expensive way to do it.

Many agile critics see YAGNI as an excuse for developers to do stupid things. Critics claim that YAGNI encourages developers to hard-code connection strings and other silliness. "In development, you're not going to need to change the connection string. So by the YAGNI principle, you should hard-code your connection strings. Isn't agile stupid?" YAGNI is a principle like any other and should be applied intelligently. It's about keeping simple problems simple. It's about the right tools for the right job - don't try to drive a finishing nail with a sledgehammer. Too often we as an industry implement "enterprise solutions" to solve otherwise trivial problems.

YAGNI isn't an excuse to be sloppy with your architecture. If you're building the next hot social bookmarking application, it better scale. You better design with caching, distribution, load-balancing, etc. in mind. I would want some architectural spikes demonstrating acceptable performance at high user loads. Similarly if you're developing an internal application to be used by 10 users, I would bet that you don't need the complexity of a load-balanced web farm, distributed middle-tier cache infrastructure, and a clustered database. YAGNI is about choosing the appropriate amount of complexity for the problem at hand.

YAGNI is about building software at the last responsible moment. The "responsible" part is key. You can't slap an asynchronous architecture in after the fact. You need to design that in up front. At the same time you should avoid speculative generalization. Solve the problems at hand with a responsible eye toward future requirements. Keep yourself lean and nimble enough to respond to those future requirements, but don't build them "just in case we need them". What you will need in the future seldom has any resemblance to what you might build now. Even worse, unused features add complexity and rigidity to a codebase. You're actually worse off than if you didn't have those features at all! Keeping your architecture simple, lean, and nimble requires a lot of discipline.

So next time someone suggests using a SOA-based ESB to integrate the disparate workflows in the document lifecycle, ask yourself whether a wiki couldn't work just as well. :^)