• Jing – The absolutely best way to capture screenshots and video, upload and share it immediately
• Charting
  • Yuml.me – Insanely awesome tool for UML diagrams
  • Websequencediagrams.com – Insanely awesome tool for sequence diagrams
• Dabbleboard – Great online whiteboarding utility
• Mockups
  • Balsamiq – Incredible quick mockup builder
  • Moquingbird – Similar to Balsamiq but with different strengths. I think its better for capturing screenflows
• Online meeting
  • Webex – The best (I used it to screenshare and do live meetings with India) but prohibitively expensive
  • Microsoft Livemeeting
  • GotoMetting
  • Dimdim
• Bubbl.us – A really promising mindmapping tool
• Trac – Simple integrated wiki/issue tracker and svn. I just really like this wiki for its simplicity and I’ve used it in the past to great effect
• Google groups – Make a private group for your project and have everyone sign up. Now you have an effective mailing list which gives you threaded conversations and an online-accessible and fully searchable repository. A big plus is that this is achieved with the communication lowest-common-denominator – email
• Google Wave – I’m not convinced that this is ready for prime-time yet but it has some promise
• Google Docs – Great for getting a survey, spreadsheet, anything Q&A up and running super-quick. Also online collaboration with documents and having an web-accessible powerpoint is great
• Dropbox – Perfect for file sharing

Plus this site has some great ideas.

I am going to add to this post as I encounter more tools that I find useful.

• Launchy - Simple, fast, open source application launcher
  • Launchy Plugin – Ty to post to twitter from Krzysztof Ko?mic
  • Launchy Plugin – GCaly to post to your Google Calendar
• ClipX - Tiny little clipboard history manager.  I use this one about 70 times each day
• WinSplit Revolution – Awesome utility to throw applications between dual monitors and tile them easily
• Deskpins - A simple utility to force windows to stay on top. Not the love of my life, but the best that I’ve found since xNeat went for-pay
• Firefox - With the firebug and Web Developer plugins. I really only use it for debugging pages and playing with javascript. This is mostly because I use
• Chrome - Web browser. It just feels faster, ok? Oh and the too many tabs extension.
• EditPad Pro – Great notepad utility. Has an unlimited trial version, and I’ve had a license for it for years. I might give Notepad2 a try, but I doubt I’ll make the jump.
• jZip - Open source zip utility. Handles all the stuff that Winzip and WinRar do with less whining.
• TortoiseSVN - Windows Explorer – Integrated SVN source control. As I use git more and more for personal projects I’m starting to regret how heavyweight the integration is though, might try something new next time.
• MSysGit - While we’re on the subject.
• Fiddler2 - Http viewer, debugger. Don’t use it too much but its handy to have around.
• IE 8 Developer Toolbar – Its actually quite good
• GIMP - I ain’t a fancy-nancy designer and I’m not paying for Photoshop.
• Paint.NET – When I want to draw stuff but don’t want something as heavyweight as GIMP
• Inkscape - For working with svg images. I use it surprisingly often
• WinMerge - Great little application for comparing two files/directories/whatever
• Console2 - Could never really get it to work better than the powershell default but it deserves another shot
• Powershell – Are you a developer on windows and don’t use this? You need to be punched in the face (or at least have you mouse stole).
• AutoHotKey – For scripting windows
  • AutoHotKey Script – BDD names from JP Boodoohoo. I had made some customizations to it but they were lost with the lastdisk crash. Oh well
• Gallio Icarus – Sometimes you just want a stand-alone test runner GUI and this is the best
• Putty - For SSHing
• TweakUI – For Windows XP. Hopefully that’s a game I won’t have to play for much longer
• Reflector - Must have for .NET development
• Jing - Oh I love this. The best for quick screen captures (though it would be nice if it had a lighter memoery footprint).
• FileZilla Client – Ftp I usually do with windows explorer (you knew it could do that, right?) but SFTP we need to bring in the pros
• Ruby – I’m going to try just running IronRuby next time, I swear.
• SQLite.NET – Tends to come up sooner or later, good for quick free file-based database
• KeePass – I keep all my passwords in here – shh don’t tell anybody
• Growl for Windows – I wrote a friggin’ log4net Growl Appender, obviously I want something to read it.
• Synergy – To share mouse and keyboard with multiple computers
• Visual Studio – duh, but also the following plugins/extensions
  • TestDriven.NET – can’t live without youuuuu
  • T4 Toolbox – gotta have it since I like Sharp Architecture so much
  • ASP MVC – nuff said
  • ZenCoding – I haven’t had a chance to use it yet but I really can’t wait till I do
  • Refactor Pro and CodeRush – It’s a love affair, though I just picked up a ReSharper license at the last VAN so I guess I should compare and contrast or something
    • CR_ClassCleaner Plugin for DxCore
• Microsoft Live Meeting – For the virtual alt net sessions
• Skype
• Dropbox
• SharpDevelop - I got to get into using this interesting IDE more
• RubyMine – Great for ruby, and I have a license!
• VLC Media Player – Way more lightweight feeling than the others and plays anything

The problem is that programs are complicated. I don’t tend to help the issue. In a flash I don’t hesitate to layer on additional complexity with domain models, frameworks, and complex infrastructures. Entities, sevices, repositories and aggregate roots – they’re the tools that we reach for all too often. That is not to say that Domain Driven Design is a poor paradigm – I’m a big fan – it’s just not always necessary.

Take for example a typical scenario. You are given an integer which uniquely identifies a customer and are asked to generate a report of all their orders, export it to a pdf file and return as a Stream. My first impulse is to start with the customer and order objects, identify the bounded context, figure out the aggregate roots, start writing data access mapping code, and so on. If I’m lucky, I only do this for a few hours before hearing the voice of an incorporeal Ted Neward yelling at me to STOP. I was not asked to build a domain model, I do not need to keep track of state, there is no validation, or (much) business logic. The problems that DDD is intended to solve are simply not present here. I need to do one thing and one thing only, map an integer to a Stream!

And yes, I do realize that this is exactly what the CQRS guys have been harping on for years.

My Solution:

Each of my last few projects has contained a very simple interface.

public IMapper<INPUT_TYPE, OUTPUT_TYPE> {
  OUTPUT_TYPE Map(INPUT_TYPE obj);
}

Get it? Put in an integer, get back a Stream, what could be simpler? Ok, maybe that’s too simple. Any change at all would require modifying the implementation. This is all that icky procedural programming stuff. What about reusability, encapsulation, separation of concerns, and our other OO goodies? Fortunately, we don’t have to give these up. All we have to do is introduce a couple of obvious seams. We no longer transform an integer directly to a Stream. Instead we:

1. Take the id and map it to a DataSet that contains the report data.
2. Map a DataSet to the appropriate fully built Crystal Reports ReportDocument.
3. Map a ReportDocument to a MemoryStream of a pdf file.

IMapper<int, DataSet> _dataProvider;
IMapper<DataSet, ReportDocument> _reportGenerator;
IMapper<ReportDocument, Stream> _pdfReportExporter;

public Stream GetCustomerReport(int customerId) {
  return _pdfReportExporter.Map(
           _reportGenerator.Map(
             _dataProvider.Map(customerId)));
}

Pretty nice huh? Well not that nice. If you’re a naming perfectionist like I this should make you shiver. When it comes to maintainability, good intention-revealing namespace, class, and method names are worth a million unit tests and n-tier architectures. Forget requirements docs and self-documenting code, proper naming is the number one tool for communicating our intent.

I lecture my team on this constantly and yet I allow myself the use of the the term “Map”?! A generic term that could indicate anything except (unless you’re a cartographer) a concept from your ubiquitous langauge. I should be ashamed.

We want to keep our generic IMapper interface though, it’s so slick, allows us to write minimal code and you you could easily imagine it coming in handy. For example, perhaps as the domain itself becomes more complicated, it becomes useful to break our IMapper<int, DataSet> down further.
1. The integer is get mapped to a Customer entity.
2. This gets mapped to a ReportSpecification.
3. The ReportSpecification is evaluated and mapped to a StoredProcedureInvocation
4. The procedure is executed and finally returns our DataSet.

You could imagine all sorts of neat little tricks you could play with our IoC container – we could have it automatically link transforms together or subsitute out implemenations. Simply by knowing that all these components transform one object to another we could configure automatic caching, deferred execution proxies, and so on. All things that are made far easier because all transformations are achieved via IMapper.Map.

What we really need is a way to introduce aliases for the Map() method. Preferably ones that depend on the input and output type. So why sit there scratching our heads? C# is a flexible enough language, let’s just let’s do that thing that I just said.

public CustomerOrderReportGenerator : IMapper<DataSet, ReportDocument> {
  public ReportDocument Map(DataSet data) {
    // implementation
  }
}
public partial static class AliasExtensions {
  public static ReportDocument GenerateReportFrom(this IMapper<ReportDocument, DataSet> mapper, DataSet ds) {
    return mapper.Map(ds); }
}

And now we have aliases:

  _pdfReportExporter.Export(
    _reportGenerator.GenerateReportFrom(
      _dataProvider.GetOrderDataFor(customerId)));

The poor readability of this bothers me. The LISPers among us might not mind reading backwards through a stack of nested parentheses but as a fan of fluent interfaces I’d like to see my code read as close to natural english as possible.

Same trick, now featuring double dispatch!

public partial static class AliasExtensions {
  public static ReportDocument ComposeIntoReportUsing(this DataSet ds, IMapper<ReportDocument, DataSet> mapper) {
    return mapper.Map(ds); }
}

Allows us to do:

  return _dataProvider
    .GetOrderDataFor(customerId)
    .ComposeIntoReportUsing(_reportGenerator)
    .ToStreamUsing(_pdfReportExporter);

And there you have it. Nice, fluent, and composable.

What do you guys think? Aliased Maps a good name?

Like for example enabling/disabling your Fusion Log every time you need to figure out why assembly binding has gone wrong. So here you go. Just put these in your profile:

function global:Enable-FusionLog {
	Remove-ItemProperty HKLM:Software\Microsoft\Fusion -name EnableLog -ErrorAction SilentlyContinue
	[void](New-ItemProperty  HKLM:Software\Microsoft\Fusion -name EnableLog -propertyType dword -ErrorAction Stop)
	Set-ItemProperty  HKLM:Software\Microsoft\Fusion -name EnableLog -value 1 -ErrorAction Stop
	Write-Host "Fusion log enabled.  Do not forget to disable it when you are done"
}
function global:Disable-FusionLog {
	Remove-ItemProperty HKLM:Software\Microsoft\Fusion -name EnableLog -ErrorAction SilentlyContinue
	Write-Host "Fusion log disabled"
}

Awesome.

Also we talked Powershell at yesterday’s GNO.NET and Cody Gros showed PowerGUI - which a totally free and seemingly awesome powershell editor. Woo!

For the purpose of this essay a mock is an object that uses the object oriented concept of polymorphism to create an alternate implementation of a class or interface. Essentially, a mock is just a fake version of an object.

A mock is used for two things

1. Stub: Stand in for a service and provide alternate, simpler method implementations. An example would be to substitute for an object that would normally query the database – instead of querying the database the stub object will simply return a canned response.
2. Spy: Detect whether an object was used in a certain way. An example would be when testing an object that decides whether to call ui.NotifyUser() depending on some criteria. A spy can stand in for the ui object and call tell you if the NotifyUser() method was called.

Don’t worry if that is a bit obtuse, it should become clear soon

Why Would You Need A Mock?

Consider the domain of liquid storage.

• We have a Container which has Contents.
• By totalling all the transfers into and out of the container we can calculate the expected Quantity of the Contents – this is called the Book Value.
• We can also physically measure the Quantity – whenever we do, we add the measured Quantity, along with it’s type (whether it was taken Automatically or Manually) to the store of Physicals.
• We can at any time request a measurement of the Variance of the Contents. This Quantity is defined as the last manual Physical minus the Book Value.
• Of course when a Varaiance is calculated, it needs to get Logged.

  public class Contents {
          public Quantity Book { get; set; }
  }
  public interface IPhysicals {
    Quantity GetLastFor(Contents contents, PhysicalType physicalType);
  }
  public enum PhysicalType { Manual, Automatic }
  public class Quantity {
     public double Amount { get; set; }
    public string UnitOfMeasure { get; set; }
  }
  public interface IEventLogger {
    void Log(string message);
  }
  public class VarianceCalculator {
    IPhysicals _physicals;
    IEventLogger _log;
    public VarianceCalculator(IPhysicals physicals, IEventLogger events) {
      _physicals = physicals;
      _log = events;
    }

    public Quantity GetVariance(Contents contents) {
      Quantity p = _physicals.GetLastFor(contents, PhysicalType.Manual);
      if (p == null)
        return null;
      var variance = new Quantity() { Amount = p.Amount - contents.Book.Amount };
      _log.Log(String.Format("New variance calculated: {0} - {1} = {2}",
               p.Amount, contents.Book.Amount, variance.Amount));
      return variance;
    }
  }

[Code Link]

The only logic here is in the VarianceCalculator.GetVariance method so let’s test that.

For any action there are two things that can be checked: the output, and any side-effects. So let’s write down all the conditions and side-effects that we expect.

1. If the contents object does have a manual physical then the method should return the correctly calculated quantity
2. If the contents object does have a manual physical then the method should log the calculation.
3. If the contents object does not have a manual physical then the method should return null
4. If the contents object does not have a manual physical then the method should not log anything.

Notice that an external service (IPhysicals) is used to retrieve the physical that will be used. We do not want to actually have to set up and query the database so we need something that performs the duties of a stub. Also notice that we need to check whether the calculation results were passed off to a logger object. Going on our definitions from above, this requires a spy.

Our Tests

Given that we have four points above we should write four tests. Here they are written in an abstract class that leaves gaps for how to to actually set-up the mocks. We will create implement this abstraction in the next two sections.

  [TestFixture]
  public abstract class VarianceCalculatorTests {
    protected abstract void BuildMocks(Quantity lastManualPhysical);
    protected abstract VarianceCalculator GetCalculator();
    protected abstract void AssertLoggerWasCalled(bool expectLoggerCalled);

    readonly Contents _contents = new Contents() {
      Book = new Quantity() { Amount = 700 }
    };

    [Test]
    public void Has_physical__Variance_is_physical_minus_book() {
      BuildMocks(new Quantity() { Amount = 1000 });
      var variance = GetCalculator().GetVariance(_contents);
      Assert.That(variance.Amount, Is.EqualTo(300));
    }
    [Test]
    public void Has_physical__Calculation_is_logged() {
      BuildMocks(new Quantity());
      GetCalculator().GetVariance(_contents);
      AssertLoggerWasCalled(true);
    }
    [Test]
    public void Has_no_physical__Variance_is_null() {
      BuildMocks(null);
      var variance = GetCalculator().GetVariance(_contents);
      Assert.IsNull(variance);
    }
    [Test]
    public void Has_no_physical__Calculation_is_not_logged() {
      BuildMocks(null);
      GetCalculator().GetVariance(_contents);
      AssertLoggerWasCalled(false);
    }
  }

[Code Link]

Doing It Manually

In the interest of going slow, let’s first implement the above test fixture manually.

MOCKS CANNOT DO ANYTHING THAT YOU CANNOT DO YOURSELF MANUALLY!

If you do not need any further convincing then you can skip to the next section.

When you manually create an alternate implementation the resulting objects are traditionally called “Fakes”. Here is a fake implementation of IPhysicals that can stub out calls to physicals.GetLastFor()

  public class FakePhysicalsStub : IPhysicals {
    private Quantity _lastPhysical;
    public FakePhysicalsStub(Quantity lastPhysical) {
      _lastPhysical = lastPhysical;
    }
    public Quantity GetLastFor(Contents contents, PhysicalType physicalType) {
      return _lastPhysical;
    }
  }

And here is a fake implementation of an IEventLogger spy:

  public class FakeEventLoggerSpy : IEventLogger {
    private IList<string> _messagesLogged = new List<string>();
    public void Log(string message) {
      _messagesLogged.Add(message);
    }
    public bool WasLogged(Regex expectedMessageMatcher) {
      return _messagesLogged.Any(m => expectedMessageMatcher.IsMatch(m));
    }
  }

And here is how you would use these:

  public class ManualFakes_VarianceCalculatorTests : VarianceCalculatorTests {
    private FakeEventLoggerSpy _logger;
    private FakePhysicalsStub _physicals;
    protected override void BuildMocks(Quantity lastManualPhysical) {
      _physicals = new FakePhysicalsStub(lastManualPhysical);
      _logger = new FakeEventLoggerSpy();
    }

    protected override VarianceCalculator GetCalculator() {
      return new VarianceCalculator(_physicals, _logger);
    }

    protected override void AssertLoggerWasCalled(bool expectLoggerCalled) {
      Assert.That(_logger.WasLogged(new Regex(".+")), Is.EqualTo(expectLoggerCalled));
    }
  }

[Code Link]

Getting Rhino.Mocks to Do It for You

Creating fakes manually is not very difficult but it does require some thought. In addition you end up having to maintain the fakes as well as your actual implementations when making any changes to the underlying types. On the other hand, creating manual fakes will always be more powerful and flexible than an automatic alternative so do not be afraid to use them when needed. That being said, Rhino Mocks is a library thatwhen properly used should be able to cover 99% of your automatic mock creation needs. In fact, I have never really encountered a situation where its abilities proved inadequate.

It is important to remember that Rhino.Mocks has been around for some time and offers several different APIs. This tutorial targets the version of the API as of Rhino.Mocks 3.6 – while improvements are possible, there have not been any truly major changes in the last few versions and this API style can probably be considered final.

Mock Creation

First things first; how do you use Rhino.Mocks to create our stub and spy instances? Rhino.Mocks does not distinguish between the two when creating objects – all classes created by Rhino.Mocks can be used as both stubs and spys. The easiest way to create them is to use the MockRepository static class:

This class has two methods of consequence, GenerateMock<T>() and GenerateStub<T>(). There is very little difference between these two and you can feel perfectly safe using only GenerateStub<T>(). Calling

IEventsLogger mock = MockRepository.GenerateStub<IEventsLogger>()

Will return an that implements IEventsLogger and can stand in for all its instances.

Stubbing

By default, any calls to _physicals.GetLastFor() will return null but we can set up this mock object to act as a stub:

  _physicals = MockRepository.GenerateStub<IPhysicals>();
  _physicals.Stub(x => x.GetLastFor(
      Arg<Contents>.Is.Anything, Arg<PhysicalType>.Is.Anything) ).Return(lastManualPhysical);

This API uses extension methods and LINQ Expressions to allow you to specify which method you want to stub and what to return. When _physicals.GetLastFor() is called after this code executes, the object lastManualPhysical will be returned.

Also, as the above code implies, you can constrain the stub based on certain types of inputs.

  _physicals.Stub(x => x.GetLastFor(
      Arg<Contents>.Is.Null, Arg<PhysicalType>.Is.Equal(PhysicalType.Automatic))).Return(someOtherPhysical);

Is legal and works pretty much like you would expect. Many constraint types are available. There are also several shortcuts. For example the above can be expressed as

_physicals.Stub(x => x.GetLastFor(null, PhysicalType.Automatic).Return(someOtherPhysical);

Since all arguments have to be matched exactly. Also the first stub (where any arguments are acceptable) can be more quickly expressed as:

_physicals.Stub(x => x.GetLastFor(null, null)).IgnoreArguments().Return(lastManualPhysical);

Several other syntaxes are also available, but as of Rhino.Mocks 3.6 these are the only ones that are preferred.

Spying

Now that we have discussed stubbing, let’s discuss the syntax for creating spy objects. As stated before, all objects created with Rhino.Mocks can be both stubs and spys so their creation is exactly the same. We only need to learn the syntax for how to verify whether a method was called or not. This is achieved with the AssertWasCalled() and AssertWasNotCalled() extension methods.

These methods have very similar syntax to Stub() with the exception that IgnoreArguments(), and other constraints shortcuts are provided in a constraints parameter, rather than as extension methods of their own. So, to specify that our IEventsLogger.Log() method was called we need to do this:

_logger.AssertWasCalled(x => x.Log(null), c => c.IgnoreArguments());

Or to specify that it was not called:

_logger.AssertWasNotCalled(x => x.Log(null), c => c.IgnoreArguments());

If you want a little more finely grained control over the argument constraints you can do that too. For example the following asserts that Log() was called and that the input was not null or empty:

  _logger.AssertWasCalled(x => x.Log(
    Arg<string>.IsMatches(Is.Matching<string>(m => !String.IsNullOrEmpty(m)))));

Of course, as before, if you know the exact argument that you want to check for you can do it more easily:

_logger.AssertWasCalled(x => x.Log("this exact message was called"));

Here is the full implementation for the base VarianceCalculatorTests:

  public class RhinoMocks_VarianceCalculatorTests : VarianceCalculatorTests {
    private IEventLogger _logger;
    private IPhysicals _physicals;
    protected override void BuildMocks(Quantity lastManualPhysical) {
      _physicals = MockRepository.GenerateStub();
      _physicals.Stub(x => x.GetLastFor(Arg.Is.Anything, Arg.Is.Anything)).Return(lastManualPhysical);
      _logger = MockRepository.GenerateStub();
    }

    protected override VarianceCalculator GetCalculator() {
      return new VarianceCalculator(_physicals, _logger);
    }

    protected override void AssertLoggerWasCalled(bool expectLoggerCalled) {
      if (expectLoggerCalled)
        _logger.AssertWasCalled(x => x.Log(null),
            c => c.Constraints(Is.Matching(m => !String.IsNullOrEmpty(m))));
      else
        _logger.AssertWasNotCalled(x => x.Log(null), c => c.IgnoreArguments());
    }
  }

[Code Link]

Other Stuff

You have now learned virtually everything you need to know to effectively use Rhino.Mocks. A couple other occasionally used syntaxes are:

  _physicals.Stub(x => x.GetLastFor(null,
    Arg<PhysicalType>.Is.Anything)).Throw(new ArgumentNullException ());

Which causes (you guessed it) an ArgumentNullException to be thrown when GetLastFor() is passed a null contents object.

If you have played around with the stubbing code above, you might have noticed that the stub will work only once. That is, you will get the desired result the first time you call _physicals. GetLastFor() but will go back to returning null for subsequent calls. To get the desired result you can set the stub up multiple times, or use the Repeat syntax.

  _physicals.Stub(x => x.GetLastFor(null,
    Arg<PhysicalType>.Is.Anything)).Return(null).Repeat.Any();

Also, you can pass in a delegate to be executed when a stubbed method is called. This is primarily useful when doing integration and benchmark tests or when working with a timer.

  _physicals.Stub(x => x.GetLastFor(null, PhysicalType.Automatic)).IgnoreArguments().Do(
    new Func<Contents, PhysicalType, Quantity>((c, t) => {
      Console.WriteLine("Method Called With {0}, {1}", c, t);
      return null;
    })
  );

A situation where you are finding yourself having to do something like this might be an indicator that you should just create a fake manually.

It is also possible to create mocks of concrete classes rather than just interfaces. However, this can be a little tricky since there is no way for Rhino.Mocks to stop the constructor from executing. You must therefore either provide a parameter-less protected constructor or pass in objects to be used.

  public class MyClass {
    string _dependency;
    public MyClass(string dependency) {
      _dependency = dependency;
    }
  }
  //
  MyClass x = MockRepository.GenerateStub<MyClass>("");

A word of caution however, if you find yourself really needing to mock a concrete object perhaps you might want to consider extracting an interface, or including the object in your test.

And that’s it. There is a lot of other stuff in Rhino.Mocks but it is almost guaranteed that you don’t need to know it as the above will cover nearly every single testing scenario.

Sample Code and on Testing Style

The sample code from this tutorial is provided here. Please note that there are three sets of tests. VarianceCalculatorTests.cs contains the base class which defines the tests used above. ManualFakes_VarianceCalculatorTests implement the tests using manually built fakes and RhinoMocks_VarianceCalculatorTests implements them using Rhino.Mocks.

Although it is ultimately a matter of preference, it should be noted that the tests written so far are not done in what in what is a somewhat dated style. The currently predominant testing technique of Behavior Driven Development (BDD) is usually preformed and recommended. To that end, another series of tests is provided inside the BDD directory to demonstrate how such tests might look.

So now you know how to use Rhino.Mocks. I urge you to investigate its use further and learn as much as you can about Unit Testing, Test Driven Development, and Behavior Driven Development.

Please feel free to leave any further questions in the comments.

It is the second day that was destined for real magic.  The challenge was simple: “Do something to help with the organization of the leagues of people who donate their time to volunteer for the New Orleans public school district”.  Those familiar with software development in general – and the challenge of herding hungover techies who get in at 10am to start and complete a project by 4pm in particular – will recognize it as simply jaw-dropping.  Especially when “something” is expanded to mean “create a full blown, maintainable, multi-media website to bring together and thank volunteers” – wowee.  And yet I’m proud to announce http://www.nolaschoolvolunteers.org/ which as of this morning did not exist and now does all those things and more.  Everything you see, including domain name, CMS installation, layout, and much of the content was created in one afternoon by a group of dedicated barcamp attendees.

In a word, everyone there was just astoundingly professional.  How professional?  Well a room full of 15 geeks from different backgrounds and diciplenes spent all of 10 minutes debating language choice and platform.  The conversation was literally:

- So it sounds like  PHP is our lowest common denominator and we’ve got a PHP guru?

- Yup.  So let’s do PHP.

- Ok.  Can we do this in wordpress?

- I think so.  We’ve got a couple guys that are good at wordpress and some more that are familar with it.

- Wordpress it is.

And if that isn’t shocking enough then we did it!  In one fell swoop and in no small part through the leadership of Matthew Tritico and others; requirements were defined, refined, scoped back, matched up with a technology, assigned,  implemented, and integrated in a whirlwind six hour session that I consider among the most productive hours of my life.

Oh and luck.  I’m going to go ahead and say that a lot of luck was also involved.

So take aways:

1. Never underestimate the collective power of an enthusiastic, experienced, and focused group.  The trick is getting all three.
2. Value of someone who’s done it once before is that of ten bright people. Value of someone whose done it twice is that of twenty.
3. Take the time and pick the right tool for the job.  The site was created in wordpress with a variety of plugins, and a healthy dose of google products.  A huge amount of functionality with hardly any code at all!  Microsoft take note – this is RAD developoment done right.  It is possible, but drag-drop and a fancy IDE is no replacement for true knowledge.
4. Finally, equally as important as the availability of the right component is the ability to integrate with the rest of the application.  Do not take this for granted – the excellent ecosystem of wordpress plugins was a major deciding factor for us and cut down considerably on integration time that we did not have.

So again, a spectacular job by all.  A lot of great relationships fostered, a lot of tech talk, and one kick-ass site banged out in an afternoon.  Frankly, given the glacial pace at which I see projects progressing in the enterprise space, I really needed to see this.  I’m not even sure what I think about this yet – was it all luck or did I really learn something interesting?

I think likely the latter.

That’s right customers and their god d*mn feature requests and bug reports!  Life would be so much easier without them.  And acknowledging the absurdity of that statement, unless you are some kind of programmer Adonis (which unlike a regular Adonis physically implies only that your esophagus is invulnerable to lesions caused by Bawls) and write flawless code you will have to deal with feature requests that can rapidly pile up and overwhelm your development process.

I had mentioned previously on this blog that I am working with a team of Indian contractors and this is exactly what they found happening with the latest high stakes omg-fix-this-now-or-we-all-die release.  The team was behind and the release went out mere minutes before users started working with it.  Of course in the rush to finish on time bugs cropped up and features were left out.  Lots of features.

So immediately the next morning, with tickets raining down and demands for new drops every day the team got to work.  And the daily releases never came.  On the 3rd day we finally dived into their process with them to identify the problem.  

Simply speaking, they couldn’t reach a stopping point.  By the time certain features were ready to go others were half-implemented and so no release could be scheduled.  It was like some sort of real life Zeno’s paradox.  Fortunately this one has a solution.  Fully acknowledging that it is probably named differently in a dozen books and Agile pamphlets (just not any that I’ve seen), I call it branch-per-release or “how to use source control to get yourself out of a tight spot”. 

The idea is blatantly simple:

1. Chose a release date
2. Decide which features will fit in that release date
3. Use your source control chops to create a branch for that release
4. Decide what release each of the features on your plate goes in
5. Create a branch for each of those releases
6. Implement each feature set in the branch for its release
7. When development on a branch is completed and tested, reintegrate into trunk.
8. Rinse, repeate.

I have created a presentation and a series of screencasts (3 x 5 minutes thank you Jing) to demonstrate the process.  And here they all are:

• Presentation – 6 Slides, Google Docs format (so its viewable in-browser)
• Part 1  
• Part 2
• Part 3

Apparently embedding videos on wordpress.com is a pain in the *ss (as is code highlighting) so as mere links they must stay.

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Gotta have at least one picture of a Rhino

 handled in a million different places probably best on Martin Fowler’s blog (is the terminology blog correct here? Bible? Holy Testament?).

Super short version: Ruby on Rails prides itself on being an edgy community; at a conference, a slide deck contained a prolonged analogy between a technology and porn; people got offended.  There, that hits all the high notes.  I posted my thoughts as a comment on the hanselblog but then thought hey, I really haven’t updated my own blog in a while and I actually have (what I think is) an original insight on this so here we go.

For the record, I am mostly with Martin Fowler and others who urge professionalism and think the presntation was in poor taste to begin with (as in a cheap use of a lame analogy) but I think that I have something else to add to the discussion.

Let me start with this, I am notoriously thick skinned.  Really.  Like a Rhino (see sidebar for gratuitous picture of a Rhino).  You would have to know me quite well to understand how deep it goes but suffice to say that it is a product of my life philosophy and I do not remember the last time I was truly offended.  That being said, I am hopefully not a jerk and do not expect others to hold to the same standard.  However, because I cannot use myself as a guage I have had immense difficulty walking the line between offensiveness and expressiveness.  This is something that I have been actively working on for years, and I would like to think with results (I somehow swindled a lovely girl into an engagement even).  Hence my keen interest in this current discussion of appropriateness.

All conversation of gender roles, stereotypes, and feelings aside I think the argument of really boils down to this:  

1.  The more edgy/expressive/offensive you get the more thin-skinned people you will exclude.  
2. If a community allows offensive behavior repeatedly then the offended parties will be excluded from that community.  
3. Why in the world would a tech movement want to exclude people – many brilliant people even – solely on these grounds?

Logically, this argument is a check-mate.  You want your ideas to be inclusive?  Then you must work to be inclusive as well.

But there is a caveat.  Many things are offensive; why would thin-skinned people want to spend their lives in an offended state?  Seriously, a lot of this stuff is actually pretty funny, we’d for love you to join in.   

So here’s the proposal, how about we BOTH work on this?  Yes that means you rabbits as well as us rhinos.  I will continue learning about sensitivity, about people’s feelings, about why I shouldn’t use the N-word even though I think its constant use would strip it of its power, and all the other social norms.  I won’t compromise my expressiveness, but I will try to consciously and responsibly make an decision of who I will offend.  You in the meantime should watch George Carlin and Bill Hicks, try to see what’s funny about Family Guy, and maybe even occasionally read SomethingAwful all with an open mind.  You must try to see humor on its own terms and to distinguish an bad person from a crass one.  You should do this seriously and with commitment.

The thing is that many people will probably take even this suggestion as offensive in itself, that I am suggesting people with “refined social standards” need to change as well as us juvenile bozos.  Here your own argument for sensitivity stands against you.   You must realize that for many people being sensitive to your feelings is f*ing difficult.  Like really really really hard.  I know that checking my speech almost always leaves a bad taste in my mouth that I have to then obsess over for hours afterwards. And if you still don’t care then F you.

I don’t have a crescendo of an ending planned so let me just state that I did indeed learn some things from this whole affair and am quite happy at the ideas that it has brought to the forefront.  I doubt that someone will seriously take me up on my challenge and I will continue down my own path of social learning regardless but if you’re really going to be intellectually honest you can hopefully admit that I have a point.  And then tag, you’re it.

Reading your blog has always been a bit like programmer masturbation, it mostly serves to make the reader feel great about what an inquisitive and intellectual developer they are.  That’s ok though, it keeps people reading and just through the sheer volume and accessibility of your writing you’ve pounded into people’s skulls some extremely useful ideas, frequently without them even realizing it.

Heck, it was you that got me into reading programming blogs (tip of the hat to Steve Yegge as well) and that is precisely why this whole tiff with Uncle Bob is just silly and your latest defense the lamest of all.  You reach far more people than Uncle Bob does, you acknowledge that the SOLID principles are good ones, you say that the problem is with capturing the ear of the uninformed – and then you put them down?  Give me a break!

I don’t have time to rant at length like others have but consider this:

You know who were really the original unreachables?  Cavemen.  Completely in isolation from each other they decided it a hassle constantly having to seek out rock outcropping roofs and moss mattresses and all on their own they started piling rocks on each other to make houses.

Sure when the Assyrians invented the arch the Egyptian and Aztec builders didn’t hear about it, but eventually the Romans came along and in that very Roman way searched out the best ideas and decided to apply them to their own projects.  Good thing the Assyrians didn’t have bloggers.  They might have declared the arch unfit for popularization due to the infeasability of their marketing.

We’re at the very beginning of this stuff, lets encourage the good ideas, no matter who is listening.

Update: InfoQ has a roundup of the whole debacle.

Overall the experience hasn’t been too bad though.  I’ve been managing to maintain a decent rapport with their project manager and team lead, deadlines have been missed, but no more than I secretly expected, and overall they seem like fairly competent guys.  Their work isn’t innovative, Agile, testable, or well factored, but its decent enough.

Except for the exceptions.

Browsing one of their recent commits to our SVN lately (ok, so technically speaking they couldn’t figure out Subversion so they ftp-ed and I did the commit for them) I was shocked to discover the following error-handling anti-pattern repeated 41 times!

try {
  // Do Stuff
}
catch(Exception ex) {
  throw new Exception(ex.Message);
}

Do I get to name it?  Let’s call it the message repackaging anti-pattern.  And in case you’re not already reeling from this, the following is a mildly edited-down version of the letter I sent (Notice the eschewed profanity.  I believe a not insignificant achievement.)

try {
 // ...
}
catch(Exception ex) {
 throw new Exception(ex.Message);
}

In any case, the recent commit has only 38 instances of this error.  So at least we’re getting better!