Becoming Agile

Message Passing

noreply@blogger.com (Neil Bourgeois) — Sun, 15 Mar 2009 20:54:00 +0000

After a week of hiatus from SICP I opened up the book to another blatantly simple yet profoundly important concept: Message Passing.

Essentially the authors talk about passing around "intelligent data objects" that can dispatch other procedures based on the operation name. The implementation in LISP is simply passing a procedure around that accepts the name of the required operation and through a switch calls the appropriate behavior implementation.

This technique is called "Message Passing" and seems eerily familiar to the way methods are dispatched in OO.

Read for yourself by following the link and scrolling to the bottom:

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4.3

Abstraction: The Sunshine of your Code

noreply@blogger.com (Neil Bourgeois) — Fri, 20 Feb 2009 20:44:00 +0000

As part of a "back to basics" kick I'm currently reading Structure and Interpretation of Computer Programs. This book is a gem and although I'm only through the first two chapters I've been fascinated several times by fundamental and obvious programming concepts that I seem to have overlooked as my career progressed beyond those carefree University days. I'm particularly absorbed in the author's consideration of abstraction.

Abstraction is something I have personally taken for granted even in University. Recalling lectures where profs used analogies of the abstraction of cars or TVs I approached the topic with the blasé "Ya, ya, ya we get it... lets get to the code!" attitude. Now seven years later this book has caused me to reflect upon abstraction and realize that it is the fundamental ingredient of nearly every advancement in the construction of software.

The core idea is in creating Abstraction Barriers to speak a different language in each layer. In doing so, we can work most efficiently with the software itself and more importantly with other humans (of which most are computer language illiterate). To steal the authors' example at the highest level we can all speak about rational numbers, create them, add, subtract and multiply them. Anyone can "program" a calculator to make rational numbers dance. But there's a special class of people we try to avoid at parties who know that a rational number is comprised of a numerator and a denominator. Further there are the computer scientists who would look at a rational number as some kind of pairing of two integers. Now consider that each computer scientist may choose to implement a rational number a different way. Does this change the way the mathemetician's work with numerators and denominators? Does it change the way the average person does math? Absolutely not. But it may be the reason us computer science nerds don't even get invited to those parties.

In essence Abstraction Barriers are the driving force beneath Design by Contract and Interface Driven Design. Object Oriented languages are based on abstraction as there is no inheritance or polymorphism with out it. Even the often abused principle of encapsulation is about protecting the abstraction barrier. Abstraction is the foundation of every OO design pattern ever invented as a design pattern is just summarizing algorithms into a vocabulary. Even the cornucopia of patterns that emerged from Fowler's PoEAA and Evan's Domain Driven Design are again just abstraction barriers applied.

Consider, for example, software engineering tenants such those found in the Domain Driven Design camp which are some of the most powerful tools introduced to software engineering. Layered architectures and Bounded Contexts compartmentalize subsets of Ubiquitous Language into abstraction layers. Each layer or bounded context has a particular language used throughout. For example, Persistence Ignorance is keeping the implementation of physically storing data out of the realm of those who speak about domain and into the realm of those who speak about databases. Knowing the power of abstraction its possible to take the fundamental concept and apply it to your own design techniques.

Quite a while ago I learned the exercise of anthropomorphising software components to help break down software design. I've just recently started to consider abstraction barriers as part of the excercise with great success. For instance, I'm always running into the nagging question of "Where does this particular piece of code belong?". Now, while playing the part of each object in the orchestration I pay attention to the language being used (that is the verbs and nouns of each component's vocabulary) along with the data in play and try to find the lines between abstraction layers. It becomes quite obvious when you've crossed a barrier as the language will change and finding where a piece of code belongs is a simple as identifying components that have the same vocabulary.

For example, on my current project we have a 3D control that works in terms of Geometries. We also have components that can be drawn in this control such as Pipes, Elbows and Tees. The 3D control works entirely with Geometries knowing nothing about Pipes, Elbows or Tees. Conversely Pipes, Elbows and Tees know nothing about Geometries. Here we have two abstraction layers, lets call them the 3D layer and the Domain layer. If I find myself with a piece of code that does something with Geometries its fairly obvious that it should be grouped with the 3D layer. Or more likely I'm tempted to throw some code that works specifically with Pipes on the 3D control. During an intense anthropomorphise excersise this would raise a red flag as the 3D layer doesn't include Pipes in it's vocabulary. I should relocate that code to a service in the Domain layer so the language is consistent. I could then inject the service into the 3D control so it can call on the service to achieve its goal.

As you can see abstraction is a powerful tool for software engineers, and definitely not a concept to be overlooked. So for you kids out there, don't be like me. Treat abstraction with the respect it deserves. For those out in the industry who have forgotten about it whether you read SCIP or not give abstraction a second thought.

If you're interested you can also watch the videos at http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/. They're worth a viewing if at least for a chuckle at the stylish '80s stashes.

Using Feature Branches

noreply@blogger.com (Neil Bourgeois) — Sat, 14 Feb 2009 00:37:00 +0000

One of the biggest changes we've made to our development process in the past month was to introduce feature branches. Historically our team ran with two branches: the trunk and a production maintenance branch. All new development occurred on the trunk while bug fixes were committed to the maintenance branch and merged down to the trunk. This was a somewhat successful approach in that it's simplicity was perfect for a team that had little experience with version control but it suffered one annoying problem: the trunk was largely unstable.

The first indication that we had a problem was that deployment became a timely event. We would wait until there was low risk that the trunk had bugs in it, close our eyes, pray to our respective gods and slam our fists on the big red deploy button. Sure enough there'd be a partially completed or untested feature in the package that would cause problems down the line.

This led to Code Freezes and the Scheduled Commits anti-patterns. Where around deploy time we'd have to postpone the risky commits in favor of the solid bug fixes. From a lean perspective this is a huge waste as there was code just waiting to be committed to the repository and a developer surfing Facebook waiting for Cruise Control to scream out "Woo hoo!".

So, we decided to try using feature branches for new development. A feature branch is simply a branch that has all of the changes from the trunk plus all of the changes required to implement a particular feature. When the feature has been tested and is ready to be released we merge the branch back to the trunk and delete it. The end result is that the trunk stays stable even while new development is occurring because the feature branches are the ones assuming the instability.

Remember: Branches are like puppies so don't create a branch unless you're prepared to take care of it.

The maintenance costs of a branch are that every day or two a developer has to merge all of the changes from the trunk up to the branch. With Subversion 1.5 this is simple task but you should be aware that it could result in a couple of problems. First, you will likely run into situations where a single file changes on both the trunk and the branch resulting in a conflict. These conflicts are no different than the conflicts you receive while doing an svn update and can be resolved as such. Another more severe problem is that changes can be lost if a file is removed on the trunk but changed on the branch. Unfortunately there is no easy way to detect this other than to scan your merge log for deleted files. I have not yet personally experienced this problem but I am hoping that if it does occur my test fixture will catch it. Finally, performing a large merge is much harder than small incremental merges, so merge often! Depending on your team size and the amount of change on the trunk you'll want to tweak your merge frequency. My team is currently merging every day or every other day depending on the state of the trunk. Plus we always make sure to merge the trunk to each feature branch after another feature branch has been merged down to the trunk.

Remember: Merging works with a range of revisions so when merging from the trunk to the branch you need to include ALL revisions since the last merge not just the HEAD revision.

Subversion mergeinfo tracking in SVN version 1.5 makes feature branches a breeze. I remember using feature branches under early SVN builds (and even CVS ) where we would have to track which versions were brought up to the trunk on an index card so we wouldn't duplicate efforts. Now the mergeinfo is tracked inside of SVN properties and SVN is smart enough to handle these tedious tasks for us. So just make sure your working directory is clean and from it run:

svn merge svn://svnserver/myrepository/myproject/trunk

Sometimes, however, you will want to know which revisions have been applied. In this case you can run the following command from your branch working directory to get a list of revisions merged up to the branch:

svn mergeinfo svn://svnserver/myrepository/myproject/trunk

Similarly you may want to know which trunk revisions are eligible to be merged onto the branch. In this case you can run:

svn mergeinfo svn://svnserver/myrepository/myproject/trunk --show-revs eligible

Remember: A small incremental merge is far easier than a massive merge, so merge often! Don't wait until the end of the feature to sync up your branch. You WILL feel pain.

The final task in feature branch maintenance is after the feature has been developed you will need to merge it down to the trunk. This is a step in our Kanban that occurs after Peer Testing but before UAT. In other words we are committing zero defects (as far as we know) to the trunk. Since our branch already contains all the changes from the trunk that occurred during the development of the feature the only changes that need to be merged down are the ones that belong to new feature. The beauty of keeping your branch in sync is that this happens natually in SVN 1.5 by running the merge command with the reintegrate flag from a clean trunk working directory:

svn merge --reintegrate svn://svnserver/myrepository/myproject/branch

Once the branch has been merged down to the trunk you will want to make sure that no more change occurs on it. This is accomplished by simply deleting the branch. It will remain in your repository so you can always browse back to find those changes but developers will not be able to check it out and commit against it.

Thats about all the mechanics there is to feature branches. But the question remains how do we know when we need to create a new feature branch? This is more of a fuzzy area. Some teams branch for every Story but the granularity of these branches is really dependant on what and how often you will be releasing. In general my team will create a feature branch based off a portion of a Stories in a Theme or Epic that should be released together. We call these chunks Minimally Markettable Features and we choose each one so it takes about an iteration to complete. So our feature branches deliver a useful feature to the business every 2 weeks.

The early results show that feature branches have greatly improved our ability to deliver stable releases and in turn make our client much happier. Our testing efforts are far more efficient since UAT now contains stable changes and there is no waste in developer cycles due to Code Freezes or Scheduled Commits. The downside is that feature branches require much more SVN savvy. To successfully implement feature branches your development team should be fairly experienced with version control systems. If your team is struggling to manage a trunk and a single maintenance branch then I would recommend mastering that before using feature branches.

If, however, you feel your team is ready for the next step and would like to implement feature branches I highly recommend reading the branching topics in the Subversion Book. Also get your hands dirty and play around with branches in a sandbox svn repository. You'll quickly get a feel for how they work and what they're all about. Lastly, drop me a line if you're have any questions.

Becoming Lean

noreply@blogger.com (Neil Bourgeois) — Sun, 18 Jan 2009 15:57:00 +0000

I've spent the past three years building up an internal software development team. This team was built with a foundation of principles instilled by XP-styled Agile (or as they were ingrained in me by ThoughtWorks). The team has changed dramatically over the three years, ever increasing in size, skill and agility. We are currently running with what I would consider to be a dream team. Each team member is a skilled and experienced generalist and everyone on the team either has 2+ years of agile experience or is an apt and enthusiastic participant in their own learning process. I couldn't be more excited about our future prospects and what we will deliver to the business in the coming months.

But even fielding this roster we experience some Agile anti-patterns that turned into pains for the team. An analysis of these anti-patterns is leading us towards a Lean Kanban style and away from the traditional Agile. I know there is not much out there about making this transition so I will try to document as much as I can to help others who are attempting the same thing.

The first of our pains was that we could not get a stable velocity. It was not uncommon for us to have a huge variance between iterations... embarrasingly so.

Iterations always seemed to result in hangover and the perpetual work in progress made testing very difficult. Not to mention cutting releases was difficult when they contained half completed work.

When we switching into maintenenance mode between phases everything went out the window. We moved into chaos mode and during this time there was some team churn (for the better) that changed the entire dynamics of the team so any historical metrics were rendered useless. Not to mention our rhythm, and I believe the inertia behind a strong rhythm is important to a dev team.

Finally, while our development team is Agile the business is hunkered down in a Waterfall mindset. They fear fast and cyclical releases opting for several big-bang releases per year. Admittedly we haven't done much to quell those fears since the work in progress problem plagues our own testing process. But even if those fears were gone the business has a gated approval process better suited for the space shuttle than it is for software.

We tried to band-aide these pains. For example we tried to fix the varying velocity by accounting for half-completed stories (Story A is %65 complete) to give a more realistic velocity. We injected empty buffer iterations to allow for work in progress completion and stabilization. We tried to estimate bugs and maintenenance work but unfortunately metrics taken during this span were used to estimate the schedule dates for future development work. As for the waterfall business problem there was unfortunately nothing we could do to reduce the release cycles. Perhaps the real problem is that changing the business is beyond the team's sphere of influence at this point and we have to earn the business' trust before that can be fixed.

After looking at these problems from a root-cause perspective we have decided to focus on the following principles:

Reduce work in progress
Zero defect mentality
Kaizen

We've also decided to switch to an iterationless Kanban system because it more closely represents the way we are working. In a subsequent post I will go through these principles and describe how we expect them to work in concert with Kanban to improve our process.

To be continued...

ClickOnce in General

noreply@blogger.com (Neil Bourgeois) — Sat, 01 Nov 2008 16:46:00 +0000

I've had many emails lately about my ClickOnce deployment using NAnt post so I thought I'd post a little bit about how ClickOnce works in general.

First, there are two files necessary to deploy a ClickOnce app: the deployment manifest and the application manifest. The deployment manifest contains version specific information about your app. This is the file that makes version 1.2 different from 1.3. You should have one deployment manifest for every version you deploy.

The application manifest, however, is really the main entry point into ClickOnce. It contains information about which version is the most recent (eg. 1.3) and redirects the client to the appropriate deployment manifest. You will have just a single application manifest for your project. It is the URL of the application manifest you should give to your users so they can open the application.

The tricky thing about ClickOnce manifests is that in addition to containing a list of files necessary to run an application they contain a hash of each file. This hash is like a digital signature and used to prevent ClickOnce from delivering malicious files. So, any time you release a new version (or change your ClickOnce payload) you must do the following (using Mage):

1. Create a new deployment manifest (for the new version)
2. Sign the deployment manifest (to regenerate the hash of each file)
3. Update your application mainfest (so it points to the new deployment manifest from 1)
4. Sign your application manifest

Once that is done you're pretty much good to go :-)

Also, for further reading my colleague Jonas Avellana has a great post on setting up ClickOnce to deploy to multiple environments.

Binsor Method Interceptor Macro

noreply@blogger.com (Neil Bourgeois) — Fri, 06 Jun 2008 02:36:00 +0000

So, I just picked up a story that is one of those really annoying feature requests-- you know the kind: adding log statements to analyze performance of about 40 key use cases scattered all over the app. Its the kind of story every developer dreads and the worst part is that it is throw away code. In a week when data has been collected there will be another story coming down the pipe to revert those changes. While I could've spent the day hunting down the 40 culprits and performing mind numbing cut and paste code injection I decided instead to attempt an implementation that would stick around and have potential uses in other scenarios.

Since our application uses Windsor entirely configured through Ayende's Binsor scripts I figured I'd take a stab at writing my own binsor macro for interceptors. The functionality I required was that only specific methods of a service need to be logged for time and occasionally other contextual information dumped.

I know I could perform the same action by creating a class that implements IInterceptor and registering it in Binsor like:
IoC.Container.Kernel.GetHandler('textProvider').ComponentModel.Interceptors.Add(InterceptorReference(MyInterceptor))

But I wanted something more flexible. Ultimately I want to be able to craft a custom binsor config file and not have to perform any code changes. This way when the story comes down the pipe to revert changes it is as simple as replacing a config file. Additionally having the ability to throw interceptors on specific methods is an enticing feature should we ever need to peer down the business end of the app running in production.

The syntax I was after looked something like this:

component 'textProvider', ITextProvider, HelloWorldProvider:
intercept 'GetText':
Log.Info('Invoking: ' + invocation.Method.Name + ' at ' + DateTime.Now())
stopwatch.Start()
invocation.Proceed()
Log.Info('Duration: ' + stopwatch.Stop())

Make sense? If not, I'll paraphrase in English: I want to intercept the GetText method on my ITextProvider service and perform the block of code that logs the invocation, lets the invocation proceed and then logs the duration of the invocation. Essentially my goal is to inject that block of code as a delegate into a class implementing IInterceptor. Its actually easier than it sounds!

The first step was to create the MethodInterceptor. This is the class that implements IInterceptor:

   public class MethodInterceptor : IInterceptor
    {
        public delegate void InterceptHandler(IInvocation invocation);
 
        private readonly string methodName;
        private readonly InterceptHandler interceptHandler;
 
        public MethodInterceptor(string methodName, InterceptHandler interceptHandler)
        {
            this.methodName = methodName;
            this.interceptHandler = interceptHandler;
        }
 
        public void Intercept(IInvocation invocation)
        {
            if(methodName.Equals(invocation.Method.Name))
                interceptHandler(invocation);
            else
                invocation.Proceed();
        }
    }

Notice the delegate? Thats the magic... otherwise, its pretty straight forward.

Step 2 is to create something that will do the Windsor configuration for us. This class needs to:

Add a new component for the interceptor
Add the dependency values to the interceptor component's configuration
Register the interceptor component as an interceptor on the parent component

If you are unclear about interceptors in Windsor I suggest reading up on them in the Windsor documentation.

   public class MethodInterceptExtension : IComponentExtension
    {
        private const string INTERCEPTOR = "interceptor";
        private const string INTERCEPTORS = "interceptors";
        private readonly MethodInterceptor.InterceptHandler interceptHandler;
        private readonly string methodName;
 
        public MethodInterceptExtension(string methodName, MethodInterceptor.InterceptHandler interceptHandler)
        {
            this.methodName = methodName;
            this.interceptHandler = interceptHandler;
        }
 
        public void Apply(Component component)
        {
            var interceptorKey = component.Name + methodName + "Interceptor";
            AbstractConfigurationRunner.IoC.Container.Kernel.AddComponent(interceptorKey, typeof (MethodInterceptor));
            AbstractConfigurationRunner.IoC.Container.Kernel.GetHandler(interceptorKey).AddCustomDependencyValue("methodName", methodName);
            AbstractConfigurationRunner.IoC.Container.Kernel.GetHandler(interceptorKey).AddCustomDependencyValue("interceptHandler", interceptHandler);
            AddInterceptorConfigItem(FindOrCreateInterceptorsConfigItem(component), interceptorKey);
        }
 
        private static IConfiguration FindOrCreateInterceptorsConfigItem(Component component)
        {
            foreach (IConfiguration configChild in component.Configuration.Children)
            {
                if (INTERCEPTORS.Equals(configChild.Name))
                    return configChild;
            }
            var interceptorsConfig = new MutableConfiguration(INTERCEPTORS);
            component.Configuration.Children.Add(interceptorsConfig);
            return interceptorsConfig;
        }
 
        private static void AddInterceptorConfigItem(IConfiguration parent, string interceptorKey)
        {
            parent.Children.Add(new MutableConfiguration(INTERCEPTOR, "${" + interceptorKey + "}"));
        }
    }

Finally we need to create the actual Macro. Binsor has a very handy base class called BaseBinsorExtensionMacro that I will inherit from so most of the heavy lifting is done for me

   public class InterceptMacro : BaseBinsorExtensionMacro<MethodInterceptExtension>
    {
        public InterceptMacro() : base("intercept", false, new[] {"component"})
        {
        }
 
        protected override bool ExpandExtension(ref MethodInvocationExpression extension, MacroStatement macro, MacroStatement parent, ref Statement expansion)
        {
            extension.Arguments.Add(macro.Arguments[0]);
            extension.Arguments.Add(BuildInterceptHandler(macro));
            return true;
        }
 
        private static Expression BuildInterceptHandler(MacroStatement macro)
        {
            var e = new BlockExpression();
            e.Parameters.Add(new ParameterDeclaration("invocation", new SimpleTypeReference("Castle.Core.Interceptor.IInvocation")));
            e.Body = macro.Block;
            return e;
        }
    }

In order to understand this class you have to know that behind the scenes what happens is that by default a new instance of a MethodInterceptExtension is created and injected into the Component being registered (ITextProvider in my example). Unfortunately by default Binsor does not know how many or what parameters to pass into the constructor. So we want to modify the call to construct the MethodInterceptExtension so that it takes in the method name that we want to intercept along with a delegate that actually does the intercepting.

The InterceptorMacro just takes the first argument passed to it as the method name we want to intercept. Now for some magic: the macro wraps it's body block in a delegate. Not to be outdone it then modifies the call to construct a new MethodInterceptExtension to accept two new parameters (method name and delegate). Now the MethodInterceptExtension will be constructed with the method name and delegate injected into it. Cool huh??

These three classes are pretty straight forward and the additional functionality in Binsor is incredibly useful. Plus rather than spending a day writing boring log statements I learned heaps about Binsor and Windsor. Tomorrow I will actually use this and craft up a binsor container configuration file in record time...

Top 10 Jonasims From the LinqToYourBrain Talk

noreply@blogger.com (Neil Bourgeois) — Fri, 30 May 2008 04:38:00 +0000

Awwya fool... Jonas Avellana (aka DJ LeDude) brought both his coding speedos and .Net skills to the edmug meeting this evening. Jonas delivered a couple of hours of Linq, SQL and .Net 3.5 nyahhhhh with a flair that's all his own. For those who missed it, here are the top 10 Jonasisms of the evening:

10. Awwww ya!!!
9. Thats Frickin' Cool
8. Thats Frickin' Awesome
7. You can do it like that if you're deepcore
6. var crapDataContext = new DragAndDropCrapDataContext(); [typed not vocalized]
5. First, I'm gonna show you the ghetto way...
4. ... now we'll do some Linq Kung Foo
3. Well, you know we don't have many chicks in the west end so the woman's prison is pretty good
2. Aghhhh my eyes!!!
1. I don't know how it works but its pretty awesome

A little bit of a let down was that he didn't find a way to work bescumber into the presentation but he made up for it by delivering an excellent Linq packed presentation. Thanks Jonas! It takes a lot of time and effort to do a presentation like that and myself and the rest of the .Net community really appreciate it. Now you can get back to ghost riding the whip.

You can read more from Jonas on his blog: http://blog.ezed.ca

How to read a programming book

noreply@blogger.com (Neil Bourgeois) — Sat, 24 May 2008 15:43:00 +0000

Earlier this week Seth Godin had an inspirational post titled How to read a business book in which he postulates that many people read non-fiction for the enjoyment of a factual adventure. Magic books rarely produce the next Houdini but the masses still enjoy reading about the mechanics behind the tricks. Similarly not everyone who reads a business book becomes a millionaire, rather we enjoy hearing about the daring capitalist who went from rags to riches.

Seth supports this claim by stating the recipe of a business book can be distilled down to a couple of pages. If one just wanted to read a business recipe they could do so in just a few minutes. But the truth is, as Seth writes:

- Bullet points are not the point.

The value in a business book is the fluffy stuff around the recipe. If read in the right state of mind it will motivate you to reflect on your own perspective and behavior. If read with the intent to change these books can, in fact, help you to change your life.

In our own industry the electronic aisles of Amazon are littered with How To and recipe style books that miss the essence of persuasion. These books tend to have a shelf life rarely exceeding that of a top 10 pop hit. These books will not change your life even if you wanted them too.

There are other books, however, that can change your life if you read them with the intent to change your life. As Seth says,

the goal of reading, then, isn't to persuade you to change rather to help choose what to change.

While I'm not an expert on the matter, my advice to reading a programming book requires a few tools. First go out and buy a stack of index cards, or post-it notes or even a pad of paper. Second, find a pencil, pen or feather and ink... check between the cushions of your car seat you'll find something to write with. Once you've got those things try these 6 steps:

1. Start with an intent to change. Make the decision before ever opening the book. Pick a handful of pain points in your daily grind. It may be technical pain that can be solved with design patterns. Perhaps its pain with requirement gathering that may be solved through understanding a different software process. In any event, write each pain down on its own index card. At the end of this process each card will form a recipe for your success.

2. Read and write. Now read the book. But don't just read it, write about it as well. As you're reading keep your pain points in mind and when you encounter something that may help solve your problem jot it down on the card. These are your solutions.

3. Set a goal. Now that you've identified problems and solutions you just need a goal. Missing the important step of setting goals is where most people fall short, but not you!. Rise above the rest and write down what you want to achieve and a reasonable time frame in which you will achieve it. Remember there are no unrealistic goals only unrealistic deadlines.

4. Just do it. Remember that you've invested your valuable time in reading the book, you've invested the effort of reflection and you now have a card that tells you exactly how to change. Bring those cards to work and read them a few times during the day. Keep your goals at the forefront of your concentration and the rest will follow suit. You will achieve your goals if you concentrate on them. Whenever you achieve one give yourself a gold star. You've earned it!

5. Don't stop there. Repeat this cycle in small increments over and over again. The process is called Kaizen by the Japanese and it means making continuous changes over time through tight increments of small change. The software industry is more susceptible to change than any other. We are at the mercy of change in technology, paradigms, business, globalization and an unnamed butterfly in the amazon jungle. The only way to avoid extinction in this field is to change continuously.

6. Tell everyone. Tell your team, your manager, your friends and even your grandmother. Pass the book around and tell them what you've achieved. Blog about it and encourage others to change as well. If you're in a position of leadership consider this quote from Seth:

Effective managers hand books to their team. Not so they can be reminded of high school, but so that next week she can say to them, "are we there yet?".

Remember that as exciting as the plot of a programming book may be, reading it is an investment of your time. Cash in on your investment by changing something in your life.

Fun With Boo's List Generators

noreply@blogger.com (Neil Bourgeois) — Wed, 21 May 2008 01:54:00 +0000

I know I'm a bit late to the party but I've just recently become infatuated with Boo's List Generators. Being a bit of a nerd I thought I'd take a shot at implementing a Eratosthenes Prime Number Sieve using one of these generators. I know this may not be an optimal solution from an algorithmic perspective but the syntax is really cool. Here's what I came up with:

last = int.Parse(argv[0])
filters = []
def IsPrime(number as int):
   for filter as ICallable in filters:
      if filter(number): return false
   return true

def HandlePrime(i as int):
   unless i > System.Math.Sqrt(last): filters.Add({ number as int | return number%i == 0})
   return i

print List(HandlePrime(i) for i in range(2,last) if IsPrime(i))

NYAHHHH!!!

Kicking Ast with Boo

noreply@blogger.com (Neil Bourgeois) — Sat, 17 May 2008 16:33:00 +0000

I'm currently working on a project that consumes a third party web service. This web service uses xml serializable DTOs to pass a fairly complex object model across the wire. The downside of this interface is that our code base (especially the tests) is littered with blocky new statements and setters like this (we're still in 2.0 land so we can't use object initializers):

    PersonDTO person = new PersonDTO();
    person.FirstName = "Neil";
    person.LastName = "Bourgeois";
    person.Address = new AddressDTO();
    person.Address.Number = 10160;
    person.Address.Street = "115 St.";
    person.Address.City = "Edmonton";
    person.Address.PostalCode = "T5K 1T6";
    person.Address.Country = "Canada";
    person.Email = "neil.bourgeois.junk@gmail.com";
    person.Age = 30;

I started writing builders with a fluent interface to help alleviate some of the typing and improve the readability so a person can be constructed like this:

    PersonDTO person = BuildPerson.With
   .FirstName("Neil")
   .LastName("Bourgeois")
   .Address(BuildAddress.With
      .Number(10160)
      .Street("115 St.")
      .City("Edmonton")
      .PostalCode("T5K 1T6")
      .Country("Canada")
      .Build())
   .Email("neil.bourgeois.junk@gmail.com")
   .Age(30)
   .Build();

The builder looks something like this:

    public class PersonBuilder
    {
        private readonly PersonDTO person = new PersonDTO();
 
        public static PersonBuilder With
        {
            get { return new PersonBuilder(); }
        }
 
        public PersonBuilder FirstName(string firstName)
        {
            person.FirstName = firstName;                        
            return this;
        }
 
        public PersonBuilder LastName(string lastName)
        {
            person.LastName = lastName;
            return this;
        }
 
        public PersonDTO Build()
        {
            return person;
        }
    }

Its a much nicer way to define our DTOs, however, building the builder class proved a taxing experience. Even with a dab of generics and a splash of inheritance the monotony of defining the builders made me almost throw this pattern out the window. But then I remembered a bit of Boo AST magic described by Ayende and thought, why can't I get a compiler to do this work for me? I did some googling to find this helpful post by Luis Diego Fallas and started to cut some code.

Essentially this code creates the a builder class for each DTO in our source assembly (hardcoded as SampleDTO). The result of running it is a new assembly called builder.dll that contains all the fluent builders. Builder classes are defined by creating expressions in an Abstract Syntax Tree (AST) and running that tree through the boo compiler.

To start with we need to define a new class. I like fluent interfaces to read like an English sentence so I chose to give the builder classes names like: BuildSomething. I also strip out the DTO portion of the name as just adds clutter.

baseName = type.Name.Replace("DTO", string.Empty)
newClass = ClassDefinition(Name:"Build" + baseName)

Once the class is defined we need to add a member variable for the type we are going to create:
newClass.Members.Add(Field(Name:"item",
Type:SimpleTypeReference(type.FullName),
Modifiers:TypeMemberModifiers.Private))

Next I want the constructor to initialize the member variable (eg. item = new PersonDTO()):
ctr = Constructor()
ctr.Body.Add(ExpressionStatement(
Expression:BinaryExpression(
BinaryOperatorType.Assign,
MemberReferenceExpression(
Target:SelfLiteralExpression(),
Name:"item"),
MethodInvocationExpression(ReferenceExpression(type.Name)))))
newClass.Members.Add(ctr)

Now we can add the Build() method that simply returns our member variable..
buildMethod = Method(
Name:"Build",
Modifiers:TypeMemberModifiers.Public,
Body:Block(),
ReturnType:SimpleTypeReference(type.FullName))
buildMethod.Body.Add(ReturnStatement(Expression:
MemberReferenceExpression(
Target:SelfLiteralExpression(),
Name:"item")))
newClass.Members.Add(buildMethod)

... and the static With property to give us a natural way to construct the builder. Remember that properties actually require a method behind the scenes to do the real work. So we will start with a getter that constructs a new instance of our builder and immediately returns it:
withGetMethod = Method(
Name:"internalWithGetter",
Modifiers:TypeMemberModifiers.Public | TypeMemberModifiers.Static,
Body:Block(),
ReturnType:SimpleTypeReference(newClass.Name))
withGetMethod.Body.Add(ReturnStatement(Expression:MethodInvocationExpression(ReferenceExpression(newClass.Name))))
Now we can add the With property:
withProperty = Property(
Name:"With",
Getter:withGetMethod,
Modifiers:TypeMemberModifiers.Public | TypeMemberModifiers.Static)
newClass.Members.Add(withProperty)

Finally we want to loop through all properties in our DTO and create fluent setter methods. We want this method to look like this:

public PersonBuilder FirstName(string firstName)

{

person.FirstName = firstName;

return this;

}

We'll start by creating a new method that has the same name as the property we want to set. To facilitate the fluent interface the return type of this method is the type of our builder class:
m = Method(Name: property.Name,
Modifiers:TypeMemberModifiers.Public,
Body:Block(),
ReturnType:SimpleTypeReference(newClass.Name))

Next we want to add a parameter argument to this method. This is the value we want to set the DTO property to:
parameterName = property.Name
m.Parameters.Add(ParameterDeclaration(
Name: parameterName,
Type:SimpleTypeReference(
Name:property.PropertyType.FullName)))

Now lets take that parameter and assign it to the appropriate property in our DTO. This step was a bit tricky to get right the first time but it makes sense when you think about assignment (a = b) as a binary operation (like a + b or a > b):
m.Body.Add(ExpressionStatement(
Expression:BinaryExpression(
BinaryOperatorType.Assign,
MemberReferenceExpression(
Target:ReferenceExpression("item"),
Name:property.Name),
ReferenceExpression(parameterName))))

Last but not least we need to return the instance of the builder class (this):
m.Body.Add(ReturnStatement(Expression:SelfLiteralExpression()))

Once the AST for our new builder types is complete we can take it and compile it into an assembly. Here is the code that brings it all together (Note the call to BuildClass, this is where the AST for our builder is created):

a = Assembly.Load("SampleDTO")
cu = CompileUnit()
mod = Boo.Lang.Compiler.Ast.Module(
Name:"Builder",
Namespace:NamespaceDeclaration(Name:"Builder"))
cu.Modules.Add(mod)
mod.Imports.Add(Import(Namespace:"System"))
mod.Imports.Add(Import(Namespace:"SampleDTO"))
for type in a.GetTypes():
mod.Members.Add(BuildClass(type))
pipeline = Pipelines.CompileToFile()
ctxt = CompilerContext(cu)
ctxt.Parameters.OutputType = CompilerOutputType.Library
pipeline.Run(ctxt)

Defining types in AST is a bit like walking in mud: slow and painful. What can be accomplished with 3 lines of code using a higher level language can take many many more. Hang in there, the frustration wears off after a few eureka moments and the benefit of learning this stuff can be huge. In my case a few hours writing AST (which was really interesting work) saved many more dull and tedious hours of writing boring property setters.

Remember that Reflector is your best friend for this type of work!!

As a side note, the overall framework for this is pretty cool. Whenever there is a new release of a web service we can run a NAnt build script that does the following:
1. Use wsdl to generate a proxy class (and all DTOs)
2. Compile the proxy and DTOs into an assembly
3. Run the fluent builder generator on the new assembly
4. Run ILMerge to create a new assembly with the outputs from 2 and 3

The result is a single assembly containing the Proxy, DTOs and Builders... its pretty slick!

Deploy ASP MVC Preview 2 your Shared Host Environment

noreply@blogger.com (Neil Bourgeois) — Sat, 08 Mar 2008 05:58:00 +0000

The latest drop of ASP.NET MVC (Preview 2) enables you to deploy your app by simply uploading your assemblies and MVC dependencies to your bin directory and run in a partial trust. There's still one catch, however, if your host is running IIS 6 and you have no access to manage your web site IIS properties.

Since MVC routing employs a .mvc extension to identify incoming requests IIS needs to have a asp.net mapping to that extension. If you have no access to the IIS management tools you'll end up with a bunch of 404 errors. The real answer is to request a mapping for the .mvc extension from your host.

The hack, if you're impatient (like me) or if your host is unwilling to map that extension is to reuse the .aspx extension. In other words set up your routes in GlobalApplication.RegisterRoutes to use the .aspx extension rather than .mvc.

public static void RegisterRoutes(RouteCollection routes)
{
routes.Add(new Route("Default.aspx", new MvcRouteHandler())
{
Defaults = new RouteValueDictionary(new {controller = "Home", action = "Index", id = ""}),
});
routes.Add(new Route("{controller}.aspx/{action}/{id}", new MvcRouteHandler())
{
Defaults = new RouteValueDictionary(new {action = "Index", id = ""}),
});
}

Note that you have to bump the default route up as the first route. This is because routing rules are evaluated in the order in which they are declared. The limitation of this method is that you can never have a controller called Default :-)

Creating a Custom Binsor Lifestyle

noreply@blogger.com (Neil Bourgeois) — Wed, 14 Nov 2007 00:58:00 +0000

I'm currently evaluating Windsor (well, Ayende's Binsor interpretation of it to be more precise) to help alleviate some UI stresses in a WinForms application. Essentially I am looking for something that allows me to track a certain UI context. For example, I have broken down the application flow into a number of key contexts: Application (user login), Project, Widget. I would like each context to build upon the previously loaded contexts and when a context is ended I want to clear data associated with it. For example repositories, caches, unsaved changes, etc.

Since our project is using the Castle Project's Windsor Container it seemed like a natural place to start implementing this functionality. My first kick at this cat involved a facility that managed contexts and the data associated with each one, however, I quickly realized that my facility was mimicking the behaviour of a Lifestyle. Basically what I wanted was the ability to resolve components as per-context singletons so I decided to try and create a Custom Lifestyle to achieve it.

The first step is to create a Lifestyle Manager. I just derived a class from the MicroKernel AbstractLifestyleManager and implemented the Resolve Method:

public class ContextualLifestyleManager : AbstractLifestyleManager
{
    private const string CONTEXT_ATTRIBUTE = "context";
    private readonly IDictionary<Type, IContext> contextMap = new Dictionary<Type, IContext>();
    private readonly IDictionary<IContext, IDictionary<Type, object>> contextualComponentMap = new Dictionary<IContext, IDictionary<Type, object>>();

public override object Resolve(CreationContext context)
{
    Type contextType = RegisterApplicationContext(context);
    IContext appContext = contextMap[contextType];
    string serviceTypeName = context.Handler.ComponentModel.Service.FullName;
    Type serviceType = Type.GetType(serviceTypeName);
    if (!contextualComponentMap[appContext].ContainsKey(serviceType))
    {
        contextualComponentMap[appContext].Add(serviceType, base.Resolve(context));
    }
    return contextualComponentMap[appContext][serviceType];
}

private Type RegisterApplicationContext(CreationContext context)
{
    string contextTypeName = context.Handler
                                    .ComponentModel
                                    .Configuration
                                    .Attributes[CONTEXT_ATTRIBUTE];
    Type contextType = Type.GetType(contextTypeName);
    if (!contextMap.ContainsKey(contextType))
    {
        IContext appContext = (IContext) Kernel.Resolve(contextType);
        appContext.Ended += HandleContextEnded;
        contextMap.Add(contextType, appContext);
        contextualComponentMap.Add(appContext, new Dictionary<Type, object>());
    }
    return contextType;
}
}

Keep in mind that you can override resolve to do whatever your heart desires... in this snip you can see I'm grabbing the name of the Service I'm requesting and also an Attribute from the ComponentModel configuration. Basically anything in the kernel is at your mercy!

Now, I also wanted to clean up after the context ends so added an event handler to respond to the IContext.Ended event:

private void HandleContextEnded(object sender, EventArgs e)
{
    IContext context = (IContext) sender;
    Console.WriteLine(string.Format("Removing context: {0}", context.Name));
    context.Ended -= HandleContextEnded;
    contextMap.Remove(context.GetType());
    contextualComponentMap.Remove(context);
}

Now, I know its not pretty, but it does the trick for a proof of concept. :-)

The next step was to configure this custom lifestyle in the boo container configuration. I got stuck on this for a while but eventually created a LifestyleExtension to help me out:

public class Contextual : LifestyleExtension
{
    private readonly Type customLifestyleType = typeof(ContextualLifestyleManager);
 
    public Contextual() : base(LifestyleType.Custom)
    {
    }
 
    protected override void AddLifestyleDetails(IConfiguration configuration)
    {
        configuration.Attributes["customLifestyleType"] = string.Format("{0}, SpikeWinForms", customLifestyleType.FullName);
    }
}

Here is what my Binsor config file ended up looking like (hint: @context is an attribute!):

component repository, IRepository, Repository:
    lifestyle Contextual
    @context = MasterContext
 
component applicationContext, ApplicationContext, ApplicationContext
component masterContext, MasterContext, MasterContext

Anyway, hope this post helps you out if you're trying to create custom Lifestyles using Binsor.

Get Your Strings To Perform

noreply@blogger.com (Neil Bourgeois) — Fri, 02 Nov 2007 23:02:00 +0000

Alright, we are probably all aware that strings are well employed in applications. We use them to display information to the user, we abuse them in dynamic sql statements and we confuse them with type definitions through their use in reflection. I'm willing to bet that if we inspected application's memory, strings would represent the majority of bytes. Not that there's anything wrong with that. After all the CLR has some pretty cool tweaks to make strings as primitive and performant as possible. Unfortunately for us... the CLR's string nyahh is sometimes not enough.

There are a few important things to remember about strings in C#. First, they are immediately derived from Object making them a reference type and living on the heap. The second important fact about strings is that they are an immutable array of characters. That means, they can not be altered in any way after they are constructed. The immutability of strings allows us to do some funky things without worrying about altering the original string.

Take the following code snip for example:

    string message = "Hello World";
    Console.WriteLine(message);
    Console.WriteLine(message.Replace("Hello", "Adios")
                             .Replace("World", "Suckah")
                             .ToUpper());
    Console.WriteLine(message);

The result of running this is:
Hello World
ADIOS SUCKAH
Hello World

The string contained in the message variable is unchanged while each method returns a newly created string. It is important to understand that line 3 of this snip actually constructs three different string objects on the heap and then lets leaves them for the garbage collector to clean up. Its easy to see then that if many operations are performed on a string we could quickly run into a large amount of memory being managed. It is preferred, for that reason, to use the StringBuilder class if you are doing many string manipulation operations.

Another bonus about strings being immutable is that they are inherently thread safe. Since there are no thread synchronization issues the the CLR can help you reduce the number of actual strings allocated in memory by sharing them as a single string object. This is the concept of string interning. You should consider using string interning when your code has many instances of the same string value (wasted memory) or if you are doing many checks for equality (expensive operation).

Note: String equality can get expensive because if the strings are the same length, they are checked character by character.

The CLR contains an internal hash table of strings mapped to actual string objects on the heap. You can access this hash table through two static methods on the String object itself:
public static string Intern(string str);
public static string IsInterned(string str);

The Intern method takes a string as a parameter and checks in the internal hash table for a reference to a matching string object that has already been allocated in memory. If one exists that reference is returned. Otherwise it makes a copy of your string, adds it to the hash table and returns a reference to the copy.

The IsInterned method behaves very similar except if the string does not exist in the hash table null is returned.

The end result is a single string being allocated in memory. These methods assist in both reducing memory consumption by reducing the total number of strings allocated on the heap as well as increased performance by replacing ordinal string comparisons with a quick pointer comparison.

So go ahead and run the following code snip:

    string message1 = "Hello World";
    string message2 = "Hello World";
    Assert.IsFalse(ReferenceEquals(message1, message2));

Um, they were the same... heh. Turns out the CLR interns all literal strings described in an assembly's metadata. This is where the ECMA specifications for string interning gets confusing. It seems that by default the CLR will try and intern literal strings for us, but, this can be disabled by adding the CompilationRelaxations.NoStringInterning flag to the assembly:

[assembly : CompilationRelaxations(CompilationRelaxations.NoStringInterning)]

But, the ECMA also states that the CLR may choose not to intern all of the strings in an assembly's metadata. So in reality, you can still end up with string interning by default. Additionally, there are no guarantees that future versions of CLR will honor this flag. So, the long and short of this is that you should only count on interning if you explicitly write code that uses the Intern or IsInterned methods. The following code snip demonstrates how to do this:

    string intern1 = String.Intern(message1);
    string intern2 = String.Intern(message2);
    Assert.IsTrue(ReferenceEquals(intern1, intern2));

By the way, to prove that interning doesn't work on non literal strings you can concatenating strings:

    string message1 = "Hello";
    message1 += " World";
    string message2 = "Hello World";
    Assert.IsFalse(ReferenceEquals(message1, message2));

So, there you go. Some tips and pitfalls of string performance.

Edmonton Code Camp '07

noreply@blogger.com (Neil Bourgeois) — Fri, 26 Oct 2007 05:33:00 +0000

Wow, thanks to the EDMUG guys... you did a fantastic job of organizing this event and what a great turn out. I think this year had a very cohesive series of sessions and really show that the
Edmonton development community is engaging more and more in ALT.NET and moving away from the MS endorsed drag 'n drop Designer Oriented Architecture (DOA for short... no really). I met a lot of great people (even some nice Calgarians ... heh heh) and had some great conversations. Hope to see you all around!

In case you missed it I did a session on Unit of Work where we implemented a hand rolled Unit of Work to demonstrate all the moving pieces: Object State, Identity Map, Repositories and Workspace. We also talked a bit about some problems inherent in the Unit of Work including how to deal with object state during and after persistence as well as what to do when objects are getting persisted in the wrong order.

You'll be able to download the code using the following two tags representing the start and completion of the session:
http://bourgeois-codecamp.googlecode.com/svn/T4.EdCodeCamp.UnitOfWorkStart
http://bourgeois-codecamp.googlecode.com/svn/T4.EdCodeCamp.UnitOfWorkComplete

My slide deck is posted here (please forgive the tacky background):
http://bourgeois-codecamp.googlecode.com/files/UnitofWork.ppt

The Unit of Work session was actually part of a bigger course. In this SVN repository you will find the entire contents of this day long course which covers the following topics:

Refactoring out the Code Smells
Introducing the Model View Presenter
Inversion of Control using Windsor
Unit of Work
Building with NAnt

In conversations with others I realized a lot of interest in these topics and would like to share these practices with your team. So if you think your dev team would benefit from a day of hands-on immersion in these topics please feel free to contact me.

Booya! on a Mini-Friday

noreply@blogger.com (Neil Bourgeois) — Fri, 26 Oct 2007 04:56:00 +0000

Rob Conery posted a nice binary poem for a mini-Friday and unable to resist my curiosity I resigned myself to solving it in boo with minimal LOC:

for word in @/ /.Split(poem):
Console.Write(Convert.ToChar(Convert.ToByte(word.Trim(), 2)))

Once you solve that see if you can figure out Ayende's question d'jour.

As a side note it was disheartening to realize all that I've forgotten about bits and bytes since my days in CS class.

Now Serving Ice Cold Code

noreply@blogger.com (Neil Bourgeois) — Sat, 13 Oct 2007 18:04:00 +0000

I've had many requests for the code I talk about on my blog and thought it would be a time saver for both myself and those requesting the code if it was available for download. So I started a project on code.google.com and licensed it under an MIT License. I've just checked in code for the Raising Events in NMock and Lazy Loading .NET Objects but I'll be committing any new stuff to this project as well.

You can have access whenever the Internet is open by doing an SVN Checkout:

svn checkout http://peodeas.googlecode.com/svn/trunk/ peodeas

Enjoy!

Raising Events in NMock 2.0

noreply@blogger.com (Neil Bourgeois) — Sat, 03 Mar 2007 17:18:00 +0000

One of the problems with NMock 2.0 is the inability to raise events on a mock object. I've run across this problem in many scenarios, but most frequently in testing passive views. For example in a passive view asp.net application your interface will probably look something like:

    public interface IAccountSummaryView
    {
        event EventHandler Load;
        void Display(AccountSummaryDTO[] accounts);
    }

The presenter then registers an EventHandler with the Load event and performs the display as follows:

    public class AccountSummaryPresenter
    {
        private readonly IAccountSummaryView view;
 
        public AccountSummaryPresenter(IAccountSummaryView view)
        {
            this.view = view;
            HookupEventHandlers(view);
        }
 
        private void HookupEventHandlers(IAccountSummaryView view)
        {
            view.Load += delegate { LoadAccountsInto(view); };
        }
 
        private void LoadAccountsInto(IAccountSummaryView view)
        {
            view.Display(GetAccountSummaries());
        }
    }

You'll notice that the LoadAccountsInto method is not public because the call is handled internally within the presenter class. This makes testing a little tricky since there is no facility in NMock 2.0 to raise this event and we have no way to call the LoadAccountsInto method from our test class.

        [Test]
        public void ShouldLoadAccountsIntoViewOnPageLoad()
        {
            Expect.Once.On(view).Method("Display").With(Is.Anything);
            presenter.??????
            mockery.VerifyAllExpectationsHaveBeenMet();
        }

Which more often than not results in granting the LoadAccountsInto method public accessibility for the purpose of testing:

        [Test]
        public void ShouldLoadAccountsIntoViewOnPageLoad()
        {
            Expect.Once.On(view).Method("Display").With(Is.Anything);
            presenter.LoadAccountsInto(view);
            mockery.VerifyAllExpectationsHaveBeenMet();
        }

Not a big deal, right? Well, I'll admit this gets the job done. However, whenever I find myself exposing more than is absolutely needed for a somewhat orthogonal task (such as testing, or data access) I get a sinking feeling in my gut that something just isn't right. Perhaps its because allowing this method to run around the application with public accessability gives other developers the wrong impression about it's intended use. And we all know code that doesn't communicate is a Bad Thing.

So, I spent a few minutes today to piece together the following NMock helper classes that will allow me to simulate raising an event:

    public class MockEvent
    {
        private EventHandler handler;
 
        public void Initialize(EventHandler handler)
        {
            this.handler = handler;
        }
 
        public void Raise()
        {
            handler.Invoke(null, null);
        }
 
        public static IAction Hookup(MockEvent mockEvent)
        {
            return new MockEventHookup(mockEvent);
        }
    }
 
    public class MockEventHookup : IAction
    {
        private readonly MockEvent mockEvent;
 
        public MockEventHookup(MockEvent mockEvent)
        {
            this.mockEvent = mockEvent;
        }
 
        public void Invoke(Invocation invocation)
        {
            EventHandler handler = invocation.Parameters[0] as EventHandler;
            if (handler == null)
                throw new Exception("Unknown event handler type.");
            mockEvent.Initialize(handler);
        }
 
        public void DescribeTo(TextWriter writer)
        {
            // do nothing
        }
    }

The MockEvent class is simply a wrapper around the handler that gets registered with the exposed event on the mock object. Right now the MockEvent only handles the handlers of type EventHandler. Its pretty simplistic but I'm sure you can figure out how to extend it for your own purposes.

Here's what my test looks like now:

    [TestFixture]
    public class AccountSummaryPresenterTest
    {
        private Mockery mockery;
        private IAccountSummaryView view;
        private MockEvent loadEvent;
        private AccountSummaryPresenter presenter;
 
        [SetUp]
        public void SetUp()
        {
            mockery = new Mockery();
            view = mockery.NewMock<IAccountSummaryView>();
            loadEvent = new MockEvent();
            Expect.Once.On(view).EventAdd("Load", Is.Anything).Will(MockEvent.Hookup(loadEvent));
            presenter = new AccountSummaryPresenter(view);
        }
 
        [Test]
        public void ShouldLoadAccountsIntoViewOnPageLoad()
        {
            Expect.Once.On(view).Method("Display").With(Is.Anything);
            loadEvent.Raise();
            mockery.VerifyAllExpectationsHaveBeenMet();
        }
    }

Hope this helps somebody else out there sleep better at night ;-)

Cool Things From Bootcampers

noreply@blogger.com (Neil Bourgeois) — Tue, 14 Nov 2006 00:52:00 +0000

Last weekend graduates of the first ThoughtWorks Bootcamp conglomerated in Chicago for a weekend of American beer; sailing lake Michigan in weather even us Canadians complained about and a large mushroom, bacon, mashed potato and clam pizza. The accomplishments of this group over the past couple of years impressed me so much that I wanted to take some time to plug some of their efforts.

Vipul Kasera built a website to help reduce the rampant traffic congestion of Bangalore's streets. The population explosion in Bangalore has left the city short on infrastructure and facing massive pollution. Vipul's idea will not only save people in commuting time but will help to reduce the amount of greenhouse gas dumped into the atmosphere. This site is the first of its kind in India and is a huge success boasting over 2200 carpoolers! http://www.commuteeasy.com

Jacob Northey, one of the most proficient coders I've ever met, recently left TW to start up his own business. I have to mention Jake is so fast that if you turn away to take a sip of sludgy Indian coffee while pairing with him he's already replaced your ugly nested conditional into a slick and concise strategy pattern using delegates. Jake's new project sounds like it will be popular with all those finance guys I know who define their life through spreadsheets. The software will import formulas in an Excel spreadsheet to drive a structured trading application so any self respecting finance guy with Excel experience can define their own trading software. I hope to hear more about this exciting project as it reaches the market: http://lasalletech.com

Desi McAdam has brought together female developers from around the world with her girls only developer community. No boys allowed in this one, but that's OK by us guys. The software profession is weak in female presence and would improve in credibility and quality with a better balance of genders. A community such as this could influence more women to become software professionals. Quickly growing in popularity, Desi is hoping to have a devchix conference in the near future. http://devchix.com

Ian Carvell, meanwhile, is perfecting the art of chicken chucking. When he determines the most efficient trajectory we will rendevous in a shady lounge where almost everyone's stuff will get stolen; Suzie will experience her second ever fight; Chris will disappear across five of the six points in search of an after hours club for all and as a happy group of bootcampers who have become all to comfortable with mayhem and chaos will watch a plastic chicken sail from the twelfth floor across Michigan avenue.

So long (for now) and thanks for all the clams, Poonfish.

The Myth of Comments

noreply@blogger.com (Neil Bourgeois) — Fri, 10 Nov 2006 05:22:00 +0000

Its been hammered into us since we took our first seat in the programming 101 lecture hall. Its been dogmatically programmed into each of us as if a religious script. I have seen developers scoff at code that lacks them and mistrust the behavior of said software. Because the myth crosses the boundary between technical and non-technical I've seen project managers require them and salesmen tout them. Of course, I'm talking about comments and the myth that they are an undisputed Good Thing. If the ultimate goal for a software project is to deliver business value the penultimate goal should be to communicate the what and how of that value. I simply do not believe that comments are the best way to communicate.

Developers have become such slaves to the myth that they start writing comments solely for the sake of writing a comment. This usually results in wasted lines on the screen telling me something that I as a developer should be able to infer from the code itself. I feel ill when I read code that looks like this:

            // initialize an integer and set its value to zero
            int i = 0;
            // increment i
            i++;

Yet this style of comments run rampant in posted code (yes even code posted on "reputable" sites such as CodeProject and MSDN), open source and commercial code! Commenting for the sake of commenting is an insult to the software profession. Please don't waste our time with these comments. Strip them out completely.

My foremost complaint is that comments (like other forms of documentation) can go out of sync with the code. Anecdotally, I've seen plenty of Perl scripts with concise algorithm explanations embedded in the code that differ completely from the actual behavior of that script. In this case the comments become not only an annoyance but a real danger as developers trusted the comments as if it were code. But comments are not code! Comments are not business value! Why should we trust the communicated message from anything but the code itself?

While I appreciate the spirit of communication that motivates comments, I think as software professionals we can do far better to fully communicate. For starters, we can strongly bind the message we are communicating to the business value itself by introducing a method through refactoring that is named by the message itself. For example, consider changing the following code from:

        public void DoSomething(double r)
        {
            // Calculate the area of a circle using Area=Pi*radius^2
            // where PI = 3.14
            double a = 3.14 * r * r;
            foo(a);
            bar(a);
        }

To:

        double PI = 3.14;
 
        public void DoSomethingElse(double radius)
        {
            double area = CalculateAreaOfCircle(radius);
            foo(area);
            bar(area);
        }
 
        private double CalculateAreaOfCircle(double radius)
        {
            return PI*SquareOf(radius);
        }
 
        private static double SquareOf(double radius)
        {
            return Math.Pow(radius, 2);
        }

The result is an explanation as concise as the original comment. The difference is that when the code changes, so MUST the message. As a believer in and practitioner of software professionalism I am more comfortable knowing that the behavior and message will not go out of sync.

In fact, a goal of software professionals in modern languages should be to bind message to behavior by making the code itself read like a book. Lets lose the grip of the myth and shift from being coding automatons to thoughtful individuals passionate in our pursuit of improving the state and image of our profession by improving the quality of our primary deliverables: business value and the communication of that business value.

Objects: Not Just For Breakfast Anymore

noreply@blogger.com (Neil Bourgeois) — Sat, 21 Oct 2006 14:58:00 +0000

Objects in OO languages are a powerful concept. They encourage collecting data and behaviour in highly cohesive bundles that effectively communicate a concept to a human. Effectively a block of memory, objects are technically very simple. In the managed world, we don't even need to worry about the memory because a garbage collector will clean up after us. Yet despite their power and simplicity objects are rarely employed to their full potential. Most applications contain a few coarse grained objects and a bedlam of procedural artifacts such as constant strings, integers and enumerations floating out in the global ether. So why are we as developers so hesitant to create new objects?

While there is nothing wrong with using enumerations in applications, there is really nothing gained from using them aside from the syntactic pattern. An enumeration is simply a wrapper around an integer (or any other primitive) to help communicate a concept to a human reading the code. The fact that it is an integer is irrelevant (at least it should be, but I'll get to that later). Rather than masquerading an integer as a type or concept, why not pass around an object? Try replacing your enumerations with something like this:

    public abstract class UnitOfMeasure
    {
        public static readonly object Meters = new object();
        public static readonly object Feet = new object();
    }

This class is abstract so it can never be instantiated and the public fields inside of it are immutable. Now it is an immutable memory address that we are passing around rather than an integer value. We can do things like:

  
    public class Quantity
    {
        private decimal value;
        private object units;
 
        public void DoSomething()
        {
            if(units.Equals(UnitOfMeasure.Meters))
            {
                // do something
            }
        }
    }

But you'll notice because we are passing around a naked object we lose some type safety. By giving a constructor to the class we gain a powerful type safe constant:

    public class UnitOfMeasure
    {
        public static readonly UnitOfMeasure Meters = new UnitOfMeasure();
        public static readonly UnitOfMeasure Feet = new UnitOfMeasure();
 
        private UnitOfMeasure()
        {
        }
    }

Now our Quantity class communicates that units are a UnitOfMeasure:

    public class Quantity
    {
        private decimal value;
        private UnitOfMeasure units;
 
        public void DoSomething()
        {
            if(units.Equals(UnitOfMeasure.Meters))
            {
                // do something
            }
        }
    }

Applications are also littered with constant strings. Often the strings are abused and conditional logic is based on the value of those constant strings. In a recent application I caught myself in a stringy trap by passing around units as naked strings. While this worked when we were only dealing with length units as soon as temperature units were added to the codebase the application got messed up. Temperature strings were being passed in where length strings were expected and caused some confusing and difficult to debug problems. So I replaced my string constants with objects:

    public class LengthUnit
    {
        public readonly static LengthUnit Metric = new LengthUnit();
        public readonly static LengthUnit Imperial = new LengthUnit();
 
        private LengthUnit()
        {
        }
    }

And a similar class for temperature units. This introduced some type safety and helps to communicate what exactly is expected. After this refactoring I couldn't even compile if I was passing in the wrong unit of measure type.

This is all fine and good in the simple case where constants are passed around to identify types. However, we can also get into situations where we've abused enumerations and strings to the point where a simple object replacement won't suffice. For example, in an enumeration the integer value means more than just a type, its also used as a value in a calculation. Or perhaps the string constant is used to display something to the user.

Well, fortunately it is this precise situation where objects really shine. Since we can associate multiple pieces of data and behaviour with an object there is no need to abuse strings or enumerations anymore. Lets look at some code:

    public enum UnitsOfMeasure
    {
        Meters = 3.28m,
        Feet = 0.3048m       
    }
 
    public class SomeClass
    {
        public decimal AddOneMeterTo(decimal value, UnitsOfMeasure units)
        {
            decimal oneMeter = 1m;
            if(units.Equals(UnitsOfMeasure.Feet))
            {
                oneMeter += oneMeter*Convert.ToDecimal(UnitsOfMeasure.Feet);
            }
            return value + oneMeter;
        }
    }

In this scenario I want to add 1 meter to some value. If the original value is in feet, however, I want to convert 1 meter to the imperial equavalent. Fortunately, I've created an enumeration that contains the conversion from meters to feet. Right?

Well, after re-reading this code I felt shame. My fellow developers won't know what that mysterious 3.28 and 0.3048 mean. Plus conversion is a common method that will likely be applied in other places in our codebase so there's potential for code duplication. I also don't like the conditional around feet and only applying the conversion if it is feet. So, I opted to refactor to a more OO solution as follows:

public class UnitsOfMeasure

{

public static readonly UnitsOfMeasure Meters = new UnitsOfMeasure(1m);

public static readonly UnitsOfMeasure Feet = new UnitsOfMeasure(0.3048m);

private readonly decimal conversionFactor;

private UnitsOfMeasure(decimal conversionFactor)

{

this.conversionFactor = conversionFactor;

}

public decimal ConvertTo(decimal value, UnitsOfMeasure convertToUnits)

{

return value*conversionFactor/convertToUnits.conversionFactor;

}

public class SomeClass

{

public decimal AddOneMeterTo(decimal value, UnitsOfMeasure units)

{

return value + UnitsOfMeasure.Meters.ConvertTo(1m, units);

}

Notice how the conversion behaviour was pushed back into the UnitsOfMeasure class, where it rightfully belongs. Because UnitsOfMeasure now know how to convert to each other I removed the need for the conditional and the potential for code duplication. Finally, UnitsOfMeasure is now a highly cohesive class that communicates to humans that those magic numbers are actually conversion factors.

In summary, finely grained objects can be used as a replacement to string constants and enumerations. Similar data and behaviour can be collected in objects to create highly cohesive classes which helps reduce code duplication and is an effective way to communicate concepts to other developers. Objects are also an effective use of type safety to ensure that the correct constants are being passed around. Starting out with constant objects rather than strings or enumerations also sets you up for simpler refactorings. For example, moving conversion behaviour to the UnitsOfMeasure class would've been a trivial refactoring if we had started with constant objects rather than enumerations. So think twice before introducing another string constant or enumeration into your application and consider the option of employing objects to their full potential.

Lazy Loading Using .NET Remoting Proxy

noreply@blogger.com (Neil Bourgeois) — Sat, 26 Aug 2006 07:36:00 +0000

One problem with a rich domain layer is that the reconsitution of aggregate objects from a persistence layer can take a long time. Furthermore, quite frequently not all objects within the aggregate are even called upon during it's lifespan. This means the time and elbow grease your application spent pulling data from the database and building up the domain object was pretty much in vain.

Performance efficiencies can be realized by deferring the reconstitution of the aggregate's internal objects until they are actually needed. This is a Fowler EAA pattern called Lazy Loading.

In .NET Lazy Loading is often implemented as an ugly mess of Properties such as:

public class Customer
{
private int id;
private string name;
private string description;
private bool isLoaded = false;

public int Id
{
get { return id; }
set { id = value; }
}

public string Name
{
get {
if(!isLoaded)
Load();
return name;
}
set {
if(!isLoaded)
Load();
name = value;
}
}

public string Description
{
get {
if(!isLoaded)
Load();
return description;
}
set {
if(!isLoaded)
Load();
description = value;
}
}
}

This flavour of Lazy Loading is called Lazy Initialization and has two main problems. First is code duplication. Any class that is lazy loaded first does a check to see if its been loaded and then makes a call to the database to actually load the object. Ideally this sequence should be refactored and reused among all objects that are lazy loaded.

The second problem with this code is that domain objects become littered with code unrelated to their sole responsibility. This impacts the communicability and simplicity of domain objects and makes the code more difficult to maintain. I prefer my domain objects to be pure. They should have no knowledge about how or when they or their data gets reconstituted.

Ideally, I would like an object that looks like a Customer (and can, in fact, be used as a Customer object) to sit as a proxy in the getter of my aggregate root. This proxy can be passed around and will remain an empty shell of a Customer until one of the properties is requested at which point the proxy would fetch the data to reconstitute the Customer.

This flavour of lazy loading is called Virtual Proxy and can be achieved in .NET with the help of the Sytem.Remoting.Proxies namespace.

Essentially we can derive a proxy class from RealProxy that will intercept calls to the getters and setters of our domain object. When the LazyLoadProxy receives a message for a getter it will first load the class from the database then continue to invoke the getter. If the LazyLoadProxy receives a message for a setter it will first load the domain object then continue to invoke the setter.

public class LazyLoadProxy : RealProxy
{
private readonly IGhostable subject;

[PermissionSet(SecurityAction.LinkDemand)]
public LazyLoadProxy(int id, Type type) : base(type)
{
subject = (IGhostable) Activator.CreateInstance(type);
InitializeAsGhost(id);
}

private void InitializeAsGhost(int id)
{
subject.Id = id;
}

[SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.Infrastructure)]
public override IMessage Invoke(IMessage msg)
{
MethodCallMessageWrapper wrappedMessage = new MethodCallMessageWrapper((IMethodCallMessage) msg);
MethodInfo invokedMethodInfo = (MethodInfo) wrappedMessage.MethodBase;
InvokeStrategy strategy = GetInvokeStrategy(invokedMethodInfo);
return strategy.InvokeMethod(subject, invokedMethodInfo, wrappedMessage);
}

You'll notice in the above code that I've introduced the term Ghost. Ghosting is just another flavour of lazy loading where you have a real object without any data (or partial data). In this case, our ghost object knows its Id. When it comes time to reconstitute the domain object our ghost object can do so by passing the Id into the persistence object.

Now, we will implement the IGhostable interface in the domain objects we want to lazy load.

public interface IGhostable
{
int Id { get; set; }
bool IsGhost { get; }
bool IsLoading { get; }
void MarkLoaded();
void MarkLoading();
void Load(IGhostable subject);
}

But to prevent duplication bloat in our code we can inherit from this Layer Supertype called GhostObject. The GhostObject class is responsible for knowing when to reconstitute the subclass. It looks a little like:

public abstract class GhostObject<T> : MarshalByRefObject where T : IGhostable
{
private readonly object GHOST = new object();
private readonly object LOADING = new object();
private readonly object LOADED = new object();
private object status;

protected GhostObject()
{
status = GHOST;
}

public bool IsGhost
{
get { return status == GHOST; }
}

public bool IsLoading
{
get { return status == LOADING; }
}

public void MarkLoaded()
{
status = LOADED;
}

public void MarkLoading()
{
status = LOADING;
}
public void Load(IGhostable subject)
{
ILoader<T> loader = LoaderRegistry.GetLoader<T>();
subject.MarkLoading();
loader.Load((T) subject);
subject.MarkLoaded();
}

public static T CreateGhost(int id)
{
return (T) new LazyLoadProxy(id, typeof(T)).GetTransparentProxy();
}
}

You should be aware of two things. First, the GhostObject class inherits from MarshalByRefObject. This is a prerequisite for the class to be used by RealProxy. Also note that the GetTransparentProxy() method of RealProxy is getting called from the CreateGhost method. This is what generates a class that is a proxy for the subclass.

Now, our Customer achieves a pure state of domain object zen. As for me, having lost the clutter of lazy initialization from this object I can once again sleep soundly at night.

public class Customer: GhostObject<Customer>, IGhostable
{
private int id;
private string name;
private string description;

public int Id
{
get { return id; }
set { id = value; }
}

public string Name
{
get { return name; }
set { name = value; }
}

public string Description
{
get { return description; }
set { description = value; }
}
}

And pulling it all together results in a test that looks like:

[TestFixture]
public class CustomerTest
{
private Mockery mockery;
private ILoader<Customer> loader;

[SetUp]
public void SetUp()
{
mockery = new Mockery();
loader = (ILoader<Customer>) mockery.NewMock(typeof (ILoader<Customer>));
LoaderRegistry.RegisterLoader(loader);
}

[Test]
public void ShouldMarkAsNotGhost()
{
Customer Customer = Customer.CreateGhost(99);
Expect.Once.On(loader).Method("Load").With(Is.EqualTo(Customer)).Will(new LoadCustomerAction());
Assert.IsNotNull(Customer);
Assert.AreEqual("My Customer", Customer.Name);
Assert.IsFalse(Customer.IsGhost);
Assert.IsFalse(Customer.IsLoading);
mockery.VerifyAllExpectationsHaveBeenMet();
}

[Test]
public void ShouldMarkAsLoadedWhenPropertySet()
{
Customer Customer = Customer.CreateGhost(99);
Customer.Name = "Fred"
Assert.IsFalse(Customer.IsGhost);
Assert.IsFalse(Customer.IsLoading);
Assert.AreEqual("Fred", Customer.Name);
mockery.VerifyAllExpectationsHaveBeenMet();
}

}

As you can see from the test, to create a customer that will lazy load you just have to call the factory method Customer.CreateGhost(). So to achieve performance gains I can replace all reconstitutions of aggregate objects in the persistence layer with calls to DomainObject.CreateGhost() and have them lazy load automatically.

If you would like my sample code, complete with NUnit tests just drop me a line.

Edmonton Code Camp (Sept 30)

noreply@blogger.com (Neil Bourgeois) — Fri, 28 Jul 2006 04:33:00 +0000

So, I'll be presenting a topic during the Edmonton .NET Code Camp on Sept 30. My topic is geared towards the mass of VB6 developers currently making the migration to .NET. We all love that you're making the switch, but please, please, leave your dirty VB6 habits at the door. To help make the .NET transition smoother for all involved parties I'll be presenting some basic OO concepts along with some helpful OO design patterns. Of course it will all be test driven, so I'll touch on that as well.

Specifically I'd like to delve into Encapsulation, Inheritance and Polymorphism as well as some patterns such as Strategy, Command and perhaps Observer. Although I'm not sure the problem domain yet, I'll be starting with some code that looks like it could have been written by a VB6 developer and we'll refactor it iteratively into a simple, maintanable OO solution using each of the aformentioned concepts. It will be not only fun, and educational but will make you more attractive to the opposite sex.

If you're in town on the 30th of Sept stop by, say hi, buy me beer.

For more information about the Edmonton Code Camp do that clicky thing here --> http://www.edmontoncodecamp.com/

Clumsy .NET Decorators

noreply@blogger.com (Neil Bourgeois) — Thu, 27 Jul 2006 01:41:00 +0000

The decorator pattern
is one of my favourite design patterns to assist in adherence to the Single Responsibility Principle. I especially enjoy the pattern in Ruby.

In .NET, however, the pattern loses alot of it's elegance. The necessity of gratuitous virtual delegating methods or overriding with the new keyword means that a decorator can not masquerade as the object it is decorating unless a significant amount of code has been added to the decorator class itself. When I've been faced with a task that could have been solved simply with a thin decorator, I'm often dissuaded from implementing the pattern because of the homely looking mess of a class that results.

This leads me to believe that an elegant solution exists by using reflection and Type Descriptors to create a Rubyish decorator that can dynamically delegate to base class methods. Stay tuned...

Click Once deployment using NAnt

noreply@blogger.com (Neil Bourgeois) — Thu, 20 Jul 2006 23:40:00 +0000

Click Once publishing using Visual Studio 2005 is an easy, quick and painless way to manage deployments. Painless, that is, if you are a cowboy developer who's stomach doesn't quiver at the thought of throwing non-integration tested code into production or if you're a coding monkey who enjoys the mindless monotony of manual builds.

For those of us enlightened in the art of automated builds and continuous integration, however, Click Once is a nightmare. Fortunately, there is a way to deploy Click once applications without becoming a Visual Studio monkey. Here are my lessons learned for Click Once deployements using NAnt.

First you must configure IIS with your deployment folder. For example I set up a virtual directory called http://server/clienttest to C:\Development\Deploy\ClickOnce on my deployment server. We have a windows file share pointing to C:\Development called \\server\Development. In NAnt the ${clickonce.dir} points to \\server\Development\Deploy\ClickOnce while the ${deploy.dir} variable points to a local folder containing the deployable outputs from the build.

Now, if you don't already have one you will have to create a certificate with which to sign the manifests. I used the makecert tool for this ensuring that I the private key was exported. I store this key in the file indicated in the ${certificate.filename} NAnt variable. Read http://msdn2.microsoft.com/en-us/library/bfsktky3.aspx for more info on makecert.

Next I have a NAnt build target that creates a new directory for the build version then copies the client dlls into that directory:

(pardon my obtuse XML, just can't figure out how to get the angle brackets and indentation on this site)

(target name="create.clickonce.dir")
(delete dir="${clickonce.dir}\${version}" failonerror="false" /)
(mkdir dir="${clickonce.dir}\${version}" /)
(copy todir="${clickonce.dir}\${version}" flatten="true" )
(fileset basedir="${deploy.dir}\client")
(include name="*.exe" /)
(include name="Dependant*.dll" /)
(/fileset)
(/copy)

Essentially, Click Once deployment is the creation of two manifest files. The first describes the contents of a specific version of your application the second describes the contents of your deployment and specifies the most recent version. Fortunately, Microsoft has a utility called mage that assists in generating and signing these manifests. In order to create these files as part of the build process I created a NAnt task that calls mage.

I had to do this in two steps. The first step is to create both the application manifest and the deployment manifest. For example I ended up adding a target that looks something like this:

(target name="create.clickonce")
(call target="create.clickonce.dir" /)
(exec program="mage" commandline="-New Application
-t ${clickonce.dir}\${version}\Client.exe.manifest
-fd ${deploy.dir}\client -Name Client" /)
(exec program="mage" commandline="-Sign ${clickonce.dir}\${version}\Client.exe.manifest
-CertFile ${certificate.filename} -Password ${certificate.password}" /)
(exec program="mage" commandline="-New Deployment
-t ${clickonce.dir}\Client.application
-pu http://server/clienttest/Client.application
-n Alpha -i false
-appm ${clickonce.dir}\${version}\Client.exe.manifest" /)
(exec program="mage" commandline="-Sign ${clickonce.dir}\Alpha.application
-CertFile ${certificate.filename} -Password ${certificate.password}" /)
(/target)

This target need only be called when you want to create your deployment manifest. Typically it will only be called once, but I like to throw it in the build script in case I ever need to rebuild my deployment server.

The second step is to create the application manifest for the most recent build and then update the deployment manifest. The following target copies the

(target name="deploy.clickonce")
(call target="create.clickonce.dir" /)
(exec program="mage" commandline="-New Application -t ${clickonce.dir}\${version}\Client.exe.manifest -fd ${deploy.dir}\client -Name Client -Version ${version}" /)
(exec program="mage" commandline="-Sign ${clickonce.dir}\${version}\Client.exe.manifest -CertFile ${certificate.filename} -Password ${certificate.password}" /)
(exec program="mage" commandline="-Update ${clickonce.dir}\Alpha.application -AppManifest ${clickonce.dir}\${version}\Alpha.exe.manifest -Version ${version}" /)
(exec program="mage" commandline="-Sign ${clickonce.dir}\Alpha.application -CertFile ${certificate.filename} -Password ${certificate.password}" /)
(/target)

For more information on manual Click Once deployments have a read through http://msdn2.microsoft.com/en-us/library/xc3tc5xx.aspx.

Got Mission?

noreply@blogger.com (Neil Bourgeois) — Wed, 19 Jul 2006 02:43:00 +0000

Being a skeptic of mandated doctrine the typical corporate mission statement is about as appealing to me as ketchup on cottage cheese. In my experiences coporate mission statements have been vague, broad and cliche. Until now, I've never been asked to participate in creating a new mission statement nor has my opinion been solicited in improving an existing one. Lacking in the authentic spirit of a team these works of bland prose garner little support from the very people they are supposed to inspire. So people tend to ignore them. Reading through them as part of the new hire literature and then shelving them with the instructions to the voice mail system.

Although I think that most mission statements are useless because they are done by the wrong people for the wrong reasons I do believe in the power of an effective mission statement written by the people who are to be guided by it. So when our PM announced a team meeting to come up with a mission statement, I'll admit I was a little excited.

The session was accepted by all the developers and everyone had their own ideas to contribute into the mix. Our PM did a great job of controlling the brainstorming sessions and making it a fun excersize. The meeting took just under an hour and the end result was a single sentence (consisting of just 4 words, actually) that conveys the quintessential values and goals of our team in addition to half a dozen sentences that describe it a little deeper.

The breakdown of the brainstorming was as follows:
1. List of things that we want to accomplish (the Whats)
2. List of ways we will accomplish them (the Hows)
3. Words or a sentence that describes a lofty yet attainable goal considering the context of the prior lists

Of course there's some categorization nebula between steps 1 and 2 that can be solved with brainstorming patterns. For example, words that fall under What and How might be broken down into two or more words which can be placed across categories.

Interestingly for our team, some of the fundamental Agile/XP values seemed to pop out on the whiteboard. Not necessarily expressed using these words, the concepts of Communication, Feedback, Simplicity, Responding to Change, Customer Collaboration emerged. Sadly, there was no Courage ;-)

So, what was our mission? The end result the following statement: Positively impact every project. Meaning that our team's lofty goal is to have our fingers in every project and ensure that we are providing a positive impact in each of those engagements.

So, does your team have mission?