-
Get a monthly update on best practices for delivering successful software.
On a recent project after months and months and hundreds of files worth of work, we were asked to provide documentation for the code. This request could have gone one of two ways depending upon how well we adhered to some basic documentation rules.
The C# compiler itself is setup to extract documentation which can then be piped through one of a number of documentation generation apps. My preference is a new(ish) project called SandCastle from Microsoft, which aims to provide much of the featureset that NDoc once did. Unfortunately this application provides no GUI. A fine gentleman named Eric Woodruff stepped in to wrap this application in an easy to use GUI for us aptly named Sandcastle Help File Builder. Through the use of good comments written WHILE we wrote the code, we were able to pop out some documentation for every bit of code we wrote in a matter of minutes. Add to this the nice information we get when using our code via intellisense, and it simply doesn't make sense not to strictly enforce documentation standards on your project.
I often see code written with little or no attention paid to comments. Sometimes the comments are fairly haphazard and appear to follow no standards whatsoever. By following documentation standards, you too can auto generate documentation instead of wasting hours or days going back through and trying to remember what your code does. Continue reading »
Topics: c# documentation ndoc sandcastle

I've been in just about the same cycle for almost 15 years now. Install Windows. Install the software I need on top of it. Wait about 6 months to a year until I can no longer take the gunk slowing down my system ("Windows Disease"). Backup my data. Format my drive. Rinse and repeat. Do this maybe 3 or 4 times, and then upgrade my hardware. Sound familiar?
So I got smarter. I started making images using Ghost. This has worked fairly well. I get a new system, I set it up as pristine and fully featured as possible, then I take an image of it. This way the install step takes a couple button presses, leaving me to do more useful things with my time. Like blog or something.
Fast forward a couple years. Processors are way faster and have more cores. Virtualization is no longer a toy, and can now be used not just for enterprise purposes, but on the desktop. Sure I'm mostly a Windows developer, but that doesn't mean I don't want to write iPhone / Mac applications. So after cursing my previous laptop up and down on a daily basis, I've upgraded to a MacBook Pro. It's tiny, it's fast, and it runs OS X and WINDOWS via VMWare Fusion. Windows runs spectacularly on my MacBook. The most beautiful part is, as far as I can tell, there is no parallel (no pun intended) to "Windows Disease" on a Mac. It has continued to run as fresh and fast as the day I installed the OS. Now with my backed up copy of my Windows virtual machine, starting from scratch on Windows is as simple as taking a fresh copy and spinning up the backup VM.
Developing an application with WinForms can lead to difficult testing scenarios. There are a ton of automated UI testing toolkits that essentially record workflows and replay them. This can work, but leads to unwieldy tests, and makes it difficult to integrate them into automated tests and builds. I recommend using the Model View Presenter (MVP) pattern for your application architecture to relieve this pain point. Todd Snyder from Infragistics has a nice blog entry explaining the differences between MVC and MVP patterns. The gist is: you have a coordinating Presenter that communicates with the View via its interface, and orchestrates the interaction between the View and the Model. The important piece here is the View interface. This view interface can allow you to stub or mock the view in testing scenarios, to completely eliminate the need for any UI interaction. As long as your UI code is used as a shell that does nothing but pass messages, this makes testing REALLY easy.
We recently built a project around the MVP architecture. Eventually we wound up creating a test harness providing us simple methods such as:
public void MouseUp(IDocumentPresenter presenter, int x, int y)
This simulated a mouse up event without actually requiring an input device or the UI that it acts upon. With simple method like these, you can build up some pretty complex tests that run quickly and don't require any special libraries to run.
Before embarking on your next GUI framework based application, be it WinForms or other, evaluate the MVP pattern and the ease of testing that it can provide. It's worked really well for us.
Love it or hate it, pair programming is a large component of many agile development methodologies. I've become a firm believer in the benefits of pairing, and very rarely write code nowadays without some degree of collaboration with a second (or third) developer. The benefits have been vast. The code is better thought out because a pairing session always starts with a discussion of the approach to be taken. Fat-fingered mistakes are headed off at the pass because a second set of eyes is closely watching what's being typed. Less time is wasted checking email, taking calls from the in-laws, and just generally doing things that would annoy the second member of the pair. Above all, it allows developers to analyze and quickly debate the approach being taken, and adjust and improve that approach throughout the development cycle.
It all sounds great doesn't it? Well it is when executed correctly. In my experience there are two general principals that if not adhered to, will turn a productive pairing session into a developer writing some mediocre code sitting next to a developer who might as well have taken the day off. These principals are: developers must remain engaged, and developers like their own space.
Topics: agile, Pair Programming
I've begun my foray into the world of LINQ, and in my investigation I've seen a lot of work based on the LINQ to SQL "design surface" available in Visual Studio 2008. It's a neat tool. I point it to my database, drag some tables over, and it infers my domain structure and relationships from the databases fields and keys. That's all well and good for a simple domain model that is directly related to the database schema. I could see using this for a quick prototype, or a really small application. I see three files created by the designer:
MyClasses.dbml - This looks like any ORM frameworks mapping file. It associates classes with tables, maps fields to object properties, and defines relationships.
<table border="0"></table>
MyClasses.dbml.layout - This looks to be specific to the layout of the design surface and appears to serve no purpose outside of this design.
MyClasses.designer.cs - This is the beast that I'm looking to replace. It contains the class definitions and attribute based mappings to bring my database schema into my application, and ready it for use by LINQ.
So this leaves me with a couple questions. One, why are attributes used to specify mappings? Can this be done strictly via XML? More importantly two, can I use my own domain model, and if so how do I map it to the database?
My goal would be to design a layered system, separating the underlying data store from the repositories required to push and pull my domain objects from these data stores. This would allow in memory implementations of the data store, and would make unit testing (and developing) a whole lot easier. I will be digging into this in the coming days and will report back soon. Stay tuned!