Shout Out to Doxygen

Software Architecture is largely a matter of communication. One big area of communications is documenting a library, whether for internal or external consumption. It is well-known that written documentation goes out of date the minute you publish it.

The only hope of keeping the documentation up-to-date is to have the it embedded within source code it is illuminating. This allows you to update the doc as you update the code. The Javadoc and C# XML comments are good for this, but don’t give you a good way to provide anything beyond documentation of classes and methods, which often falls short in properly documenting a library or code base.

Doxygen is a capable, open source library that combines the comment-based documentation with a full mark-up language that allows you to add text, diagrams, pages, sections, lists, etc. that allows for robust documentation.

Some of my favorite features include:

  • Auto-generated class and collaboration diagrams
  • The ability to include hyperlinked source
  • Compiled Help format
  • PDF format

Update Route Tables on Windows Mobile

Our dev team needed to do something that, evidently, very few people need to do… update the routing tables on a Windows Mobile device that is simultaneously connected to both WiFi and the wireless carrier. Internet searching was very little help, but we eventually stumbled across a nifty little shareware app called PocketLAN by z2 Software. If you are doing any advanced networking on a Windows Mobile device, PocketLAN is well worth the $14.99.

A Nifty Extension Method for Mapping Property Values by Name

Here is a nice little C# extension method that allows you to copy all of the properties from one object to another where the names match.

SetPropertiesByName(this object target, object source)
{
PropertyInfo[] sourceProperties = source.GetType().GetProperties();
PropertyInfo[] targetProperties = target.GetType().GetProperties();
foreach (PropertyInfo targetField in targetProperties)
{
PropertyInfo sourceProperty =
(sourceProperties.Where(f => f.Name == targetField.Name)).FirstOrDefault();

if (sourceProperty.IsNotNull())
{
targetField.SetValue(target, sourceProperty.GetValue(source, null), null);
}
}
}

The usage looks this…

foo.SetPropertiesByName(bar);

I was using AutoMapper for this, but it was overkill for what I needed.

Desktop Developer’s Introduction to Compact Framework Development: Part 4-LINQ on the Compact Framework

LINQ (Language-Integrated Query) is supported on the Compact Framework. However, like with every other technology on CF, there is stuff you might that isn’t there. In my case, it’s LINQ to SQL. System.Data.Linq is not provided on the Compact Framework.

Also, contrary to some reports, the Entity Framework 3.5 is not provided on the Compact Framework, either.

Referencing a File by Relative Path with T4

This was way harder to figure out than it should have been, so for the next person that needs to reference an input file in a T4 template by its relative path, here is what you need to do…

1. Include T4Toolbox.tt…

<#@ include file=”T4Toolbox.tt” #>

2. Add hostspecific=”True” to your template setting…

<#@ template language=”C#” hostspecific=”True” #>

3. Import EnvDTE…

<#@ import namespace=”EnvDTE” #>

4. Now TransformationContext.Host.ResolvePath(“SomeFile.sdf”) will return the absolute path of “SomeFile.sdf”.

Domain-Driven Design Friendly Persistence on the Compact Framework

I’ve been searching for a persistence tool that will eliminate the hand coding of our basic CRUD operations. I’m looking for something that allows us to develop our domain model in plain, unencumbered C# classes, and later persist them to a data store. Ideally, I’d like to use the same tool on both the Windows Mobile devices and on the server (just so we don’t have to learn two different tools or frameworks). This is the story of my pain…

NHibernate – The first and obvious choice for DDD-friendly persistence in .NET is NHibernate. It is a true object-first ORM and seems to have a lot of interesting tooling growing up around it. Alas, NHibernate is not supported on the Compact Framework because of some unsupported reflection it uses.

LLBLGen Pro – Developers who use LLBLGen Pro seem to love it. It is supported on the Compact Framework, but LLBLGen will not support an object-first approach until version 3.0 which won’t even beta until the end of Summer 2009, which is way too late for me.

Entity SpacesEntity Spaces is yet another commercial database-first ORM that runs on the Compact Framework. I don’t see anything that it offers that LLBLGen doesn’t offer.

Entity FrameworkEntity Framework is supported on the Compact Framework and is free but does not support any kind of POCO, object-first approach.

db4objectsdb4objects was an extremely intriguing option. I had never considered using an object database before. I found db4o extremely easy to use and intuitive—perfect for the lightweight storage needs we have on handheld devices. However, db4o is offered under a GPL or commercial license. The GPL license won’t work for us and the commercial license is orders of magnitude more expensive than a tool like LLBLGen or Entity Spaces.

Given that having our developers write all of the database access code by hand is (in my opinion) too time-consuming and error prone, I’m left facing some sort of compromise approach.

One option is to create my domain model as I need to, ignoring persistence. Then, within my repository implementation use a data-first tool, treating the “entities” generated by the persistence tool as DTOs and manually translate them into my true domain objects.

The second option is to again model the domain, but attempt to back into the code we need for those objects using a tool like EF or LLBLGen. The Patterns and Practices guys seem to think this approach is true to the DDD concept (see this article). I’m not sure I agree.

I think I’ll give a go at the second approach and fall back to the first if I see that the database schema, and not my domain, is driving the conceptual creation of my object model. I’ll also have to figure out whether to use LLBLGen or Entity Framework. EF is free, but LLBLGen is more mature and may offer a better option in the next version.

Desktop Developer’s Introduction to Compact Framework Development: Part 3-C++/CLI on Compact Framework

It may seem like a waste to have a whole post dedicated to a feature that isn’t there, but knowing this fact would have saved me some wasted mental effort and disappointment.

The Compact Framework is necessarily small. Microsoft only puts functionality into it that developers will be likely to actually need. This means that a lot of stuff you’d like to be there isn’t. This also means that you might need to interoperate with native code to do some of what you want to do.

If you are like me, this means you would like to use C++/CLI (the old-school .NET technology formerly known as Managed C++) to do that interop. You, like me, would be sorely disappointed. C++/CLI is not supported on the Compact Framework, and as far as I know there are no plans to add it. Prepare to P/Invoke.

Unit Tests Just a Happy Side Effect of Test-Driven Development

Interviewing developers has given me an interesting, although not scientific, sampling of the thinking and mindset of software developers in the Atlanta area. While there have been a few bright spots, most of what I’ve learned has been disheartening.

I have found that TDD is still only an idea that most developers have heard about but never practiced. Of the ones who have practiced it, almost none of them understand what TDD was meant to achieve and only view it as automated unit testing. I believe this is due to two factors working together derail the original intent of TDD. First, TDD was named poorly. “Test” has specific meaning and has for a long time. It naturally biases us toward a certain type of thinking (strangely enough… testing and quality assurance). Second, most developers and development organizations would rather apply a formula or recipe to what they do than to take the time and effort to deeply understand what makes software development success or failure (and all of the degrees in between).

Scott Bellware is the guy who first got me thinking about a new way to approach TDD. It started with a new name: Behavior Driven Development (BDD). I actually think the “D” should be changed to Design to complete the mind shift. In a nutshell, BDD attempts to get back to the XP view of the tests being documentation of what the code should do. In this way of thinking, the set-up code is referred to as context and the assertions are referred to as specification. It has helped reform my thinking about TDD for the better.

You can catch Scott pontificating on the subject on the latest Hanselminutes podcast. Scott doesn’t get as specific as I would have liked, but this interview shows the side of Scott that I like so much. He’s passionately advocating a valuable practice and philosophy without the insults and vitriol that he is prone to fall into. I highly recommend it.

[Update: My reference to “Scott” in the above paragraph is to Bellware–not Hanselman, who is always pleasant and rarely vitriolic.]

Spell-Checking for ReSharper

Your code will be written once. It will be read (by you and others) many times. Code should be easy to read. This means that I should be able to scan a screen full of code and get a sense of what it does quickly. Layout and spacing plays s big part in that. Naming things with real, recognizable words just as important.

If you buy that, it goes without saying that those words that make up your identifiers must be spelled correctly. I am a terrible speller. As a C++ coder, I loved that Visual Assist would give me the red squiggles under any word that I misspelled. This has been the only regret I have about moving from VA to ReSharper. In every other way, ReSharper is a win over what VA offered.

I’ve just discovered Agent Smith as a plug-in to ReSharper. I had to make a few tweaks and drop one of the checking rules, but I am loving it. My ReSharper experience is now complete!

Desktop Developer’s Introduction to Compact Framework Development: Part 2-Windows CE versus Windows Mobile

Sorting out the difference between Windows CE and Windows Mobile is the key to understanding the platform versioning (which can be very confusing). Here it is in a nutshell…

Windows CE is a set of modules that Microsoft releases for hardware vendors to build operating systems custom for their devices. Because these devices are so resource constrained, manufacturers don’t want to put any functionality on them that isn’t necessary.

It turns out that there are a whole bunch of devices that need about the same functionality, namely smart phones and PDAs. Instead of having each smart phone and PDA manufacturer build their own version of CE and add in all of the niceties that are needed to be productive on those devices, Microsoft offers Windows Mobile. In other words, Windows Mobile releases are instances of Windows CE specifically built for handheld devices.

The group that develops Windows Mobile is a customer of the CE group. The Windows Mobile releases always trail the CE releases and have their own (crazy) naming and versioning scheme. In the beginning, it was called PocketPC (first 2000, then 2002), then there was a split, as they offered Windows Mobile 2003 for PocketPC and Windows Mobile 2003 for Smartphone. PocketPC was optimized for a touch screen and keyboard while Smartphone was optimized for menu buttons and a numeric keypad.

With Windows Mobile 5 and 6 (which are found on most devices today), there are three flavors: Pocket PC without phone (classic), Pocket PC with phone (professional), and Smartphone (standard).

Wikipedia has a decent breakdown of the various combinations.