We decided to create the group in August last year with the idea of getting together our local developer talent to talk about varying aspects of development and share ideas. The first meet-up was held at Hull University in early December and we had over 30 attendees. The really interesting part was the cross-section of people who attended:

• business owners
• account handlers
• designers
• front-end web developers
• back-end developers
• students and lecturers from Hull University

For the first meet-up we had two talks. One on the Ruby on Rails ecosystem and the other on the challenges of launching, and growing products on an International level from an office in the pioneering city of Hull. Both talks went down very well with the attendees.

Since then we’ve had two further meet-ups which have proven nearly as popular as the first meet-up and again the cross section of those that attended was similar to the first meet-up.

For details of all the meet-ups so far see the Hull Digital meet-up page.

Hull University Involvement

One really great aspect of the group has been the involvement of the University and its students. It’s been really interesting to see how well prepared the students are for when they leave and start searching for work. They are very much up to speed on the latest developments within the industry. If you are looking for new development talent then I would look no further than some of the students graduating from Hull University.

Why should you attend?

The developer group offers companies and individuals a great opportunity to enhance their knowledge, and meet like minded people.

To quote a tweet from an attendee to one meet-up

“Run a team of devs in Yorks/Humber? Give the team a morning off & send to a #hulldigital dev evening meet for top (free!) teaching.”

Still need a reason, then keep reading.

• Students – gain practical insight into how your academic experience can be applied in the commercial world.

• Freelancers / Agency workers – improve your knowledge and develop collaborative partnerships with other talented developers.

• Business Owners – opportunity to network, find talented freelancers and seek out the best graduates.

The next meet-up

The next meet-up will be held on 24th June at Fudge Cafe in Hull. We have lined up two excellent and highly respected speakers in Peter Cooper and James Gregory. To find out more about the meet-up, the speakers and their talks go to the Hull Digital meet-up site.

The Future – Keeping the momentum rolling

As with all groups we are reliant on the involvement of local businesses and individuals. We are always looking for suggestions on topics, speakers and even sponsorship. If you can help with any of these, please let us know.

Finally, we’d like to you to take a few moments and complete the Hull Digital Developer group questionnaire to help us keep improving the group. Your feedback will be greatly appreciated, it’s only short I promise!

The format of the next meetup will different to the first as there are not going to be any speakers this time around.  Instead we are hoping to make it a discussion evening, with everyone participating. This should hopefully be  a good way for all the attendees to learn more about each other.

To make the discussions relevant to the majority of developers what we hope to do over the next couple of weeks is gather suggested topics from yourselves, and then ask attendees to vote on the list of topics.  The most popular topics will then be discussed at the meetup.

To get the ball rolling there is a list of topics below.  This list has been created based upon comments from previous blog posts, so thanks to the community for those ideas.

1. Document-oriented Databases (e.g. MongoDB and CouchDB)
2. Testing Techniques and Tooling
3. Continuous Integration
4. The Agile Manifesto
5. The principles of SOLID
6. Outside-in Development

Clearly there are many, many more topics that could be suggested, so please let us know what is relevant to yourselves.  Whether it’s front-end web development techniques, or object oriented programming techniques, please let us know.  Remember you don’t have to be an expert on the topics you suggest, it may well be you know very little and want to talk to other developers to gain a better understanding.

Today and tomorrow, there is an opportunity for us to get involved and see how the plans are progressing (thanks to @duncmc for letting us know about this, and apologies for not letting you know sooner as it is the first we heard about this!).

“Don’t forget to pop into Arc tomorrow or Friday to see the public exhibition being hosted by Arc on behalf of Hull Forward, of the Fruit Market revised development brief. The exhibition is in the Arc building’s main space on Thursday 19th & Friday 20th November and is open between 10am – 4pm.

Representatives from Hull Forward and Yorkshire Forward will be staffing the exhibition from 2.30 – 3.30pm to answer any questions that the you may have about the brief, and Hull Forward are also producing evaluation materials for you to complete if you would like to have your say.

You are also invited to our third ever public Design Review Panel, which takes place from 12.30-2.30pm tomorrow (Thursday) here at Arc. 
Hull Forward and Yorkshire Forward will be represented at the Design Review Panel”.

Who / what is Arc?

Arc is working with people to make great places. They are the architecture centre for Hull and the Humber sub-region, and they’re part of a national network of architecture centres across the UK.

If you can get along, we hope to see you there – it is important that we help shape the future of Fruit Market to meet the needs of the digital community.

Please do add your comments and thoughts here, or on the original post.

The purpose of the event is to assess the level of potential demand from local businesses and highlight the opportunities for meanwhile uses such as studios, exhibition space and workspace following the relocation of the Wholesale Fruit Market to Priory Park on the outskirts of the city later this year.

You are invited to attend a briefing session about opportunities for creative and media businesses at the Fruit Market, Hull to be held at 62-63 Humber Street (Hull Fruit Market) from 5.30 – 7.30 pm on Thursday 24th September.

Toby Hyam from Yorkshire based Creative Space Management has been commissioned to help Hull Forward to explore the reuse of these properties as quickly as possible pending the long term regeneration of the area. Toby and his colleague Paul Fallon will facilitate the event on the 24th September, providing information about the opportunity and how its supports the delivery of the long term plans for the Fruit Market.

Hull Forward is working closely with Hull City Council and a range of key public and private sector partners to regenerate the area. The partners involved have identified the potential for artists, creative business and social enterprises to get involved and be a major part of the regeneration proposals.

If you are interested in the Fruit Market, either as a location for your business, as a place to try out a new business idea or retail concept or to experiment with performance or installations (storage and passive uses will not be encouraged), please contact Liz King to register your interest and to obtain a place at the event. Email: liz.king@hullforward.co.uk Tel: 01482 387420.

Here at Hull Digital, we fully support this project. In many cities around the country, there are thriving, successful quarters where the new media and creative industries congregate. It provides a rich crossover of working opportunities, a vibrant atmosphere, as well as attracting businesses like coffee shops and restaurants / cafes.

Why do we need such a group?

The speed at which our industry moves is incredible and as developers it is almost impossible for us to keep on top of all aspects of our industry, we can only begin to keep up by working together. Sure we can read books, blog posts and watch screencasts, but there are only 24 hours in a day and we all have lives outside of work as well.

A group would be the perfect place for developers to get together and discuss all things development.  Whether this is Web, Desktop or Mobile based development we’ve got lots we can discuss with each other.

Who is the group for?

The group will be open to anyone wanting to learn and discuss development technologies and techniques. Whether you are a back-end or front-end developer, run a development shop, are a student, or simply a development enthusiast, this group will be for you.

Developers involved in the group should be open minded and not be closed to non-mainstream ideas. The group will not be dedicated to one language, but open to all, as every language can learn ideas and principles from others.

Possible Format of Development Group

Initial ideas have been for the group to meet every couple of months.  Clearly this can change dependent on demand.

We are currently thinking that the meetup should be kept in a similar format to the current Hull Digital Meetup, with a couple of speakers and then time to socialise and discuss the evenings talks.

Topics

Clearly the world of development is very wide ranging and as such it is hoped the range of topics will be quite large.

Some suggested early topics have been:

• Test Driven Development
• Object-relational Mapping
• Principles of SOLID
• MVC Frameworks
• JavaScript Frameworks
• Advanced CSS
• Windows Presentation Foundation
• Mobile Apps
• Cloud Computing
• Accessible AJAX (Hijax)
• Domain Driven Design

Your thoughts?

So we can get this group right for you, please let us know what you would like from such a group. Does the proposed format work for you? What kind of topics do you think should be covered?  Would you be prepared to do a talk?

The idea of TDD has been around for quite some time now, but it seems to be gathering favour with more and more developers now.

Brief Overview

The process of TDD is shown in the stages below

1. Write a test
2. Check if the test fails
3. Write the smallest amount of production code to make the test pass
4. Run the test (Return to step 3 if it fails)
5. Refactor the code (both tests and production code)

Theses steps are often referred to as Red (the test fails), Green (the test passes), Refactor.

TDD in Action

The easiest way to explain how TDD works is to show some examples. To do this we are going to look at creating a login page for a website, minus the front end (View). For these examples we are going to use the following development stack

• Castle MonoRail (a MVC Framework for .Net)
• NUnit (a testing framework for .Net)
• Rhino Mocks (a mocking framework for .Net)

Whilst these may not be your development stack, the principles discussed in this post will be roughly the same.

Starting from scratch

We are going to be starting completely from scratch with no pre-written code, so the first thing to do is create the LoginController class. Yes that’s right we are not going to start with the database first, in fact that will happen much further down the line.

public class LoginController : SmartDispatcherController
{
}

There is no need to worry about the SmartDispatcherController, this is a MonoRail class that implements smart ways to invoke actions. Basically it makes our life easier.

So we have the empty controller, we need to think about what we want it to do. This is where TDD comes in. The tests are going to help us create all of the code for the controller and it’s dependencies. So let’s create an empty test fixture for the controller.

[TestFixture]
public class LoginControllerFixture : BaseControllerTest
{
}

The TestFixture attribute comes from the NUnit framework. It basically means that when NUnit sees this class it knows it has tests to run.

The BaseControllerTest is a MonoRail testing base class which allows us to test controllers without the need for an ASP.Net Runtime

Creating the first test

Now we have the test fixture ready we can put our first test together.

As we are testing whether users can login in or not, lets start with a test called User_Can_Successfully_Login.

[TestFixture]
public class LoginControllerFixture : BaseControllerTest
{
	[Test]
	public void User_Can_Successfully_Login()
	{
		var controller = new LoginController();
		PrepareController(controller);
	}
}

So far we haven’t done anything much other than create a reference to the LoginController class we created earlier. The PrepareController method comes from the MonoRail BaseControllerTest and it prepares the controller giving it mock implementations of the services it requires to function normally.

Ok, so we need to actually get this test doing something now. The important thing to remember here is that we are only testing the controller and nothing else. Following the Single Responsibility Principle, the controller will handle the user input. The handling of the authentication will be done by an AuthenticationService class.

[TestFixture]
public class LoginControllerFixture : BaseControllerTest
{
	[Test]
	public void User_Can_Successfully_Login()
	{
		var mockery = new MockRepository();
		var authenticationService = mockery.DynamicMock();
		var controller = new LoginController(authenticationService);

		var authenticatedUser = new AuthenticatedUserDTO { Id = Guid.NewGuid(), Type = "Administrator" };
		var authenticationRequest = new AuthenticationRequestDTO {Username = "username", Password = "password"};

		PrepareController(controller);

		With.Mocks(mockery)
			.Expecting(() => Expect.Call(authenticationService.AuthenticationUser(authenticationRequest)).Return(authenticatedUser))
			.Verify(() => controller.Login(authenticationRequest));

		Assert.AreEqual("/admin/index", Response.RedirectedTo);
	}
}

As we currently don’t have an AuthenticationService class we have added the mocking framework to “mock” the service functionality. The functionality of the service will be tested by the test fixture for that service not by the controller test fixture.

A mocking framework allows us to simulate the output of objects, so we don’t actually have to worry about the implementation of those objects. Remember we are only testing one unit at a time.

Let’s quickly review the whole test method.

1. Setup the Mock framework
2. Create a mocked instance of the IAuthenticationService interface
3. Create and prepare a reference to the controller we are testing and passed in any of it’s mocked dependencies
4. Create a AuthenticatedUserDTO object as this is needed by the IAuthenticationService
5. Create a AuthenticationRequestDTO object that will be passed into the Login action
6. Set the expectations for the controllers Login method – Expectations are the methods expected to be called by the Login method
7. Run the Login method via the call to Verify
8. Make sure the method has redirected to the index action of the admin controller by using assertions.

The test is forcing us to generate code

We have our first test method, however this won’t compile as we have no IAuthenticationService interface, no AuthenticatedUserDTO, no AuthenticationRequestDTO, no Login method on the LoginController and we are missing the AuthenticationService dependency in the controller, so let’s get all this added in.

public class LoginController : SmartDispatcherController
{
	private readonly IAuthenticationService authenticationService;

	public LoginController(IAuthenticationService authenticationService)
	{
		this.authenticationService = authenticationService;
	}

	public void Login([DataBind("login")]AuthenticationRequestDTO authenticationRequest)
	{
	}
}

We’ve got the authenticationService dependency and the login action in now.

public interface IAuthenticationService
{
	AuthenticatedUserDTO AuthenticateUser(AuthenticationRequestDTO authenticationRequest);
}

Here is our abstraction of the AuthenticationService. Using the idea of dependency injection we can substitute in any service that inherits from this interface.

As the test has already specified it expects a call to the AuthenticationUser method of the IAuthenticationService interface we can also create the signature of that method.

public class AuthenticatedUserDTO
{
	public Guid Id { get; set; }
	public string Type { get; set; }
}

public class AuthenticationRequestDTO
{
	public string Username { get; set; }
	public string Password { get; set; }
}

The last two objects are our DTOs (Data Transfer Objects). These are simple objects that contain no business logic, they are used to transfer data between other objects.

Run the test

The code should now compile happily, so we can move on to the next stage of TDD and that is running the test. Clearly the test will fail as we have no code in the LoginController to make it pass. Now it may seem pointless running a test when there is no code to make it pass, however if you were writing a test for an edge case you would want to make sure the test wasn’t passing first, otherwise the test may well be wrong.

Make the test pass

When using TDD, the developer should remember they need to write the smallest amount of code possible to make the test pass.

public class LoginController : SmartDispatcherController
{
	private readonly IAuthenticationService authenticationService;

	public LoginController(IAuthenticationService authenticationService)
	{
		this.authenticationService = authenticationService;
	}

	public void Login([DataBind("login")]AuthenticationRequestDTO authenticationRequest)
	{
		var authenticatedUser = authenticationService.AuthenticationUser(authenticationRequest);

		Redirect("Admin", "Index");
	}
}

If we now run the test it will pass. The final stage of the TDD process is to refactor the code. At this stage there is no code that can be refactored, so we’ll move on.

Test the negative and positive

We are not finished here as we need to test that the controller can cope when a user enters incorrect details. Let’s look at creating a User_Can_Fail_Login test.

[Test]
public void User_Can_Fail_Login()
{
	var mockery = new MockRepository();
	var authenticationService = mockery.DynamicMock();
	var controller = new LoginController(authenticationService);

	var authenticationRequest = new AuthenticationRequestDTO {Username = "username", Password = "password"};

	PrepareController(controller);

	With.Mocks(mockery)
		.Expecting(() => Expect.Call(authenticationService.AuthenticationUser(authenticationRequest)).Return(new AuthenticatedUserDTO()))
		.Verify(() => controller.Login(authenticationRequest));

	Assert.AreEqual(1, controller.Flash.Count);
	Assert.AreEqual("Username or Password not recognised", controller.Flash["error"]);
}

The difference here from the successful login test is that the mocked authenticationService returns an empty instance of the AuthenticatedUserDTO object. We also have changed the assertions to make sure that an error has been placed into the MonoRail Flash parameter. Now if we run the overall test fixture we will have one passing and one failing test, so we need to revisit the LoginController class and make the second test pass.

public class LoginController : SmartDispatcherController
{
	private readonly IAuthenticationService authenticationService;

	public LoginController(IAuthenticationService authenticationService)
	{
		this.authenticationService = authenticationService;
	}

	public void Login([DataBind("login")]AuthenticationRequestDTO authenticationRequest)
	{
		var authenticatedUser = authenticationService.AuthenticationUser(authenticationRequest);

		if (authenticatedUser.Id != Guid.Empty)
			Redirect("Admin", "Index");
		else
		{
			Flash["error"] = "Username or Password not recognised";
			RedirectToReferrer();
		}
	}
}

If we run the tests now, we should have two passing tests.

Refactor all our code

Again as part of the TDD process we need to look at refactoring our code, this includes the test fixture code as well. From looking at the controller code there isn’t anything that can be refactored, however the test fixture is suffering from DRYness (Don’t Repeat Yourself).

Let’s look at the whole test fixture class again.

[TestFixture]
public class LoginControllerFixture : BaseControllerTest
{
	[Test]
	public void User_Can_Successfully_Login()
	{
		var mockery = new MockRepository();
		var authenticationService = mockery.DynamicMock();
		var controller = new LoginController(authenticationService);

		var authenticatedUser = new AuthenticatedUserDTO { Id = Guid.NewGuid(), Type = "Administrator" };
		var authenticationRequest = new AuthenticationRequestDTO {Username = "username", Password = "password"};

		PrepareController(controller);

		With.Mocks(mockery)
			.Expecting(() => Expect.Call(authenticationService.AuthenticationUser(authenticationRequest)).Return(authenticatedUser))
			.Verify(() => controller.Login(authenticationRequest));

		Assert.AreEqual("/admin/index", Response.RedirectedTo);
	}

	[Test]
	public void User_Can_Fail_Login()
	{
		var mockery = new MockRepository();
		var authenticationService = mockery.DynamicMock();
		var controller = new LoginController(authenticationService);

		var authenticationRequest = new AuthenticationRequestDTO {Username = "username", Password = "password"};

		PrepareController(controller);

		With.Mocks(mockery)
			.Expecting(() => Expect.Call(authenticationService.AuthenticationUser(authenticationRequest)).Return(new AuthenticatedUserDTO()))
			.Verify(() => controller.Login(authenticationRequest));

		Assert.AreEqual(1, controller.Flash.Count);
		Assert.AreEqual("Username or Password not recognised", controller.Flash["error"]);
	}
}

You should be able to see the duplication quite clearly. So we need to clean this up.

[TestFixture]
public class LoginControllerFixture : BaseControllerTest
{
	private MockRepository mockery;
	private IAuthenticationService authenticationService;
	private LoginController controller;
	private AuthenticationRequestDTO authenticationRequest;

	[SetUp]
	public void SetUp()
	{
		mockery = new MockRepository();
		authenticationService = mockery.DynamicMock();
		controller = new LoginController(authenticationService);

		authenticationRequest = new AuthenticationRequestDTO {Username = "username", Password = "password"};

		PrepareController(controller);
	}

	[Test]
	public void User_Can_Successfully_Login()
	{
		mockLoginAction(new AuthenticatedUserDTO { Id = Guid.NewGuid(), Type = "Administrator" });

		Assert.AreEqual("/admin/index", Response.RedirectedTo);
	}

	[Test]
	public void User_Can_Fail_Login()
	{
		mockLoginAction(new AuthenticatedUserDTO());

		Assert.AreEqual(1, controller.Flash.Count);
		Assert.AreEqual("Username or Password not recognised", controller.Flash["error"]);
	}

	private void mockLoginAction(AuthenticatedUserDTO authenticatedUser)
	{
		With.Mocks(mockery)
			.Expecting(() => Expect.Call(authenticationService.AuthenticationUser(authenticationRequest)).Return(authenticatedUser))
			.Verify(() => controller.Login(authenticationRequest));
	}
}

You can see here we’ve cleaned up the test fixture quite a bit.

The first thing we’ve used here is the built in testing framework SetUp method. This method is run before every test method is run, so we can use it to prepare everything we are going to need for each test.

The second thing we have done is to move the mocking code into a private method that both test methods can use at once.

Once we have finished refactoring any code we need to run the tests again to make sure we haven’t broken anything.

Conclusion

So from starting with an empty controller class we have used two tests to drive out our code and we now have a fully tested controller, with an abstract dependency and two DTOs. Clearly we need to add in some method of keeping the user logged in, using a cookie or session variable, but this isn’t going to be done now as this post would be much longer!

Yes we have written more code that we would have done by just simply writing the controller without tests, however these tests are some major benefits for the future.

1. We’ll know if we brake anything in the future as we can keep running the tests at any stage
2. If a new developer starts to work on the code, they will be able to read the tests and understand what the controller should be doing. That’s right, we have written some documentation for them!
3. To run these tests we’ve not had to ramp up any database or test data
4. We’ve not had to set up any web server to test the code
5. Developers can have rapid feedback on any development work they are doing, by running the tests as often as they want
6. The controller is loosely coupled with it’s dependency (AuthenticationService), so we can change the service at any stage, as long as it inherits from the abstract version of the service.

Now we have our controller we can then use the same TDD ideas to drive out the code for the abstract service object we have. This will, more than likely, lead to the driving out of other abstract objects.

Once we have all these objects written we can then use the idea of integration tests to make sure all the objects work together without any mocking.

Dependencies take many forms. You’re dependent on your car (shame on you!) to get to work. Your pet depends on you to feed it. You depend on your employer paying you for your work, and your employer depends on you to actually produce the work.

You may not think much about these in daily life, but every thing that you rely on reduces your control over your situation. For those commuters among us, if you take a train to get to work you’re probably already aware that you have no control over whether it arrives on time; without that control you’re indirectly out-of-control of what time you arrive to work.

Dependencies are unavoidable. To stop depending on the trains you could take your car, but that’s just shifting the buck; you work from home, but then you’re reliant on your broadband and electricity being available. They’re unavoidable, it’s how you manage them that’s important.

Sometimes you need to think at a higher-level than where your dependency is affecting you. You may not be able to control the trains, but you can control your need for the trains. Substitution is best method for maintaining control. Being able to substitute your mode of transportation for another without consequence would seriously improve your situation.

Dependencies in your code

Let’s play spot the dependencies.

class ChatSession
  attr_accessor :session_id

  def initialize
    @server = ChatServer.new
  end

  def get_latest_messages
    messages = @server.get_messages session_id, :since => @last_request_time
    @last_request_time = DateTime.now
   messages
  end
end

There’s a couple in there, can you spot them? The main one is that we’re depending on a ChatServer instance. We’re also depending on DateTime, but we’ll leave that one alone for now. By instantiating the ChatServer in the constructor, we’ve lost control of how our class works.

There’s a core tenet of Object Oriented Programming called the Open/Closed Principal. This states that modules should be open for extension, but closed for modification. Put simply, this means you should be able to modify the behavior of your classes without changing their code.

If we decided that our chat client was going to be distributed rather than centralized, then we’d have to modify this class. We’d have to modify all classes that instantiate a ChatServer. This design is brittle, because a single design change can ripple out across your entire code-base requiring many small changes.

How exactly do you close a class for modification, but still allow extension? I’ll show you.

def initialize(server_class)
  @server = server_class.new
end

We’re now passing in the class of server into our constructor, which is a technique called Constructor Injection; we’d create it like so: ChatSession.new(ChatServer). ChatSession is now independent of server implementation details and can operate with any server; we can now potentially swap out to use a DistributedChatServer or more practically, substitute the server in a test to verify our class more easily.

Those of you who’ve used dependency injection in a static language (such as C# or Java) may be wondering why we’re passing the Type in, instead of an actual instance. We’re doing this because it’s more flexible when combined with the dynamic nature of Ruby. For instance you could throw in a respond_to? call to check if the type is capable of doing something special, and if not fall back on the regular constructor; we couldn’t do this if we’d only received an instance.

While overloading the constructor like this can be very useful, it does lead us into producing more code when we instantiate classes. The more arguments you add, the less it scales. Statically typed languages favor using a Dependency Injection framework to alleviate this problem (I’ll cover them soon), but as we’re currently talking in Ruby we’re going to keep things simple.

def initialize(server_class=ChatServer)
  @server = server_class.new
end

We’ve altered our constructor is now using the default parameter support from Ruby to supply the most common scenario to our instance. Most of the time we’re going to use the standardChatServer so it makes sense to default to that and only supply a different one for those special cases. This gives us back our ability to use a plain new. We now satisfy the Open/Closed Principal, because we can now modify the class’s behavior by supplying a different server instance without having to modify any of it’s code.

Q: We’d still need to modify every class that creates a default ChatServer if we wanted to swap it out entirely, wouldn’t we?

A: Correct, this design is mainly intended for allowing easier occasional substitution (present in unit tests mainly). If you wanted full independence from any references to concrete implementations in your dependents, then you could use a variety of other injection patterns, or simply not supply the default to achieve this. Some examples are using a factory method with subclassing, a property to set on construction, or a type supplied directly to the method that uses it. Ruby is dynamic, do whatever works for you.

It’s fairly accepted in Ruby circles that there isn’t the need for frameworks to do Dependency Injection, as the language is flexible enough to let you do it easily enough yourself; Jamis Buck covers this position nicely in his LEGOs, Play-Doh, and Programming blog post; however, not all languages have this ability, and it’s these that generally utilise frameworks to help with dependency injection.

In static language Dependency Injection frameworks are what tie everything together. They allow you to specify your dependencies via constructors and have them auto-magically injected at run-time. If you have your container configured to pick up all your available classes on startup, then extending a class is as simple as changing the constructor, everything else happens automatically.

Our Ruby example would be configured using StructureMap (a .Net dependency injection framework) like so:

public class ServerRegistry : Registry
{
  public ServerRegistry()
  {
    Scan(x =>
    {
      x.TheCallingAssembly();
      x.WithDefaultConventions();
    });

    ForRequestedType<IChatServer>()
      .TheDefaultIsConcreteType<CenteralizedChatServer>();
  }
}

The Registry is StructureMap’s convention for configuring the container, and it’s Scan method auto-discovers all injectable types, and the ForRequestedType method-chain configures our application to use the CenteralizedChatServer as the default instance for any consumers of an IChatServer. It’s that last part that we’d be able to switch on an external variable to use a DistributedChatServer if needed.

There are dependency injection frameworks for almost every language, even for those that don’t really need them. .Net has StructureMap, Windsor, and Ninject (as well as several more); Java has Spring, Google Guice, and others; php has Symfony and Crafty; and even though Ruby and Python don’t really need them, they have Needle and Snake Guice respectively.

I know what you’re thinking, “sure this sounds nice, but isn’t it just more work? How does it actually make my life easier?”.

The fewer dependencies that your classes have, the fewer reasons they have to change; the fewer reasons they have to change, the less work you have to do; the less work you have to do, the more time you can spend doing more fun things (whether they’re more interesting programming tasks, or life outside the screen). That would be nice, wouldn’t it?

Quick Thanks

I’d just like to give James Gregory a huge thanks for writing this post.  James is the project lead for Fluent NHibernate and is the founder of Proof of Concept Ltd.

Maintainability is probably the single most important thing in software development, so why is it that so often code becomes difficult to maintain, and the older the code gets the more difficult it becomes to maintain?  This post will give a very brief overview of some common techniques that should be remembered to help improve maintainability.

Meaningful and Consistent Naming Conventions

The first thing to remember is that someone else may be reading your code, and thus it is important that they can understand what a class, method or variable is doing based on the name given to it.  This is particular important with larger projects where developers need to be able to find functionality quickly, otherwise maintenance costs will increase.

There are quite a number of standard naming conventions around, so once you have picked one, stick to it.  If possible use tools that help you stick to those conventions.

Remove “Code Smells”

One of the major problems with code is that is can be full of “code smells” and over time the code can rot more and more.  Some of the common code smells are

• Duplicate code
• Large methods
• Large classes
• Excessive commenting
• Conditional complexity
• Dead code

For a fuller list with explanations read the Code Smells article on Coding Horror.

Separation of Concerns

SoC is about breaking the software into distinct pieces of functionality.  On a simple level this may mean separating the UI layer, the business logic layer and the database access layer.  If functionality is not separated out then it becomes difficult for developers to pin point the area they need to update during maintenance.  It is also likely that this mixed functionality will lead to making changes more complicated, due to code being reliant on other areas of code.

A major benefit of SoC is that it generally leads to much smaller methods and classes, thus improving the readability of code.  It also improves the ability to test each area of functionality.

Loose Coupling

Coupling is the measure by which each object relies on other objects.  If objects are loosely coupled a change to one object will have a minimal effect on all other objects.  One way of loosely coupling objects is to follow the Dependency Injection pattern.

Testability

Testing is an essential part of software maintenance.  If code is not covered by tests then it becomes difficult and time consuming for developers to check if updates have caused knock on effects in other areas of the software. Ideally a developer should be looking to practice Continuous Integration, and a build server should run the tests whenever new code is checked in.  This way the team members will know quickly if the build has broken and problems can be resolved quickly.

Final Thoughts

There are many more areas to creating maintainable code that haven’t been mentioned above, the purpose of this post is to act as a starting point.

Please lets us know how you ensure your code is easy to maintain.