A friend asked me recently, “do all these good organisational and development practices really make that much of a difference to the successful outcome of a project?”. We all know following good practices improves the lives of those involved, but do they really help to achieve a business success? After all, some extremely-late, over-budget, bloated, misguided and poor-quality software development projects do go on to make the business a lot of money, therefore can be deemed to be successful. But at what price? Projects like this often leave a path of destruction behind them. The stress, political battles, low morale, fear, late nights, strained relationships, blood, sweat and tears of the people who worked hard under pressure, following poor organisational and development practices. That’s the difference. Good practices not only help to achieve a successful business outcome, they also help to build a good working environment. There is a human factor to the successful outcome of a project. Let’s not forget that.

The Single Responsibility Principal (SRP) states that every object should have a single responsibility, and that all its services should be aligned with that responsibility. By separating object responsibilities we are able to achieve a clear Separation of Concerns. Objects need to collaborate with each other in order to perform a behaviour. I find I use two distinct styles of collaboration with other objects which I have called internal and external collaborators.

The principals of object collaboration are nothing new, but I have found that defining these roles has helped me to better understand how to design and test the behaviour of objects.

External Collaborators

External collaborators are objects that provide a service or resource to an object but are not directly controlled by the object. They are passed to an object by dependency injection or through a service locator. An object makes calls to its external collaborators to perform actions or retrieve data. When testing an object, any external collaborators are stubbed-out. We can then write tests that perform an action, then determine if the right calls were made to the external object.

Examples of external collaborator objects include: services, repositories, presenters, framework classes, email senders, loggers and file system wrappers.

We are interested in testing how we interact with the external collaborator and not how it affects the behaviour of our object. For example, if we are testing a controller that retrieves a list of customers from a repository, we want to know that we have asked the repository for a list of customers, but we are not concerned that the repository returns the correct customers (this is a test for the repository itself). Of course, we might need some particular customer objects returned by the stub for the purpose of testing the behaviour of the controller. These customer objects then become internal collaborators, which we’ll come to next.

External collaborators can be registered with an IoC container to manage the creation and lifecycle of the object, and to provide an instance to dependent objects.

Internal Collaborators

Internal collaborators have a smaller scope than external collaborators. They are used in the context of the local object to provide functions or hold state. An object and its internal collaborators work together closely and should be treated as a single unit of behaviour.

Examples of internal collaborators include: DTOs, domain entities, view-models, utilities, system types and extension methods.

When testing an object with internal collaborators, we are interested in the effect on behaviour, not the interaction with the object. Therefore we shouldn’t stub-out internal collaborators. We don’t care how we interact with them, just that the correct behaviour occurs.

These objects are not affected by external influences, such as a database, email server, or file system. They are also not volatile or susceptible to environmental changes, such as a web request context. Therefore, they should not require any special context setup before testing.

We don’t get passed an instance of a internal collaborator through dependency injection, instead they may be passed to us by an external collaborator (e.g. a repository returning an entity), or we create an instance within our own object when we need it (such as a DTO).

By understanding the roles and responsibilities of collaboration between objects, our design becomes clearer and tests are more focused and easier to maintain.

The Test-Driven Development cycle of red-green-refactor gets you into a rhythm of writing a failing test, making it pass and then refactoring. It is important that we get feedback early if something is broken so we can keep this rhythm going. Stopping to run tests and wait for the result can impact this rhythm and distract our focus on the next step.

The concept of continuous testing came from research carried out by the Program Analysis Group at MIT. They found that continuously running tests increased developer productivity and reduced waste. You can find more information about continuous testing in this blog post by Ben Rady.

Tools For Continuous Testing

There are a number of tools available that support continuous testing. Ruby has AutoSpec, a command-line continuous testing tool. Java has Infinitest, a plug-in for Ecplise and IntelliJ. In .NET, James Avery has been working on AutoTest.NET and I was involved in a project to write a Visual Studio add-in called QuickTest. The main problem I have found with using these tools for .NET development is the complexity of real-world project structures. Whenever I’d try to use QuickTest on real projects, I found I was dealing with very different project structures, test configurations and naming conventions. It was really difficult to factor all these configuration scenarios into a tool that is designed to "discover" which unit tests to continuously run.

That gave me the idea for AutoBuild.

Introducing AutoBuild

AutoBuild is a continuous testing tool for .NET that runs a NAnt script whenever a file is saved. You simply tell AutoBuild to watch a particular folder and give it a simple NAnt script to run whenever a file changes. The advantage of this approach is that all the complexity in customising a continuous testing tool for your project is contained within the NAnt script. The NAnt script is likely to be a small subset of an actual build script. For example, you might not want tests that hit the database to be run on every save, so you could add a "DatabaseTest" attribute to your test and configure the NAnt script to ignore all tests with that attribute.

If you aren’t familiar with NAnt, don’t worry. A default build file is provided and you only need to modify the solution path and unit test assembly path properties.

Currently, the test failure output in AutoBuild only supports the NUnit task. I plan to add support for other unit test frameworks in the near future. I am also interested in adding support for Rake build scripts.

Using AutoBuild

You can find the source code for AutoBuild here:
http://code.google.com/p/autobuildtool/

To get started, get the source and run the default.build.cmd file. This will run the build and create an output folder that contains the AutoBuild assemblies, along with a sample build script and command file. You can copy these to your own project and customise the build file for your solution.

To run the "dog food" sample, simply run the autobuild.cmd file in the root AutoBuild folder (not the one in the output folder). This will open AutoBuild and start watching the source directory. Then open the AutoBuild solution and modify any .cs file. This should kick-off the build and run the tests. Mess around with the code to watch the build fail. Note that this autobuild.build script is configured to only run tests not marked with "integration".

AutoBuild will produce an output with build errors and failing tests in red and successful builds and test runs in green. You can change the output colours by modifying the log4net settings in the AutoBuild.Console.exe.config file. You can also switch on debug output by changing the log level to debug.

AutoBuild is ideally suited to a dual-monitor set up, with Visual Studio in one monitor and AutoBuild in the other. This allows you to focus on writing code and check the status of the build at a glance. I would like to integrate the console into Visual Studio for cases when you only have one monitor (e.g. working on a laptop). This might involve writing a Visual Studio add-in that allows you to load the console into the IDE.

Please submit any issues to the project on Google Code. If you have any comments or suggestions, then please feel free to contact me.

Many .NET applications I see that have a so-called Service-Oriented Architecture (SOA) use a technology such as Windows Communication Foundation (WCF) to treat services as if they were local objects. You call methods on the remote object in the same way as you would call a local object, only rather than executing locally, the request is sent to a remote service for processing which may then return a response. This is known as a Remote Procedure Call, or RPC. Often these calls can cause the application to hang while waiting for a response. The usual way to handle this is to call the service method asynchronously, providing a method to call when a response comes back. This allows your application to continue processing after the request is made.

Sounds simple enough, but I have found these direct request-response calls can lead to a fragile and unreliable application that is tightly-coupled to the services it calls. If for some reason a service is not available, your application may stop functioning. Sure, you can build in error-handling, but it then becomes the responsibility of your application to manage the dependency on the service.

Recently, Jennifer Smith and I were discussing the unreliable nature of these architectures on Twitter, when Udi Dahan, SOA specialist and creator of NServiceBus, pointed us to a recent blog post of his that explains why we shouldn’t call services as if they were real objects. Udi suggests that there is a better way to handle calls to services and that is to use a message queue. He also makes the point that we need to stop treating services as local objects and use messaging as in integral part of the application architecture:

A queue isn’t an implementation detail. It’s the primary architectural abstraction of a distributed system.

So, if you’re developing a distributed application, use a message bus to communicate between applications. The message bus is responsible for transporting messages between applications. When you use a message bus, the application that sends a message is no longer coupled to the receiver.

I am currently converting a fragile request-response service-based application to use messaging with the NServiceBus message bus. I hope to significantly improve the performance and robustness of the application by making messaging a first-class citizen in the architecture, and not just an abstraction.

For more information on messaging and NServiceBus, check out:

• An overview of NServiceBus
• Udi Dahan’s blog

This book also contains excellent information on designing and developing messaging solutions:

• Enterprise Integration Patterns

I’m going to take a short diversion from my series on BDD with ASP.NET MVC to talk about the difference between Features and Specs in Behaviour-Driven Development.

I am currently reading the beta version of The RSpec Book. This is an excellent book that covers doing BDD in Ruby using RSpec and Cucumber. From reading this book, I have come to realise there is a distinct difference between higher-level user acceptance criteria (features) and and lower-level context-specifications (specs).

Features

Features are the things that the customer is likely to be most concerned with. They are high-level behaviours that are derived from the acceptance criteria of a user story. They are purely concerned with how the user interacts with the application and don’t provide any details of implementation.

Features can be used to facilitate communication with the customer on what business objectives the application should achieve.

A feature consists of a user story and one or more example scenarios, which serve as our acceptance criteria. An example of a feature would be:

Story: Account Holder withdraws cash

  As an Account Holder 
  I want to withdraw cash from an ATM
  So that I can get money when the bank is closed

  Scenario 1: Account has sufficient funds 
    Given the account balance is $100
    And the card is valid
    And the machine contains enough money
    When the Account Holder requests $20
    Then the ATM should dispense $20
    And the account balance should be $80
    And the card should be returned

Features can be turned into automated acceptance criteria. In Ruby, we can use Cucumber to parse a plain-text file and run each scenario against the application. These are usually slow-running, end-to-end integration tests. In .NET we would use a BDD framework such as NBehave, or a standard unit-testing framework to implement the features as automated acceptance criteria.

Recently, I have been using Cucumber for automating the acceptance criteria for a .NET application, using Waitr to drive the browser. With IronRuby, we will be able to access our .NET objects directly from Cucumber. As of this post date, IronRuby does not work with Cucumber, but a fix should be out very soon.

Specs

When we have defined a new feature, we must create the objects required to implement it. To do this we need to “drop-down” to the object-level and use a context-specification style to define how these objects should behave.

Specs are implemented as fast-running, unit-level tests with stubbed dependencies. In Ruby, RSpec is used to define the specs. In .NET we would use a standard unit-testing tool, such as NUnit.

A spec consists of an action on an object, within a certain context, and the observations made from that action. An example of a spec would be:

When ATM requests withdrawal and account has sufficient funds
  Should check account balance
  Should send “Please wait” message to screen
  Should begin transaction
  Should withdraw funds from account
  Should dispense cash
  Should end transaction
  Should return card
  Should send “please take your card” message to screen

These steps describe the interaction between our object and its dependencies. They do not necessarily reflect the user’s observations (e.g the user doesn’t observe a transaction taking place).

We are not as concerned about testing the state of an object as we are about defining how it interacts with other objects. For instance, using the Model-View-Controller pattern, if we’re specifying a controller, we want to make sure an action sends a certain “message” to the view, rather than testing how it affects the state of the view. By specifying interaction over state, we are better able to define the roles and responsibilities of our objects.

I will try to incorporate some of this into the PlaylistShare sample application to demonstrate the distinction between Features and Specs.

In part one, I introduced the PlaylistShare project, created some initial user stories, defined the acceptance criteria and created a template for writing executable specifications. In this part, I am going to write some executable specs for viewing playlists and implement the behaviour to make them pass. You can download the source code at the end of this post.

There a couple of approaches you can take when writing specs for an ASP.NET MVC user interface. Either you can run them directly against the UI from inside a browser, using a tool such as WaitiN. Or, you can drop in just below the UI and run the specs against the controllers. I prefer running them against the controllers as they run much faster and are not susceptible to changes to the HTML elements. However, you may find some aspects are better specified using a UI testing tool, such as behaviour that relies heavily on client-side scripting, which the controllers know nothing about.

I will be starting with the executable specification template I created in part one:

namespace view_playlist_specs

{

    namespace scenario_of

    {

        public abstract class listener_views_playlists : Specification<PlaylistController>

        {

            protected override PlaylistController create_subject()

            {

                // Create the system under test

                return new PlaylistController();

            }

            protected void given_a_list_of_playlists()

            {

                // Establish a list of playlists

            }

        }

    }

    namespace viewing_a_list_of_playlists

    {

        [TestFixture]

        public class when_the_listener_views_the_playlists 

            : scenario_of.listener_views_playlists

        {

            protected override void setup_scenario()

            {

                // Arrange

                given_a_list_of_playlists();

            }

            protected override void execute_scenario()

            {

                // Act

            }

            [Test]

            public void should_display_a_list_of_playlists()

            {

                // Assert

            }

            [Test]

            public void playlists_should_be_ordered_by_date_submitted_from_newest_to_oldest()

            {

                // Assert

            }

        }

    }

}

The first scenario we are going to implement is:

Story: Listener views playlists

As a playlist listener, I can view a list of playlists that have been submitted, so that I can find a playlist I might enjoy.

Scenario 1: Viewing a list of playlists

Given a list of playlists

When the listener views the playlists

Then should display a list of playlists

  And playlists should be ordered by date submitted from newest to oldest

First, lets create a new ASP.NET MVC application and add a PlaylistController to give us a subject to work with.

[HandleError]

public class PlaylistController : Controller

{

    public ActionResult Index()

    {

        return View();

    }

}

Now that we have a controller, let’s specify the first outcome of the scenario.

[Test]

public void should_display_a_list_of_playlists()

{

    the_view_model.should_be_equivalent_to(playlists);

}

The outcome states that a list of playlists should be viewed on the page.

the_view_model is a property on the spec base class that wraps calls to ProductsController.ViewData.Model. This makes the code slightly more readable. We can use ViewData.Model on the controller to pass data back to the view. In this case we want to pass back a list of Playlist objects.

You will notice I have used a method called should_be_equivalent_to to verify that the_view_model contains the same elements as playlists. This is an extension method defined in a SpecificationExtensions class I have added to the project. This class contains some helpful extension methods that wrap-up calls to NUnit assertions. This enables us to assert conditions directly on the objects, producing slightly more readable outcomes. Again, this is a personal preference and you can use ordinary Assert calls if you wish.

Running this spec should result in a failure, as we are not yet returning any playlists from the Index() controller method. We need to provide the controller with our list of playlists. To do this, we need to somehow pass a list of Playlist objects to the controller. The best way to do this is to use Dependency Injection and Mocking to pass a Repository containing our Playlist objects into the controller. Woah! Sounds complicated. But, it’s actually quite simple…

Let’s modify the PlaylistController to take an IPlaylistRepository and initialise a field in the constructor.

[HandleError]

public class PlaylistController : Controller

{

    private readonly IPlaylistRepository _playlistRepository;

    public PlaylistController(IPlaylistRepository playlistRepository)

    {

        _playlistRepository = playlistRepository;

    }

    public ActionResult Index()

    {

        return View();

    }

}

Now we need to pass an instance of this repository when we create the PlaylistController in our specs. To do this I am going to generate a stub using RhinoMocks. This creates a runtime implementation of the IPlaylistRespository that we can pass into the controller.

protected override void setup_scenario()

{

    playlist_repository = MockRepository.GenerateStub<IPlaylistRepository>();

}

protected override PlaylistController create_subject()

{

    return new PlaylistController(playlist_repository);

}

The setup_scenario method gets called right before create_subject, so we can use this to create any dependencies before the PlaylistController gets instantiated. Any scenarios can create additional context by overriding the setup_scenario method.

Now we need to add a GetAll() method to IPlaylistRepository that allows the PlaylistController to retrieve a list of Playlist objects.

public ActionResult Index()

{

    var playlists = _playlistRepository.GetAll();

    return View(playlists);

}

Back in our specs, we can now tell the stubbed playlist_repository to return some Playlist objects whenever the GetAll() method is called.

protected void given_a_list_of_playlists()

{

    playlists = new List<Playlist>

                    {

                        new Playlist(),

                        new Playlist(),

                        new Playlist()

                    };

    playlist_repository.Stub(r => r.GetAll()).Return(playlists.ToArray());

}

Our spec should now be passing! We have now confirmed the controller is passing a list of playlists to the view to display on the page.

So, let’s write an assertion for our next outcome: “playlists should be ordered by date submitted from newest to oldest”. Here we verify that the Playlist objects sent to the view are ordered by date-submitted in a descending order.

[Test]

public void playlists_should_be_ordered_by_date_submitted_from_newest_to_oldest()

{

    the_view_model.should_be_ordered_by_descending(p => p.DateSubmitted);

}

For this to compile we need to add a DateSubmitted property to the Playlist object.

I have created a helper method called should_be_ordered_by_descending that will verify that the playlists are ordered correctly. It’s really useful to create extension methods for complicated assertions to better explain what is being verified.

We can now make this spec pass by using LINQ to order the list of Playlist objects in the controller action before they are returned to the view.

public ActionResult Index()

{

    var playlists = _playlistRepository.GetAll();

    return View(playlists.OrderByDescending(p => p.DateSubmitted));

}

Here is the output from the Resharper test runner:

Using these naming conventions means that if a spec fails, it’s easy to identify what behaviour is causing the problem. You also get clear, concise, executable documentation that describes how your application behaves.

You might have noticed that I have been implementing the playlist controller without even running the web site. By implementing the controller first, we can focus on the core behaviour of the application without being concerned about how it is presented. In the next part, we will create the view that displays the playlists on the page.

Download the source code for Part 2

Introduction

Welcome to the first post in a series where I hope to demonstrate creating an ASP.NET MVC application using Behaviour-Driven Development (BDD).

I agonised over how to introduce this blog post. In the end, I figured it would be best just to get straight into it! There are plenty of excellent articles that introduce the concepts behind both BDD and ASP.NET MVC, so I won’t bother repeating it here. I will explain core concepts along the way and provide links to further information. If you feel that I haven’t explained something properly, or have missed something, then please post a comment and I’ll try to elaborate further.

Right, let’s get started. The application I am going to build is a playlist sharing web site aptly called PlaylistShare (slightly unimaginative, but if you have a better name, let me know! . Music streaming services like Spotify are becoming increasingly popular and a number of sites have sprung up that allow you to share playlists with other people. I don’t intend this example to be anything unique or new, but I thought it would be an interesting subject and not yet-another-storefront example.

I will provide a link to download the source code at the end of each post. I have also created a Google Code project to host the source code.

It All Starts With a Story

BDD is an outside-in development process. We start by identifying goals and motivations, then drill down to the features that will achieve those goals. So, I’ve come up with a few user stories to get us started.

Story: Listener views playlists

As a playlist listener, I can view a list of playlists that have been submitted, so that I can find a playlist I might enjoy.

Story: Listener views playlist details

As a playlist listener, I can view the playlist details, so that I can get more information about the playlist.

Story: Contributor submits a playlist

As a playlist contributor, I can submit a playlist, so that others can listen to it.

There are a lot of other features I can add, but as a “business”, these are my top priorities and will allow me to get something functional delivered first.

Defining Acceptance Criteria

In order to determine what behaviour to implement, we need to create a list of acceptance criteria for each story. The acceptance criteria allows us to define when a story is “done”.

Note: this is a very important stage. It allows all members of the team to share a common understanding of what the system is meant to do. It is tempting to jump straight to writing the executable specifications, but this stage needs to be carefully considered and have input from the customer and testers.

We will define the acceptance criteria as example scenarios using a given/when/then vocabulary.

Story: Listener views playlists

Scenario 1: Viewing a list of playlists
Given a list of playlists
When the listener views the playlists
Then should display a list of playlists
  And playlists should be ordered by date submitted from newest to oldest

Story: Listener views playlist details

Scenario 1: Viewing playlist details
Given a playlist
When the listener views the playlist details
Then should display the playlist details
  And should display a link to listen to the playlist

Story: Contributor submits a playlist

Scenario 1: Submitting a playlist
Given a playlist
When the contributor submits the playlist
Then should submit the playlist
  And should display a message confirming the submission was successful

Scenario 2: Submitting a playlist without a name
Given a playlist without a name
When the contributor submits the playlist
Then should display a message saying the name is required
  And should not submit the playlist

Now that we have defined some acceptance criteria, we can create the executable specifications used to drive the implementation (a fancy way of saying, “write some tests!”). As we go forward we will probably identify other features we would like. We will make a note of these then add them to our next “iteration”.

Writing Executable Specifications

In BDD, tests are called specifications. This is mainly to get away from the notion that we are “testing”. Rather, we are defining behaviours that will drive the development process. We will still end up with a full suite of automated tests, but this is merely a very handy side-effect, not the goal, of BDD.

There are a number of BDD frameworks available for .NET, the most well-known of these being NBehave. However, these frameworks can be difficult to get started with and can distract us from the main purpose of BDD, which is to effectively describe the application behavior. This is not because these frameworks are bad, but is more to do with the constraints of the C# language. BDD frameworks are much more effective in languages like Ruby, where the syntax makes it very easy to write readable specifications using frameworks such as RSpec and Cucumber. For this example, I am going to stick with using NUnit and structure the test classes and member names to enable us to write BDD specifications. It will be a glorious day when when eventually see RSpec and Cucumber working on IronRuby and integrated seamlessly with our .NET applications. Until then, this is my current preference for writing BDD-style specifications in real-world applications.

I use a common Specification base-class to provide a framework for writing the specifications. This simple class contains the NUnit setup/teardown methods, handles exceptions and coordinates the various stages of executing a scenario.

These are a few conventions I use when writing BDD-style specifications:

• Specification names are lowercase with underscores. This_is_to_make_the_specifications_more_readable. It is a personal preference, but I find PascalCaseNamingBecomesHardToReadForLongSentences (see what I did there… heh).
• One test-fixture per scenario. Each test fixture represents a scenario of the story.
• Each test-fixture is wrapped in a namespace that describes the scenario. This allows us to easily navigate the scenarios and prevents naming conflicts with other actions. This becomes important when we have the same action in different scenarios.
• Each test-fixture name defines the action. An action is the “when” part of a scenario. It is the event that causes the behaviour.
• Each test-fixture derives from a base class that describes the story. By inheriting from a base class, we can provide common set up data that is shared across all scenarios in the story. It also provides us with a handy reference back to the original story.
• The context is set before executing the action. The context is the “given” part of a scenario. The context sets the state of the system-under-test and its dependencies before the action is invoked. Wrapping setup code in helper-methods makes it easy to see what context we are creating and to reuse common setup steps.
• One test per outcome. An outcome is the result of an action, the “then” part of a scenario. We may have many outcomes from an action, but we should only be testing for one thing per outcome. So try to only make one assertion per test method. Test for other outcomes in separate test methods.

The outline for the first scenario looks like this:

namespace view_playlist_specs

{

    namespace scenario_of

    {

        public abstract class listener_views_playlists : Specification<PlaylistController>

        {

            protected override PlaylistController create_subject()

            {

                // Create the system under test

                return new PlaylistController();

            }

            protected void given_a_list_of_playlists()

            {

                // Establish a list of playlists

            }

        }

    }

    namespace viewing_a_list_of_playlists

    {

        [TestFixture]

        public class when_the_listener_views_the_playlists 

            : scenario_of.listener_views_playlists

        {

            protected override void setup_scenario()

            {

                // Arrange

                given_a_list_of_playlists();

            }

            protected override void execute_scenario()

            {

                // Act

            }

            [Test]

            public void should_display_a_list_of_playlists()

            {

                // Assert

            }

            [Test]

            public void playlists_should_be_ordered_by_date_submitted_from_newest_to_oldest()

            {

                // Assert

            }

        }

    }

}

Download the source code containing the outline for the first scenario.

I hope this has been a helpful way to get started. I will explain a lot more about writing specifications in upcoming posts. Please feel free to post any questions or comments. In the next part of this series, I will begin implementing a playlist controller and passing the scenarios.

We .NET developers have always had the security blanket of a general purpose language like C# or VB.NET that we’ve been able to use for pretty much anything we need. However, it is becoming increasingly important for a developer to know several languages covering different paradigms and to have the ability to choose the best language for the problem at hand.

The Pragmatic Programmer recommends learning a new language every year. I’m currently taking that to the extreme and have several languages on the go.

C

I never learned C. I went straight from a basic understanding of Java to ASP/VBScript (ah, those were so not the days). So now I’m playing catch-up, learning about exciting things like pointers and memory allocation – all things that I have heard about many times, but never fully understood.

I’m current reading The C Programming Language, which is a very concise (only 274 pages) and superbly written book. If you know C#, then most of what’s covered will not be new. In fact, C is nowhere near as intimidating as I thought it would be, and it’s really made me appreciate the things I took for granted in modern C-based languages.

Haskell

Functional languages are hitting the mainstream, big time. I learned basic functional language principals using Haskell at Uni over 10 years ago. Back then it was pretty much an academic language that complemented a mathematics paper I was doing. These days, functional languages offer a promising solution to concurrency problems with software running on multi-core processors. Haskell is a purely functional language, which means you cannot sneak in a for-each loop when the going gets tough. It’s a great way to learn how to solve a problem in a functional manner, using a functional mindset.

It’s easy to get started with Haskell. I’m currently making my way through this excellent tutorial: Learn You a Haskell for Great Good.

Javascript

I already know Javascript. Or at least I thought I did. Javascript has made a big comeback recently with the increasing popularity of client-side web programming for creating rich websites. The emergence of excellent frameworks like JQuery take the pain out of cross-browser support and DOM manipulation, which has always been the bane of Javascript development. On the surface, Javascript looks like a weak language with some bad features. But strip away the bad parts and there’s a really neat, powerful and dynamic language that runs pretty much anywhere!

With web applications becoming increasingly reliant on rich-client capabilities, it is important for any web developer to have a solid understanding of Javascript. If you are already familiar with Javascript, I would recommend the book Javascript: The Good Parts to take you to the next level.

Ruby

I previously posted on my adventures in Ruby and mentioned some good resources for getting started. Ruby is a very powerful, dynamic and portable language that can be used for many tasks big or small. From building full-scale web applications using Rails, to writing build scripts using Rake. Many .NET developers are replacing the XML-heavy NAnt build files with Rake scripts, which allow much greater flexibility by using the expressiveness of Ruby to coordinate the build tasks. The potent combination of RSpec and Cucumber for writing BDD specs make good use of Ruby’s dynamic and readable syntax. With the release of IronRuby on the horizon, .NET developers will be able to get the benefits of this great language running natively on the .NET Framework via the Dynamic Language Runtime.

F#

F# is a multi-paradigm language for the .NET framework and encompasses both functional and imperative elements. I’ve barely scratched the surface of F#, but it looks very promising indeed. The more we require functional elements in our day-to-day programming, the more important it is to have a language that fully supports functional programming. C# 3.0 has some great functional features, such as LINQ and lambda expressions, but F# looks to offer much more powerful set of functional features.

Conclusion

So, I have a lot of learn! I don’t expect to become an expert in all these languages at once. But I think having a basic understanding of each has already helped me to improve my general programming skills and to approach problems in different ways.

If you are interested in learning a new language, I would recommend you know at least one dynamic and one functional language. If you’re feeling particularly up for a challenge, try LISP

Yesterday I attended the Software Craftsmanship 2009 conference held at the BBC media centre in London. Overall, it was a great day with some really interesting sessions covering a wide variety of topics. It was especially interesting to share ideas and experiences with developers from different backgrounds using different languages and platforms.

The first session I attended was Pitfalls in Test Authoring with Dave Cleal and John Daniels from Syntropy. This session was an open discussion on identifying test anti-patterns. Some really good points were raised and the discussion was very open and frank. There was some debate on whether unit tests should ever hit the database and what the scope of a unit test should be. This discussion later led to an open spaces talk on functional (integration) testing versus unit testing.

The next session I attended was Gojko Adzic’s talk on Specification Workshops. Gojko gave an excellent presentation on running workshops for the whole team to discuss the requirements for an iteration. One point that stood out for me was that the workshop should focus on what the software needs to do and not how to do it.

Over lunch I had a good chat to some java developers on why we should minimize code comments and the use of NOJOs ("Non Object-oriented Java Object", or DTOs to us .NET developers).  I also had a chance to catch up with some ex-BBC colleagues who were attending the conference.

After lunch I went to a session on Responsibility-Driven Design with Mock Objects by Willem van den Ende and Marc Evers. This was a live pair-programming session developing a text-based adventure game using RSpec and Ruby. The tests were focused on object collaboration rather than state. It was really interesting to see the use of mock objects in Ruby. I also found the focus on pure mocking for testing object collaboration to be very different from using mock objects to simply replace dependencies.

The next session was Empirical Experiences of Refactoring in Open Source by Steve Counsell from Brunel University. Steve presented his findings on the use of refactoring in open-source software. His findings were interesting but I was left a bit confused by what the results of the study meant for software teams. I would be interested to learn more about the conclusions of the study.

The final session I attended was on Test-driven Development of Asynchronous Systems by Nat Pryce. Nat gave a good talk on his experiences with end-to-end testing of asynchronous systems.

We finished the day with a tour of the BBC Television Centre and a few beers in the bar upstairs. A few of us got to see Jonathan Ross recording his Friday night show and apparently U2 were guests. Unfortunately we didn’t bump into Bono, but we did get to have a photo with a TARDIS.

All in all it was a great day and I would like to thank Jason Gorman for organising this excellent event.

Ron Jeffries explains why software quality and speed of delivery are not mutually exclusive. If you want to continually deliver working software quickly, then you need to maintain high quality:

http://xprogramming.com/blog/2009/02/01/quality-speed-tradeoff-youre-kidding-yourself/

Uncle Bob has also posted his thoughts:

http://blog.objectmentor.com/articles/2009/02/03/speed-kills

I often find there is a lot of focus on delivering software quickly, but not so much on maintaining quality. I think this is because it is generally considered that maintaining high quality means greater expense and later delivery. However, the higher the quality of code, the better able we are to deliver working software quickly and repeatedly. My belief is that the quality leaver should never be touched, or you risk taking on crushing debt.