With the popularity of service oriented architectures and other buzz phrases related to software as service, good API design has become a significant selling point for any software platform in the past 5-10 years.  People make purchasing decisions based on how easy it is to interoperate with your applications and code and as such the number of client / public facing APIs attached to software has skyrocketed.  I’d like to believe the days of dropping strategic text files in directories to trigger some action or another in an application are behind us.

In this article I’m going to talk about the following things

• Why you should choose your method names carefully, and what to call
• Why pretending to be a data access layer is a terrible thing for an API to do
• Talk about the dangers of leaky abstractions in an API
• Explain the benefits of creating a data contract between you and the calling code
• Explain why it’s vital to support standards
• Make sure that your users can retrieve values they’re going to want to modify
• Suggest supplying compiled libraries alongside your API documentation
• Explain why it’s important to keep your API implementation clean
• Talk about the benefits of dogfooding your API
• Consider supporting atomic operations including rollbacks on failure
• Discuss bulk operations
• Try and convince you that both logging and security should be first class citizens
• Beg you to maintain integration tests and most of all to keep it simple!

Your API Sucks

You’ve probably used an API and there’s a good chance you’ve had to write one.  This probably won’t surprise you; most APIs suck.  They’re horrible to use and built around illogical leaky abstractions that leave you flicking through huge wads of documentation just to make the most rudimentary feature work.

About 18 months ago, after a year of struggling with a broken third party API that almost brought a business to it’s knees by placing significant roadblocks in front of in house development, I was part of a team tasked with designing our own client facing API.  With no desire to expose other developers to the cruel and unusual punishments of software design we’d had to endure, we came to the conclusion that it was really important that we god this piece of the system right.  People say first impressions are everything, and your API design can make or break the faith other developers have in your ability to produce software.  Show somebody a shitty API and they’ll perhaps correctly assume the rest of your code sucks too.

The Best Man For The Job

There’s a bit of a trend that I’ve noticed with some of the worst APIs I’ve worked with: they seem to be designed by the wrong people.  The wrong people to design an API are 1) the guy that wrote the internal code to do the job the API is providing access to and 2) the consumer of the API. 

The guy that wrote the code that the API is calling under the hood will be inherently slanted to implement an API which exposes this functionality and will have a predisposition to creating a leaky abstraction.  This is especially bad for the consumer APIs designed by the internal implementer tend to assume the consumer knows far more than he really does, or has access to internal data that in reality, he doesn’t.

Conversely, an API designed by the consumer of the API will have a tendency towards solving problems that are not the concern of the API itself.  The consumer will, either accidently or by intention, attempt to offload some of the work that should be the responsibility of the calling code into the API.

Ideally, the person that’s writing the API will have knowledge of the system internals, but not be the guy that wrote them. A fellow team member with passive experience to the code would be a good person, or ideally, a pair design exercise between the person that originally wrote the code and an API designer, with the consumer as a consultant.

Speaking The Same Language

Like a lot of software development, you make good progress when you get your terminology right and understand exactly what you’re trying to produce.  I’ve consistently found that the best way to think of a client facing API is as a orchestrating thin wrapper that summarises, in code, a set of business processes that you wish to expose to the public.

In order to get your API design right, you need to clearly define and agree on the boundaries of the system with both your internal team, and your consumers.  It’s important that you have a clear understanding of the following:

• The responsibility of the calling code
• The responsibility of the API layer
• The responsibility of the internal code the API makes calls to

This might sound like a really simple suggestion but I’ve taken part in countless discussions where people on both sides of the API just “presumed” that either the calling code or the API would perform specific functions (data cleansing, logging etc) when in fact, this confusion had lead to none of the implementers bothering to write the required functionality.  Make sure you know for certain what your API is responsible for doing.

Defining Your API – Tips and Tricks

Defining your API methods (or the “contract” of the API) is the most important thing to get right and there are several vital things to remember.

• Choose Your Names Wisely Using the language of the business
  
  It’s vital that your API methods speak in terms that the caller is going to understand.  Your API should be readable.  If your users go hunting for the documentation every time they want to use a method, then you’re probably doing it wrong.

  Clarity in naming is exceptionally important.  The names of your API methods should succinctly state what action that method call is going to perform.  Don’t fear using long method names, embrace them for clarity.  As a general rule, your pmethods should probably always be in the form DoSomething(object withThis);

  Ensure that when naming methods you reflect business operations in the method names, not the underlying implementation.

  Bad example:     void InsertToTblCustomer(string[] custDataValues);
  Good example:   void AddCustomer(Customer customer);
  Good example:   void DisableAccount(string accountId); 

• Don’t pretend to be a data access layer

  APIs should summarise business operations in a logical and meaningful fashion.  You are not a public facing data access layer and you should never pretend to be.  If your users want raw database access give them read only permissions on some tables and a copy of SQL Management Studio.  So don’t write methods for CRUD operations in your API (unless you’re writing some kind of online file management utility).

  Bad example:     void InsertToTblCustomer(string[] custDataValues);
  Bad example:     void UpdateTblCustomer(string[] custDataValues);
  There are no good examples!

• Avoid leaky abstractions

  This is a fundamental and simple rule – don’t expose your callers to anything that they’re not interested in or won’t understand.  If it’s not important, don’t show it.  Don’t code for things nobody will ever need and don’t require your callers to have intimate knowledge of data types or internal categories in your system.

• Create a data contract between you and the calling code
  
  I’m going to borrow some of the terminology from WCF here because I’ve found it an appropriate label.  Create a Data Contract library for use in your API.  This library should summarise the business process and the outward facing view of your software.  It might contain terminology that doesn’t actually exist in the software itself, but in the business processes that the software models.  Either way, this, and only this, should be the language that the API talks to your callers.

  Where possible, create this data contract in a separate assembly that’s entirely decoupled from your core system and distribute it to people that want to use your API.  This is especially beneficial when using WCF as your clients can generate a service proxy and deal in the same data types that you are in your API code.

  It should be the responsibility of the API layer to marshal the data from your data contract into the domain model of your internal components.

  You data contract should contain every type used to communicate with your API and the object model should be named in a way which is meaningful for the consumers.

  Because your data contract is NOT the object model of your internal components, you’re able to add properties and objects that don’t logically exist in your internal components.  This means that you can perform an operation using some internal component, gather the output in your API layer and then compose the output data in a meaningful way using classes written specifically for the data contract.  This way, by the time the user has access to the output data, it’s in a format and language which they understand.

• Support standards!  Don’t reinvent the wheel!
  
  Here’s a true story; while working with an API, my team was faced with the following API method:
  object Run(string request);

  It was the only method on the API, and “covered up” for around 30 methods all made available through one giant black hole in the side of the system.  Underneath that there was an XML format that the request had to be in in order to call the appropriate method.

  If you’re writing an API, stick to some kind of standards.  Ideally, expose a web service endpoint with an accurate WSDL that people can call or use a simple and obvious REST endpoint.  

  Please, please, please, do not make other developer suffer by rolling your own delivery mechanism.  We have enough of them, don’t confuse people by adding some more.  If you’re going to use a raw sockets connection, supply a calling library and stick to some standard middleware like WCF rather than rolling your own. 

  Thousands of people have spent thousands of man years writing code based on existing techniques, you’re not better than all of them combined.

  Reinventing the wheel is never good for anyone.

• Ensure that the user can retrieve values they’re going to want to modify

  The number of times I’ve used APIs that let me set or update objects without returning the current state of the object is mind blowing.  So always remember: If you’re going to let them set it, let them get it.  Providing an update or “upsert” method without allowing your consumers to query the current state of data in the system is a complete waste of time.

• Supply compiled libraries to work with your API documentation

  This may not always be possible, but it’s a really good idea to supply a sample implementation and compiled binaries with your API that covers the most common scenarios of usage.  Not only does this prevent the consumer from struggling to get to grips with you API, but it allows you to outline and illustrate a set of best practices for usage.  In an ideal world, the user could just use your sample code in their application, so ensure you license the code appropriately.

  This is an exceptionally good way to deal with any authentication your API may require as you have the ability to provide additional helper classes to perform some common tasks (authenticate –> perform action –> logout, for example).

• Keep your implementation clean

  Delegate the API logic to your middleware components / reusable libraries.  Do your best to ensure the API layer doesn’t actually contain the logic required to perform operations, just the logic required to marshal the data from the API format into your internal data structures.  The API should simply orchestrate calls to one or more internal methods because your API should simply be exposing existing functionality.

  If the API is exposing some new, API specific functionality, consider splitting this behaviour into a separate assembly or binary to aid testability.

• Consider dogfooding

  Dogfooding is the act of using the software you’re creating.  I worked on a project where we were developing an order placement system in ASP.net MVC, and as part of the design process we decided that we wanted to have an API that was a first class citizen.  It then dawned on us that in order to produce the API in a way that accurately mirrored the functionality of the website, we should have the website consume the API like any other client would.  The website had it’s own concept of user authentication, and when a user logged in, the web application logged in to the API as the current user.

  Doing this not only ensured that our security model was watertight, but that any additional web functionality would immediately be available to API users because they were actually the same thing.  On top of that, you gain confidence in your own API because you know that it’s called often by your own code, reducing the likelihood of users discovering bugs in your API because it’s not a product you actually use.

• Support atomic operations including rollbacks on failure

  When implementing your API methods, ensure that if an exception occurs or an operation doesn’t complete, the all the changes made by your API call are reversed.  Consider explicitly supporting transaction scopes in your API to let your consumers compose their own “set” of operations.

• Support bulk operations where appropriate

  Building support for bulk operations into your API can often prevent performance issues occurring later when a user tries to, for example, insert 10,000 customers sequentially.  Consider pluralising your methods, so instead of providing an AddCustomer(Customer customer) method, provide only a AddCustomers(List<Customer> customers); method.  Doing this prevents callers from overloading your system by bulking data through your API in unintended ways, allowing you to properly cache required data and cater for these bulk operations.

  This isn’t always appropriate, however I’d always strongly suggest offering pluralised versions of methods that you suspect may be used in bulk, in order to help optimise your API calls and reduce the amount of data being transferred over the wire.

• Logging as a first class citizen

  Don’t wait until somebody asks about API usage to decide to log it.  Build logging into your API wrapper, from the start, at the point of every method call.  It doesn’t need to be fancy, and you can use a number of freely available components to handle these logs and log rotation (consider using log4net or log4j for simple log rotation).

  Log each method call and some summary or identifiable element of the data passed to it.  This’ll help you profile API usage, and identify how data changed in your previously closed system.

• Security as a first class citizen

  Consider the security of your API from the start of the project.  Understand who will have access to your API, which organisations and which individuals.  Do you require roll based security?  Do you need a way to disable API support for specific customers?  Are you transferring data that needs to be encrypted over the wire?

  Beware of over baking your security.  WS-* offers some very robust packet level security features, but if your API doesn’t need them, or is restricted to an internal network, then don’t bog down your implementation in unneeded security.  Beware of making security choices that tie you down to a specific protocol or technology stack – you want to keep your API usable for the consumers.  Do the simplest thing that works.

• Have integration tests!

  Make sure you have integration tests with mocking at the business logic layer. These tests are for your API wrappers, NOT your logic. The logic should be tested independently, you’re just ensuring your API layer, marshalling and method calls operate correctly at this level.

  With any luck, your business logic should already be tested as part of your existing test suite (which you have right?) but if not, ensure the business logic is tested separate from the API code.

  Consider using a TDD or BDD approach to designing your API calls, designing the specification first in the form of some calling code, then write the code required to make your usage examples compile.  This will help you understand exactly what calls the client will have to make for to your API to achieve specific functionality.  These tests can happily double up as regression tests when you make changes to the API.

• Keep it simple!  If all else fails, do what the big boys do.

  Always strive to keep your API simple.  Pretend your the consumer at all times.  If you’re unsure of how to proceed, I’ve always found inspiration, both for what to do and what not to do, from reading the API documentation of some large companies that have widely used APIs.  It’s safe to say that the likes of Amazon, Google and Microsoft have had to put some thought into their API designs.  Beware of trusting their decisions blindly, but liberally borrow anything you, as a consumer, would find pleasing in your API.

I’m not going to try and convince you that by following my advice that your API design will be flawless.  I’m really hoping for a little discussion on this topic as it seems like something that is rarely covered and often “felt out” by the people left to implement APIs for the public.  These are just some lessons I’ve learnt on the way while implementing several public facing APIs.

Want to talk about APIs?  Send me an email!

A common complaint when faced with localizing ASP.net MVC pages is that littering your code with tonnes of runat=”server” tags breaks the “purity” of the MVC model.  Regardless of how meaningful that debate is, there is a way to achieve globalisation without server controls.

I’m going to walk you through a sample implementation which should hopefully make this clearer.  As a standard disclaimer, none of this code has been tested in a production environment and I wouldn’t advise implementing it blindly.

I’m going to attempt to play this out mostly in screenshots…

The Idea

• The required language is stored in a database / session / extrapolated from the Url route information
• Your view pages derive from the type TranslatableViewPage

• This page adds support for a LanguageCode property that you can make use of inside the view along with adding a class implementing ITranslator, a class that provides hooks into a translation database.

• This controller add a method called ViewInLanguage(string languageCode) that you use instead of View() or View(model) to return your Asp.net MVC view.

Class Layout

The following is built upon the standard Asp.net MVC starter project for the sake of illustration.

Implementation

First, configure the translation settings and register your translator…

You need to configure a fail-safe default language code and a type that implements ITranslator.  This translator will be responsible for doing the heavy lifting.  Ideally we’d add some inversion of control here to allow you to define the translator implementation at configuration time, but that’s outside of the scope of this example.  I’ve implemented a very crude resource .resx translator for the example.

Next, make your controllers inherit from TranslatableController

Once inherited, switch from using the View(); method to ViewInLanguage() passing in your desired language code (gathered from the user session / database / Url route).

Then set your view type (or derive your view from) TranslatableViewPage…

Once your view is inheriting from TranslatableViewPage, you’ll have access to an instance of your specified Translator and the LanguageCode inside the view which you can use in a manner similar to the built in HtmlHelper class to access your translated strings.

How It Works

The TranslatableController provides you with ViewInLanguage and when called generates the standard MVC ActionResult.  This ActionResult will be a ViewResult, which is then wrapped in a LocalizedViewResult wrapper class adding a LanguageCode.

When ExecuteResult is called on the LocalizedViewResult to render the view, the LanguageCode is placed in the TempData array in the TranslatableViewPage.  Then, when the OnInit(EventArgs e) method is called on the TranslatableViewPage, this LanguageCode is extracted and placed in the LanguageCode property on the page.  In addition to this the page provides a constructed instance of ITranslator which you can use in your views to source translated data as the page is rendered.

Source Code

Download Here

One of the most valued practices in software development is brevity.  Writing code is bad.  When you write code you create bugs, and creating bugs is bad.  The solution?  Don’t write much code.  Commenting your code however, has traditionally been seen as a “good thing”.  So much so that most modern programming environments make some provision for document generation and offer style-guidelines for commenting your code.

I believe, however, that excessive commenting is actually an anti-pattern and should treated with caution, and as far as possible, avoided.  I’m going to illustrate my point with a (somewhat contrived, but in no way unusual or outlandish) example.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace XmlDocumentationAntiPattern
{
    /// <summary>
    /// XmlCommentHell
    /// </summary>
    /// <example>var xmlCommentHell = new XmlCommentHell</example>
    public class XmlCommentHell
    {
        /// <summary>
        /// Description
        /// </summary>
        /// <remarks>String description of XmlCommentHell.</remarks>
        /// <example>instance.Description = "some description";</example>
        public string Description { get; set; }

        /// <summary>
        /// XmlCommentHell ctor
        /// </summary>
        /// <param name="description">Description string</param>
        public XmlCommentHell(string description)
        {
            // Assign description
            Description = description;
        }

        /// <summary>
        /// Gets the description property, but in reverse!
        /// </summary>
        /// <returns>Reversed description</returns>
        public string GetReversedDescription()
        {
            return Description.Reverse().ToString();
        }
    }
}

The context of this example is C# but similarly applies in other programming languages.

If you find yourself engaging in XML comments like the above example, I really believe “you’re doing it wrong”.  Why?

• Reduced code readability

  The Xml comment clutter in the code above actually reduces it’s usefulness.  The code now takes three times as much screen real estate to maintain and understand.

• Low signal to noise ratio - too many characters that add no value

  When you’re maintaining systems however large, the act of actually writing code takes time and adds maintenance overhead.  Past the visual unpleasantness the amount of mark up required to document relatively simple methods actually reduces the codes utility.  Only ever type ANYTHING in your IDE if it adds value.

• Incredibly obvious comments

  There’s a wonderful quote to the tune of “always pretend that the person that’s going to maintain your code is an axe wielding manic who knows where you live”.  I’d like to extend that by adding “so don’t insult their intelligence”.  There are few things I find as frustrating as reading comments that not only add no value but also make me feel like I’ve wasted a tiny piece of my life reading them.  Don’t waste your time or mine.

• Violating the DRY principle

  The DRY principle is very well agreed upon in software development.  Don’t repeat yourself.  If your XML comments just repeat your method signatures, you’re not only repeating yourself (and thus wasting time) but you’re leaving yourself open to a maintained nightmare as the code changes and the comments are left unchanged leading to confusion and misinformation.

• Possible misuse – the generation of utterly useless documentation

  When I see projects documented in this way I often joke that someone should run Sandcastle or javaDoc over the code to gain some tangible value in the form of MSDN-esq documentation.  I’m actually wrong.  This is a terrible idea.  Pop quiz time!  What’s worse than tedious documentation that adds no value?  Tonnes of hyperlinked documentation that adds no value!  Think of the poor developer wasting minutes to hours searching for the value in generated documentation before painfully realising that there’s none to be had.

I occasionally get met with some resistance when I state my opinion on this for a couple of reasons.  People often argue that they do it for the sake of intellisense and IDE tooling, that they do it for generated documentation or just out of habit.  I feel like these are all dangerous reasons.

Firstly, if you’re generating documentation for documentations sake, you’re either trying to please some form of middle management that doesn’t understand what documentation really exists for (hint: to help developers develop), or you’re wasting time.

Secondly, if you’re documenting methods for intellisense you’re probably missing the point.  See, intellisense and other IDE self-help mechanisms are very good; they’ll display method signatures and method names with minimal fuss, any extra comments you glue on top of every method will either clutter your GUI, or become ignored white noise, potentially leading to that one important comment going ignored as your developers slowly desensitise themselves to reading the human generated “auto-doc” garbage.

Finally, if you find that you need to cover your methods in comments because they legitimately don’t make too much sense at a glance then you’re falling foul of a different problem: you have code that’s not legible maintainable and clear.  In this case you’d be far better served by ensuring your methods are named well, take logical parameters and have single clearly defined purposes.  In my experience, whenever somebody says that they need to comment their methods because the method is unclear, they really should be refactoring, not documenting.

Please DON’T bury your code in comments, just keep it all readable ok?

A quick code snippet.  These two extension methods (C# 3.0+) enables you to return custom attributes from types, both on a specific type and any data type.  They both return null if the attribute is not present.  

The first extension is useful for extending a type of your choice.  It’s especially useful when considering Enums and the DescriptionAttribute, or other enumeration attributes (especially custom attributes).  The usage examples below should make the use more obvious.

The second extension allows you to return an Attribute from ANY type.  Use with caution, but I find it interesting that it’s actually possible to write an extension method that works that way.

    public static class ElementExtensions
    {    

        public static T GetAttributeValue<T>(this SomeConcreteType val)
        {
            var attributes = val.GetType().GetField(val.ToString()).GetCustomAttributes(typeof(T), false);

            T response = default(T);
            if(attributes.Length > 0)
            {
                response = (T)attributes[0];
            }

            return response;
        }

        public static TReturnType GetAttributeValueFromType<TInstanceType, TReturnType>(this TInstanceType val)
        {
            var attributes = val.GetType().GetField(val.ToString()).GetCustomAttributes(typeof(TReturnType), false);

            TReturnType response = default(TReturnType);
            if(attributes.Length > 0)
            {
                response = (TReturnType)attributes[0];
            }

            return response;
        }       
    }   

Some usage examples….

    public enum RegexEnum
    {
        [RandomAttribute("^(([a-zA-Z]{1}[0-9]{3,4})|([a-zA-Z]{2}[0-9]{2,3})|[0-9]{4})$")]
        SomeEnumValue,
    }   

    public class RandomAttribute: Attribute
    {
        public string Expression { get; set; }

        public RandomAttribute(string expression)
        {
            Expression = expression;
        }
    }

    private static void Example()
    {
        // Both of these are equivalent
        foreach(var enumMember in Enum.GetValues(typeof(RegexEnum)))
        {
            var value = enumMember.GetAttributeValue();   
            var valueFromAnyType = enumMember.GetAttributeValueFromType<RegexEnum, RandomAttribute>();
        }       
    }

Some nice syntactic sugar for use with enumerations.

I’ve previously provided a code snippet illustrating how to use WiX (the “new” Windows Installer framework) to install certificates onto the target machine.

I’ve had some good feedback about the post, but also had a request for a working example (in order to illustrate how the code fragment is used in an Installer.wxs file).

I’ve cooked up a sample visual studio solution that installs a test certificate (generated using the MSDN makecert certificate example “makecert -sk XYZ -n “CN=XYZ Company” testXYZ.cer “).

You’ll probably need to re-path references to the WixIISExtension and WixUIExtension in relation to your development environment but hopefully this should help you.

The previous post is the third most accessed post in my blog (which probably speaks as much for the number of people that read this as it does it’s utility) so this should be useful to someone.

It’s worth noting that this example installs the junk certificate as a Root CA so you might want to change that or ensure you remove it once you’re done.

Download the Sample Solution

I Know It Sucks, But You Need Requirements To Work

There are two parts of software development that really suck. Traditional requirements analysis and documentation. This isn’t some silly joke, both practices are terribly antiquated and essentially useless, not least in an agile (read: rapidly changing) project.

However, one of the common misconceptions I often hear when working on agile projects is stakeholders not quite “getting it” and thinking that agile is the same thing as requirement-less development.

However you paint it, you need something that resembles requirements to write code with. Requirements needn’t be exhaustive, and in an agile environment are rarely ever final, but you need to know what you’re working on- the average user story isn’t going to cut it.  User stories are designed to start conversation between the developer and the stakeholder but you need to do something with the detail once you have it.

Make The Requirements As Accountable As You Are

You know what else sucks? The fact that most businesses don’t have any kind of document management strategy. Sure, you do, you’re a developer. You have source control (and if you don’t, go take care of that now), you’re accountable and auditable line by line, check-in by check-in. This same rigor rarely extends to other areas of businesses (though it should).

When all is said and done, if you’re maintaining a traditional requirements document for your project you’re probably already making a big mistake. Who owns the document? How do you track changes? How do you know people haven’t changed the requirements without a reasonable discussion? What happens when somebody accidentally deletes it?

Requirements documents are the “Excel Applications” of development. They’re unreliable, often so large that nobody will ever read them, and as such fundamentally useless. It’s a bit of a trick question really, monolithic requirements documents are about as “Write-Once-Read-Never” as most Perl code.

I Think We Have a Problem…

So lets recap. Requirements documents are evil and nobody reads them, but you need requirements to develop. Requirements documents aren’t auditable yet it’d really be a good idea if they were. Oh and documentation sucks.

You Need Wikimentation!

Wikimentation is a particularly amusing portmanteau but what you need is a wiki and if you do it right, you’ll never have to write documentation again.

In an agile project, the requirements are meant to evolve and change as you go, so they deserve to be stored in a format that naturally leans towards allowing the users to do just that.

There’s also an immediate bonus to either you or your business analysts in the way requirements are captured as a traditional requirements capturing exercise is eschewed in favour of documenting requirements as they become relevant. This is a very natural way of working and allows you to prototype or stub out components until you need to delve into detail (in fact, doing this is very much the SCRUM way).

When I approach a new project I like to keep a few things in mind, I’ll call them the Holy Trinity of software maintainability…

The Holy Trinity Of Software Maintainability

• Readable Code
• Good Developer Documentation
• Source Control

So how will a wiki help you get there?
I’d argue that after the implementation of a set of requirements, the requirement and it’s details have effectively been superseded by the precedent set in the code.

Those requirements you coded to, after implementation are useless. If the code doesn’t adhere to the requirement the code is buggy, and your bug tracking system should contain information explaining why.

If the code is correct, the requirements would be classified as obsolete. Keeping them around only serves the purpose of misleading anyone who attempts to read the requirements to establish the coded behaviour of an application.

So what we do is we maintain the list of requirements in a wiki in a slightly less formal manner. This is hypertext remember, big long lists of stuff are so 1990. Use links and divide the content into requirements for logical components, leaving a well maintained index on the project homepage in the wiki.

Now as features are completed instead of the requirements eventually rotting away into irrelevance, they can be replaced by a simple developer commentary of the implementation. As you follow this pattern, your requirements will develop into a solid set of searchable developer documentation at the same rate as your project progresses.

Constructing Your Own Evolving Requirements Wiki

There are plenty of FOSS and OSS Wiki platforms out there. I have a personal preference for ScrewTurn Wiki on Windows and you can be up and running in literally under 5 minutes (web server not even required).

A few simple guidelines

• Ensure that the home page of your wiki clearly links to the discrete sub projects or components you’re developing
• It’s encouraged to create wiki links for content that doesn’t exist but needs elaborating on by yourself or your team, to serve as a visual reminder of what is left to do
• Create a standard template for a project and component wiki page
• Populate each of your component wiki pages with the top level requirements for that component, along with “pre-links” to any sub-components of specific note or percieved complexity
• Encourage your developers to document as they write
• Don’t duplicate code comments or huge chunks of code in the wiki - that’s what clean and readable code is for
• Do encourage the posting of examples for reusable or common components - share individual developer knowledge

The wonderful thing about using a wiki is that it breeds accountability. Modifications are logged and audited; you can always see the history of any given page, from requirements to documentation.

A wiki will provide you with a sound and adaptable framework for producing project documentation that evolves with your project. Used in conjunction with a good bug tracking system, a good version control system and some good developers, you’ll have a good chance at edging closer to that holy grail of maintainable well documented code at low cost.

Zero Friction Documentation

Your developers won’t resent a little bit of writing as they finish off logical units of work, and it could be even encourage to keep a “scratchpad” of information on the wiki as opposed to paper-notebooks. It’s also good to remember that you can always generate a traditional requirements document from the content stored in the wiki if an occasion calls for it.

I’ve had a lot of success implementing these ideas in past projects (both agile and none agile) and I’d certainly recommend it.

Fear Of Deployment

When you start working on a new project there are four really important pieces of information you should be aware of regarding the deployment of your software

1. Are you unafraid of deploying your code to production?
2. Do you know how your code will react in your production environment with production configuration?
3. Does your code react in the same way in your production environment as it does in development?
4. Are you confident in the repeatability of your installation procedure?

Fear and uncertainty in the deployment of software projects is a common theme I’ve seen across all the companies where I’ve worked and it’s never good for your project.  The fear of deployment is always a good indicator of the confidence your staff have in the project they are working on.

A project with unknown qualities and suspicious (or known but unreported) bugs often causes an serious fear of deployment.  There’s nothing like the fear of deploying an application and reducing a business critical system to it’s knees.

I’ve worked on a handful of projects where I’ve taken it upon myself to reign in this deployment fear and chaos, and more often than not, the fear has it’s roots in an uncontrolled development environment.

Configuring A Development Environment

I have very few suggestions regarding which tools you should use to develop your software.  I think that you gain the maximum benefit by allowing developers to pick and choose the absolute best tools for the job, be that technically or by preference.  Allowing developers to use their tools of choice makes happy developers.

By contrast however, the one thing I’m really certain about is that every development environment should start with an absolute base configuration that should not be changed.  This is the first way to solve the eternal “works on my machine” developer problem.  In essence, if all the development environments start off the same, there’s no excuse for a “works on my machine” error.  Not only will this reduce friction between team members, but it’ll speed up the development process because you’re all working to one known configuration.

Furthermore, the development environments alone shouldn’t share this configuration, they should share the base configuration with your production servers.  A huge percentage of software release issues are relating to the differences between production and test and development and the only way to solve what amounts to human error is to make this discrepancy go away.

In the current IT landscape where virtualisation is painfully simple (and often free) there are no excuses not to have a development environment (or at the very least development staging virtual machine) that accurately and completely mirrors your production server.  If you’re struggling with licenses of third party software, produce mocks / proxies / approximations.  I can assure you that the time you spend building these glorified testing rigs will work healthily towards eradicating development-to-production errors.

If It’s Worth Doing Once, It’s Worth Doing Three Times

Another nasty pattern I see frequently is the development-to-production pattern.  If you’re compiling software on your development machines and releasing it to production, “you’re doing it wrong”.  What’s worse than a “works-on-my-machine” conversation with a colleague?  You got it, a “works-on-my-machine” conversation with a system administrator.  It’s not an excuse.  Stop it.

You need to start dog-fooding your deployments, and this means environment cloning and real test servers.  I always follow a simple pattern; developer machine -> developer test box -> system-test box -> user acceptance test box -> production.

In order to do this you’ll need a series of environments (physical or virtual)

• Developer machine
• Developer environment
• Test environment
• UAT environment
• Production environment

That might sound like a lot of hardware but it really isn’t.  Use virtualisation and use it well.  Clone your virtual environments if need be.  Use snapshots and rollbacks to test deployments.  It shouldn’t take any time to administer (and I’ll explain why in the next section) and by the time your code is running on production you’ll have moved it through three different environments.  This is absolutely key to having faith in your deployment procedures.  When you’ve deployed your code so many times that you’re sure it works, in an environment that’s a mirror image of production, production is a far less scary place to be deploying to.

The key to this technique is that the environments all have very clearly defined purposes.  The developer produces his code changes to a system on his development box.  The code seems to work so it’s deployed to the developer environment and checked into your source control repository.  The development environment should be treated as a place where things could potentially get messed up, but it’s also a good place to host joint resources (a database, some middleware) that all the developers make use of.  If the code works in the developer environment it can be promoted to the test environment for the system tester (or a developer wearing a system testers hat) to test.  Once passed on the test box, the code changes can be promoted to the UAT environment for users to preview coming code releases.  Once these changes have been accepted, the code is released into production.

Beware of release insanity.  It makes perfect sense to frequently deploy to the developer environment but only occasionally promote code up to test and UAT.  This should fit around your way of working, just be sure to keep the conceptual integrity of the environments.  If you find a bug in test, don’t fix it in the test environment, fix it in development. It’s up to you to ensure you know what code is running across your environments to avoid any nasty surprises.

One Install To Rule Them All

At this point you’re probably thinking that this all sounds like a huge amount of effort but it isn’t.  The reason it isn’t is that you should, for the most part, be able to deploy your entire system in about 5 clicks / commands.  Don’t let your deployment mechanism be the week link in your application.  There are tonnes of install technologies on the market, both free and costly, to match whichever platform and tool chain you’re working in.

I wish I could remember where I read it, but one of the pieces of setup advice I read long ago that always stuck with me is that you should aim for a one-click install.  You might not achieve it, but you should aim to get very very close.

You need to invest time in configuration management for your application.  Build tools to auto-generate configurations for your deployment environments, build tools to automate setup and deployment.  These tools are worthwhile, because from the moment they’re built, you never need to worry about deploying your software.  They remove risk, and anything that removes risk from software development should be embraced.

Once you’ve build these tools and installers you’ll find your able to do things that you only thought were possible in large companies with seemingly limitless resources.  You’ll be able to configure nightly builds using a continuous integration package of your choice and have the nightly builds install themselves in your developer environment,  You’ll be confident that at any point you can provide a working copy of your software on request.

No Fear Of The Unexpected

The wonderful benefit you get at the end of this process is confidence in your software.

So you’ve released your system to production, do you then feel the need to slavishly test the system in the live environment? 

Imagine that urge going away, knowing that by the time the code hits production that any environmental glitches that could manifest have had the ability to fail three times already.  Any amount of cursory testing you could perform at this point should pale in comparison to the testing you did in the test environment and the user testing environment.  If your “at a glance” testing somehow discovers a bug, you’ve done something very very wrong in the lead up to release.  You should be confident in the fact that your code has been run exhaustively and often by the time it’s reached production.

The world isn’t perfect however, and it’s obviously advisable to a quick audit of the software once installed, just don’t force yourself to repeat your system tests in production (an obvious anti-pattern) and you’ll gain no benefits from doing so.

If you can devise an automated tool to verify your deployments after install, you’ll be able to round off your sense of deployment-security.

A Zen-like State Of Satisfaction

I opened this piece with a few simple questions.

• Are you unafraid of deploying your code to production?
• Do you know how your code will react in your production environment with production configuration?
• Does your code react in the same way in your production environment as it does in development?
• Are you confident in the repeatability of your installation procedure?

I can answer yes to all three questions because I understand my environments and I hope you can too.

Recently I’ve been trying to pay a debt of sorts.  I use the software provided on the fantastic XDA-Developers frequently on my Windows Mobile devices and have been doing for almost three years now.

So currently, if I have a little bit of free time, I’ll nip past their development section and try and fulfil a random request.

Today’s request might come in useful to a little bit of a wider audience so I’ll post it here.  The initial problem is outlined in this thread and the upshot was that someone needed a very simple Http server that could run on Windows Mobile, written in C#’, and was programmable.

What the guy really seemed to be looking for was something that used the Http protocol to return random computed data, so after a tiny bit of googling and a simple MSDN example, I’ve built a really simple web server for Windows Mobile.

Amusingly, my sample doesn’t behave much like a web server at all.  It just tells you what you requested, but it should be enough to get you going in the right direction.  It’s derived from the MSDN example with some additional sugar, and I certainly wouldn’t suggest that it’s got a threading model that’d stand up in a production environment (at a glance it looks like it’d process requests in sequence…) but hopefully it’s useful to somebody looking to produce a simple server, or who is just interested in how Http works.

I’m not really sure if I can accurately call it a webserver, seeing as it doesn’t even support a full set of Http Verbs, but you get the idea.

I’ve not actually bothered compiling this on a mobile device yet (lack of inclination) however seeing as it was explicitly based on a socket programming for Windows Mobile MSDN example, I suspect it’ll work just fine.  No warranty, do what you will with it.

Download Simple C# Http Server for Windows Mobile (Source Code Only) (7kb)

I’ve been working with WiX ( wix.sourceforge.net ) for generating application installers over the past few weeks.

The project is rapidly evolving (if I recall, it was one of Microsofts first forays into open source development) but as a side effect finding up to date documentation can be a little taxing. The documentation is good and quite comprehensive, but often subtly incorrect or outdated.

Anyway, we have a few services at work that require certificates to be installed at install time into the Windows certificate store. Previously we had a couple of custiom actions designed to configure the user and store, but after a little investigation it appears like this functionality comes for free in the Wix toolkit.

It’s confusingly in the IIS extensions, which is a bit of a misnomer- it’s only in there because it was originally designed to install certificates for web servers, however it works perfectly for any certificate.

So how do you do it? In Wix3, ensure you first have a reference to WixIIsExtension.dll (in the default install, it’s in c:\Program Files\Windows Installer XML v3\bin) in your project if you’re using voltive, or manually linked if you’re building on the command line. The following example is of a fragment which installs two certificates, one as a Root certificate authority and another as a certificate in local machine.

<?xml version=”1.0″ encoding=”utf-8″?>
<Wix xmlns=”http://schemas.microsoft.com/wix/2006/wi”
xmlns:iis=”http://schemas.microsoft.com/wix/IIsExtension”>

<Fragment>
<Directory Id=”Directory_Certificates” Name=”Certificates”>
<Component Id=”MyRootCert.cer” Guid=”*”>
<File Id=”MyRootCert.cer” Name=”MyRootCert.cer” Source=”..\..\Path\To\MyRootCert.cer” />

<iis:Certificate Id=”Certificate.RootCA”
Name=”MyRootCert.cer”
Request=”no”
StoreLocation=”localMachine”
StoreName=”root”
Overwrite=”yes”
BinaryKey=”Certificate.RootCA.Binary”
/>

</Component>
<Component Id=”RandomCert.p12″ Guid=”*”>
<File Id=”RandomCert.p12″ Name=”RandomCert.p12″ Source=”..\..\Path\To\RandomCert.p12″ />

<iis:Certificate Id=”Certificate.MnpTestCertificate”
Name=”RandomCert.p12″
Request=”no”
StoreLocation=”localMachine”
StoreName=”personal”
Overwrite=”yes”
BinaryKey=”Certificate.RandomCert.Binary”
PFXPassword=”myCertPassword_Optional”
/>

</Component>
</Directory>

<Binary Id=”Certificate.RootCA.Binary” SourceFile=”..\..\Path\To\MyRootCert.cer” />
<Binary Id=”Certificate.RandomCert.Binary” SourceFile=”..\..\Path\To\RandomCert.p12″ />

</Fragment>

<Fragment>
<ComponentGroup Id=”Component.InstalledCertificates”>
<ComponentRef Id=”MyRootCert.cer” />
<ComponentRef Id=”RandomCert.p12″ />
</ComponentGroup>
</Fragment>

</Wix>

Ever wanted to generate a change log from all your (dubious) Subversion repository comments?  For some reason want to do it in C# or just by calling an exe?  Now you can!  You can even tie it in to continuous integration!

About 6 months ago I spent an evening porting the Subversion Change Log generator to C# in order to integrate Change Log generation it into our Cruise Control.Net nightly builds at work.

It’s not a direct port, more a C# reimplementation, but it produces the same output as svn2cl (which in itself was inspired by cvs2cl).  The gist is, that it calls svn.exe on the command line and retrieves the full history of comments for whichever svn path you request.

It’s not the most elegant thing I’ve ever written (it pretty much just spawns the svn.exe and pipes the output through an XSL transform) and requires you having a command line svn.exe on your system (which if you use subversion on windows is pretty likely), but if you do you should be able to generate change logs from your repositories by calling the compiled executable like so:

SubversionReportProducer.exe –style=ChangeLog.xsl –outputLocation=out.txt –repositoryPath=svn://repo/trunk

If you don’t want to pass the subversion exe path and repository path through on each execution you can specify them by modifying the values in SubversionReportProducer.exe.config.  Those values will always attempt to load from configuration, and then attempt to load from a command line parameter (overwriting any app.config settings) allowing for maximum flexibility in batch scripts and automation.

I’ve bundled it with a couple of XSL transform files to produce some output, mostly taken from svn2cl and one subtle adaption that we use in our build process (ingeniously named changelog.xsl).

Your mileage by vary, but this could well be of use to someone.

Source code provided, feel free to contact me about any bugs but I’m pretty much just kicking this out into the wild..

Download Source
Download Compiled Executable
Requires .Net 2.0+