Even if you are part of a small team, having the overview of what is going on, and especially in the code base, requires quite some effort from all your team members. 

And the problem with this lack of overview, is that often it leads to developers solving the same problem, or perhaps similar problems, several times and in different ways. And not only that, but developers also make errors due to lack of knowledge about the domain and the rest of the code base. 

Now, we all probably understand that this will eventually lead to a maintenance hell somewhere down the road. And we do not want to go there, do we?

Practices like Pair Programming and Code Reviews are of course great ways of sharing knowledge, but sharing is then limited between two persons and not the whole team.

I’m going to tell you about a little practice I’ve been doing for some years now. Of course, it’s no silver bullit, but I can most certainly promise that it will help you and your team with delivering better, more maintainable software. 

It goes like this: When you get in the office in the morning, you grab a cup of coffee as usual. But, instead of drinking your coffee while reading yesterdays news, you drink your coffee while reading yesterdays commits done by you and your team. You pull up the history, read the commit messages, and the changes that are made.

When you find something good, you will learn something. When you find something wrong, you tell the person who did it, and work together with him to fix it. 

It’s as simple as that, and it only takes you a few minutes every day. 

You might experience that it can be a bit hard to begin with, especially if you have a lot of crappy commits. But guess what? You’ll get better at committing or checking in as well. Your commits will get more focused, and your messages will get more descriptive. Your source control is no longer just a place where you keep a backup of your files.

One other thing. I mentioned Code Reviews. They are hard. Not doing them necessarily, but getting people to do them. At least from my experience, things go well in the beginning, but then people tend to not do it so much more. I hope I don’t have to convince you that doing code reviews are a good thing. Right? By following the little advice I’ve just given you, you also get code reviews for free. Let’s call it a check in review. You’ll be amazed by how many bugs, wrongly implemented business rules, and duplicated code you’ll find.

So, start learning from your history, stop repeating it, and encourage your team mates to do the same!

I just released version 0.2.0 of my validation plugin for Backbone.js. The plugin lets you declare validation rules on your Backbone model, ensuring that input from the user is valid. It currently ships with 18 built-in validators such as required, min, max, range, length, minLength, maxLength, regex-validator etc. In addition to the built-in validators, it is very easy to extend with your custom validators.

Lets start with an example of how to declare validation rules on your model:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
var SomeModel = Backbone.Model.extend({
  validation: {
    name: {
      required: true,
      msg: 'Name is required'
    },
    age: {
      range: [1, 80]
    },
    email: {
      pattern: 'email'
    },
    someAttribute: function(value) {
      if(value !== 'somevalue') {
        return 'Error';
      }
    }
  }
});

To configure your validation rules, simply add a validation object with a property for each attribute you want to validate on your model. The validation rules can either be an object with one of the built-in validators or a combination of two or more of them, or a function where you implement your own custom validation logic. If you want to provide a custom error message when using one of the built-in validators, simply define the msg property with your message.

To add your own validators, extend the Backbone.Validation.validators object as shown in the example below where we use underscore.js extend method. You can also redefine one or more of the built-in validators if it doesn’t fit your needs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
_.extend(Backbone.Validation.validators, {
  myValidator: function(value, attr, customValue, model) {
    if(value !== customValue) {
      return 'error';
    }
  },
  required: function(value, attr, customValue, model) {
    if(!value) {
      return 'My version of the required validator';
    }
  },
});

var Model = Backbone.Model.extend({
  validation: {
    age: {
      myValidator: 1 // uses your custom validator
    }
  }
});

A couple conventions

After performing validation, an isValid attribute is set on the model that is (obviously) true when all the attributes on the model is valid, otherwise it is false.

The Backbone.Validation.callbacks contains two methods: valid and invalid. These are called (in addition to the error event raised by Backbone) after validation of an attribute is performed.

The default implementation of invalid tries to look up an element within the view with an id equal to the name of the attribute that is validated. If it finds one, an invalid class is added to the element as well as a data-error attribute with the error message. The valid method removes these if they exists. You can also configure it to use a class selector instead of id selector.

As with the validators, you can redefined the behavior of these callbacks by overriding the implementation.

1
2
3
4
5
6
7
8
_.extend(Backbone.Validation.callbacks, {
  valid: function(view, attr, selector) {
    // do something
  },
  invalid: function(view, attr, error, selector) {
    // do something
  }
});

Validation binding

For all of this to work, you need to hook up the validation. The validation binding code is executed with a call to Backbone.Validation.bind(view). The validate method on the view’s model is then overridden to perform the validation.

There are several places that it can be called from, depending on your circumstances.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Binding when rendering
var SomeView = Backbone.View.extend({
  render: function(){
    Backbone.Validation.bind(this);
  }
});

// Binding when initializing
var SomeView = Backbone.View.extend({
  initialize: function(){
    Backbone.Validation.bind(this);
  }
});

// Binding from outside a view
var SomeView = Backbone.View.extend({
});
var someView = new SomeView();
Backbone.Validation.bind(someView);

Summary

With this declarative way of defining validation, combined with the conventional updating of your user interface, it makes for an easy way to handle client validation. At least I think so.

But remember: you add client validation to be nice to your users, but you also need to add server validation to be nice to yourself and your company.

The source code for this project is licensed under the MIT License and is available on GitHub.

• Added extension methods to the IAssemblyScanner for easier discovery and configuration of conventions
  • scan.WithFirstInterfaceConvention()
  • scan.WithNamingConvention()
  • scan.WithAddAllConvention()
  • scan.WithSetAllPropertiesConvention()
• Added non-generic overload to the AddAllConvention that allows you to register open generic interfaces
  • scan.WithAddAllConvention().TypesImplementing(typeof(IHandler<>))
• Added option on the IAssemblyScanner interface to scan for internal types in an assembly
  • scan.InternalTypes()
• Strong named the assembly
• Switched to Semantic Versioning. In short this means that when
  • the major number is changed: There will be breaking changes
  • the minor number is changed: New features are added, but it is still backwards compatible
  • the patch number is changed: Backwards compatible bugs fixes only

As usual you can install it via NuGet using the package manager in Visual Studio:

1
PM> Install-Package UnityConfiguration 

or, if you like, you can grab the code at GitHub.

Hope you enjoy it!

So what’s new in v1.3?

• Documented public facing methods
• Included the xml documentation in the NuGet package
• Debugging symbols are available on SymbolSource.org
• Several more overloads for adding assemblies to the scanner
• One more overload for adding a registry that takes an instance of a UnityRegistry
• New convention that scans for registries
• New convention that uses an overridable naming convention for registering a type mapping
• Added Transient, PerThread, PerResolve, ExternallyControlled and HierarchicalControlled lifetime scope configuration
• MakeSingleton()</code> and MakeSingleton(string)</code> is marked as obsolete. Use Configure().AsSingleton()</code> or Configure().WithName(name).AsSingleton()</code> instead
• ConfigureCtorArgsFor(params object[] args)</code> is marked as obsolete. Use Configure().WithConstructorArguments(params object[])</code> instead

Install using the package manager console in Visual Studio:

1
PM> Install-Package UnityConfiguration

Hope you enjoy it!

Now, some say that auto mocking is a bad practice since it can hide certain design flaws in your system, like classes with to many dependencies etc. I say, that if you have these issues, it is probably not the auto mocking that is causing them. Auto mocking can increase your productivity, so I have no issues with using it. In fact, I encourage you to do so.

Using the container

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Creating a new instance of the auto mock container
var container = new UnityAutoMoqContainer();

// Resolving a concrete class automatically creates
// mocks for the class dependencies and injects them
// before returning an instance of the class
Service service = container.Resolve<Service>();

// Resolving an interface, returns a mocked
// instance of that interface
IService mocked = container.Resolve<IService>();

// GetMock returns the mock on which you can do setup etc.
Mock<IService> mock = container.GetMock<IService>();

// Sometimes you need to cast your interface to some other type
// This is how that is done
container.ConfigureMock<IService>().As<IDisposable>();
Mock<IDisposable> disposable = container.GetMock<IService>().As<IDisposable>();

Download

The framework is available as a NuGet package, and can be installed either using the package manager console in Visual Studio like this:

1
PM> Install-Package UnityAutoMoq

Or by right clicking on references in your project and select the Add Library Package Reference option

The source code for this project is licensed under the MIT License and is available on my GitHub profile.

Below you can see a small example of configuring a container using registries, and I should probably apologize for the poor (or rather lack of) documentation at this time.

You get access to the configuration api by using the extension method Configure on the IUnityContainer interface.

1
2
3
4
5
6
var container = new UnityContainer();
container.Configure(x =>
{
  x.AddRegistry<FooRegistry>();
  x.AddRegistry<BarRegistry>();
});

Configuration is done in one or several registries that inherit the UnityRegistry base class.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
public class FooRegistry : UnityRegistry
{
  public FooRegistry()
  {
    // Scan one or several assemblies and auto register types based on a
    // convention. You can also include or exclude certain types and/or
    // namespaces using a filter.
    Scan(scan =>
    {
      scan.AssemblyContaining<FooRegistry>();
      scan.With<FirstInterfaceConvention>();
      scan.With<AddAllConvention>().TypesImplementing<IHaveManyImplementations>();
      scan.With<SetAllPropertiesConvention>().OfType<ILogger>();
      scan.ExcludeType<FooService>();
    });

    // Manually register a service
    Register<IFooService, FooService>().WithName("Foo").AsSingleton();

    // Make services a singleton
    MakeSingleton<ISingletonService>();

    // You can automatically configure the container to call
    // a method on any service when they are created
    AfterBuildingUp<IStartable>().Call((c, s) => s.Start();

    // You can automatically configure the container to
    // decorate services when they are created
    AfterBuildingUp<IFooService>().DecorateWith((c, t) => new FooDecorator(t));

    // If you want to inject values or objects that are not registered in
    // the container, you can do so by adding them using this statement.
    // For instances you want the container to create, just specify the type.
    ConfigureCtorArgsFor<ServiceWithCtorArgs>("some string", typeof (IFooService));

    // Unity follows the greedy constructor pattern when creating instances.
    // If you want to use a different constructor, you specify it by listing
    // the types of the arguments in the constructor you want it to use.
    SelectConstructor<ServiceWithCtorArgs>(typeof (IFooService));
  }
}

At the moment, built in conventions includes AddAllConvention, FirstInterfaceConvention and SetAllPropertiesConvention. If these doesn’t suit you, creating custom conventions is as easy as creating a class that implements the IAssemblyScanner interface.

1
2
3
4
5
6
7
8
public class CustomConvention : IAssemblyScannerConvention
{
  void IAssemblyScannerConvention.Process(Type type, IUnityRegistry registry)
  {
    if (type == typeof(FooService))
      registry.Register<IFooService, FooService>().WithName("Custom");
  }
}

Download

The framework is available as a NuGet package, and can be installed either using the package manager console in Visual Studio like this:

1
	PM> Install-Package UnityConfiguration

Or by right clicking on references in your project and select the Add Library Package Reference option

The source code for this project is licensed under the MIT License and is available on my GitHub profile.

• 

  01. Arcade Fire - The Suburbs

• 

  02. The National - High Violet

• 

  03. Sufjan Stevens - The Age of Adz

• 

  04. Deerhunter - Halcyon Digest

• 

  05. Motorpsycho - Heavy Metal Fruit

• 

  06. Beach House - Teen Dream

• 

  07. LCD Soundsystem - This Is Happening

• 

  08. Tame Impala - Innerspeaker

• 

  09. Shearwater - The Golden Archipelago

• 

  10. Menomena - Mines

• 

  11. The Black Angels - Phosphene Dream

• 

  12. The Besnard Lakes - The Besnard Lakes Are The Roaring Night

• 

  13. The Walkmen - Lisbon

• 

  14. I Am Kloot - Sky at Night

• 

  15. Titus Andronicus - The Monitor

• 

  16. Broken Social Scene - Forgiveness Rock Record

• 

  17. Perfume Genius - Learning

• 

  18. Belle & Sebastian - Write about Love

• 

  19. The Black Keys - Brothers

• 

  20. Black Mountain - Wilderness Heart

• 

  21. The Tallest Man on Earth - The Wild Hunt

• 

  22. Suckers - Wild Smile

• 

  23. The Morning Benders - Big Echo

• 

  24. MGMT - Congratulations

• 

  25. Midlake - The Courage Of Others

• 

  26. Wolf Parade - Expo 86

• 

  27. Broken Bells - Broken Bells

• 

  28. Ariel Pink's Haunted Graffiti - Before Today

• 

  29. Teenage Fanclub - Shadows

• 

  30. of Montreal - False Priest

It’s been a good year.

-O, [--skip-activerecord]  # Skip Active Record files
-J, [--skip-prototype]     # Skip Prototype files
-T, [--skip-testunit]      # Skip Test::Unit files

You can get a complete list of all the available options by running the command:

1
	$ rails new --help

Creating the app

1
2
3
$ sudo gem install rails
$ rails new YourApp -OJT
$ cd YourApp

The gem command will install the latest version of Rails 3. The rails command creates a new app named ‘YourApp’ without Active Record (-O), Test::Unit (-T), and the Prototype javascript files (-J).

Configuring the app and the required gems

To get things working you first have to install all the required gems. Since Rails 3 introduces Bundler, the gem management is as simple as it can get.

Open your Gemfile at the root of you application and specify the gems:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
source "http://rubygems.org"

gem "rails", "3.0.0"
gem "bson_ext"
gem "mongo_mapper"

group :test, :spec, :cucumber do
  gem "rspec"
  gem "rspec-rails", ">= 2.0.0.beta"
  gem "capybara"
  gem "cucumber"
  gem "database_cleaner"
  gem "cucumber-rails"
  gem "spork"
  gem "launchy"
end

Then, install all of them by simply running:

1
$ bundle install

Finally, you have to tell the generators that you are not using the default stuff. You do that by editing the config/application.rb and add these lines:

1
2
3
4
5
config.generators do |g|
	g.orm             :mongo_mapper
	g.template_engine :erb
	g.test_framework  :rspec
end

Setting up the connection to MongoDB

Create a new file, config/initializers/mongo.rb with the following content:

1
2
3
logger = Logger.new("log/mongodb-#{Rails.env}.log")
MongoMapper.connection = Mongo::Connection.new('127.0.0.1', 27017, :logger => logger)
MongoMapper.database = "YourApp-#{Rails.env}"

If you use different databases in the different environments (e.g. dev, production), go ahead and put some if-else logic in here.

Generating the Cucumber and RSpec stuff

1
2
$ rails g rspec:install    
$ rails g cucumber:install --capybara --rspec --skip-database

That’s it. You’ll now have a folder features for your Cucumber features and a folder spec for your RSpec specs.

Adding jQuery

1
2
$ curl http://code.jquery.com/jquery-1.4.2.min.js > public/javascripts/jquery-1.4.2.min.js
$ curl http://github.com/rails/jquery-ujs/raw/master/src/rails.js > public/javascripts/rails.js

The first line downloads jQuery 1.4.2 and saves it to your public/javascripts/ folder. The second line downloads rails.js which is a wrapper around jQuery for Rails.

Finally, specify that the javascripts should be loaded as part of the default scripts by opening the file config/application.rb and change

1
config.action_view.javascript_expansions[:defaults] = %w()

to

1
config.action_view.javascript_expansions[:defaults] = %w(jquery rails application)

And, you’re done!

From the readme:

The shotgun command starts one of Rack’s supported servers (e.g., mongrel, thin, webrick) and listens for requests but does not load any part of the actual application. Each time a request is received, it forks, loads the application in the child process, processes the request, and exits the child process. The result is clean, application-wide reloading of all source files and templates on each request.

As you can see, there in no longer a need to restart your server when code has changed, Shotgun does it for you. Nice.

To get going you need to install the gem

1
$ sudo gem install shotgun

To start the web server, simply type

1
$ shotgun

if the current directory contains the config.ru file, or specify the config file like this

1
$ shotgun config.ru

The output should be something like

1
== Shotgun/Mongrel on http://127.0.0.1:9393/

telling you which server got started and on what port it is listening.

There are some more options available, which you can find by looking at the help

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ shotgun --help

Ruby options:
  -e, --eval LINE          evaluate a LINE of code
  -d, --debug              set debugging flags (set $DEBUG to true)
  -w, --warn               turn warnings on for your script
  -I, --include PATH       specify $LOAD_PATH (may be used more than once)
  -r, --require LIBRARY    require the library, before executing your script

Rack options:
  -s, --server SERVER      server (webrick, mongrel, thin, etc.)
  -o, --host HOST          listen on HOST (default: 127.0.0.1)
  -p, --port PORT          use PORT (default: 9393)
  -E, --env ENVIRONMENT    use ENVIRONMENT for defaults (default: development)

Shotgun options:
  -O, --browse             open browser immediately after starting
  -u, --url URL            specify url path (default: /)
  -P, --public PATH        serve static files under PATH
  -h, --help               show this message
      --version            show version

This walkthrough assumes that you have installed Ruby and Git and is somewhat familiar with using Git. Oh, and I am using a Mac, but I think it should work just as fine on Windows.

toto

1
$ sudo gem install toto

That’s it. You have now installed the blog engine, but before you can get started writing your articles you need a toto template.

1
2
$ git clone git://github.com/cloudhead/dorothy.git myblog
$ cd myblog

Dorothy is toto’s default template. It’s very minimalistic, but fully functional. If you want to customize it, all the files you need to change is located in the templates and public folders. It also comes with a Rack configuration file, config.ru, where you can configure your toto instance.

Writing in Markdown

toto uses no database or anything except .txt files for storing articles with metadata. The articles are written in Markdown and the metadata is stored in yaml at the very beginning of the file. Markdown is a plain text formatting syntax that gets converted to html. Its goal is to make it as readable as possible and I think they’ve succeeded. All you need is a simple text editor to get going.

To create a new article I recommend using the rake task for it.

1
2
$ rake new
Title:

You enter the title, hit enter, and the .txt file is created with necessary metadata and saved to the articles folder.

Open the file and start writing your article. When you are done writing, you need to commit the article to the git repository.

1
2
$ git add -A
$ git commit -m"Added new article"

Hosting it

The best (in my opinion) hosting option for Ruby is Heroku. It’s very easy to set up and it uses a pure git workflow for publishing your blog or site. For a small blog like mine, it is also completely free. No cost what so ever.

To publish your blog go to Heroku and sign up for an account. Then install Heroku on your machine.

1
$ sudo gem install heroku

After that is done, you need to make your blog a Heroku application.

1
2
3
$ heroku create myblog
Created http://myblog.heroku.com
git@heroku.com:myblog.git

Finally, you publish it. There are two ways of doing so. You can either use the rake task that comes with Dorothy or you can use the git push command. Essentially, they both do the same thing.

1
$ rake publish

or

1
2
3
4
$ git push heroku master
-----> Heroku receiving push
-----> Rack app detected
-----> Launching......... done

Your blog is now online! If you want to use your own domain it is also possible and very easy to set up with Heroku.

Disqus it

As part of the minimalistic approach of toto, it does not come with any custom built commentary module. For comments it uses the Disqus service. If you would like to enable comments, you go to http://disqus.com/, register for an account, and then you open the toto configuration file, config.ru, and changes

1
#set :disqus, false          # disqus id, or false

to

1
set :disqus, "YourDisqusId"  # disqus id, or false

People can now comment on your articles.

Running it locally

Sometimes it can be very useful to run the blog on local machine. Especially when tweaking layout and css there can be a lot of changes. I choose to run it on the thin web server.

1
$ sudo gem install thin

To start the web server type:

1
$ thin start -R config.ru

When I started it the first time I got an error

1
/Library/Ruby/Gems/1.8/gems/rack-1.2.1/lib/rack/utils.rb:138:in `union': can't convert Array into String (TypeError)

After some Googling I found that the error was most likely caused by Rack 1.2.1. When downgrading to Rack 1.1.0 it worked, although I don’t know why (yet).

When thin is running, go to http://localhost:3000 and browse your blog.

Summary

It took me longer to write this article than to get the blog up and running. That, I think, says a lot. I really like the minimalistic approach of toto and the frictionless publishing to Heroku. I also actually like writing in markdown.

If you are considering creating a blog, or maybe moving your existing, I would definitively recommend the toto and Heroku combo. After all, it will only cost you five minutes.

1
2
$ defaults write com.apple.finder AppleShowAllFiles TRUE
$ killall Finder

This will show you all of the hidden files and folders on your operating system. If you want to reverse the command replace TRUE with FALSE.

That’s all.

SynchronizationContext to the rescue. Here’s what the documentation says:

Provides the basic functionality for propagating a synchronization context in various synchronization models. The purpose of the synchronization model implemented by this class is to allow the internal asynchronous/synchronization operations of the common language runtime (CLR) to behave properly with different synchronization models. This model also simplifies some of the requirements that managed applications have had to follow in order to work correctly under different synchronization environments.

What this means is that you can use the SynchronizationContext class to dispatch a call to the right thread synchronously using Send, or asynchronously using Post.

Here is a simple example where we show a message box from a background worker using the Send method on the SynchronizationContext class. When we initialize the Worker class on line 15 we pass in SynchronizationContext.Current which holds the synchronization context for the current thread, i.e. the main UI thread. We then use this context to dispatch calls from the background worker to the UI thread, and the message box is properly shown.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
public partial class Form : System.Windows.Forms.Form
{
    public Form()
    {
        InitializeComponent();
    }

    private void buttonStart_Click(object sender, EventArgs e)
    {
        StartAsyncJob();
    }

    private void StartAsyncJob()
    {
        var worker = new Worker(SynchronizationContext.Current);

        backgroundWorker.DoWork += (sender, e) => worker.DoWork();
        backgroundWorker.RunWorkerAsync();
    }
}

public class Worker
{
    private readonly SynchronizationContext _synchronizationContext;

    public Worker(SynchronizationContext synchronizationContext)
    {
        _synchronizationContext = synchronizationContext;
    }

    public void DoWork()
    {
        _synchronizationContext.Send(callback => MessageBox.Show("Hello from background worker!"), null);
    }
}

The full example application can be found here.

The Dependency Inversion Principle is one form of decoupling as it states:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend upon details. Details should depend upon abstractions.

So what does this actually mean? Let’s look at a method in a BlogService.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class BlogService
{
    private Repository _repository;

    public BlogService()
    {
        _repository = new Repository();
    }

    public void ProcessComment(Comment comment)
    {
        _repository.Save(comment);

        // Send notification to author and do other stuff here
    }
}

The BlogService, being the high-level module, has a dependency on the Repository, the low-level module. (A dependency, by the way, can easily be spotted by looking for the new keyword.)

To break this dependency, we are supposed to invert the dependency and make both the Repository and BlogService dependent to an abstraction.

To create the abstraction we introduce an interface called IRepository. In order to make the BlogService depend upon the abstraction, we need to remove the creation of the Repository inside of the BlogService. Instead we inject an IRepository in the constructor when we create a BlogService instance. This way the BlogService is decoupled from the Repository, and it does not really care what repository it gets, as long as it implements the IRepository.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public interface IRepository
{
    void Save(Comment comment);
}

public class BlogService
{
    private IRepository _repository;

    public BlogService(IRepository repository)
    {
        _repository = repository;
    }

    public void ProcessComment(Comment comment)
    {
        _repository().Save(comment);

        // Send notification to author and do other stuff here
    }
}

To make the Repository depend on an abstraction and make it useful for the BlogService, it simply needs to implement the IRepository interface.

1
2
3
4
5
6
7
public class Repository : IRepository
{
    public void Save(Comment comment)
    {
        // Save the comment
    }
}

The dependency between BlogService and Repository is now removed and both depends upon an abstraction; the IRepository. Both classes can easily be changed, and even replaced without affecting each other.

Who “owns” the abstraction?

Let’s say the BlogService belongs in the Domain or Business Layer and the Repository belongs in the Persistence or Data Access Layer. Before we introduced DI this made the Domain Layer depend upon the Persistence Layer. To invert this dependency we should make the Persistence Layer dependent on the Domain Layer. Therefore the IRepository belongs in the Domain Layer.

To install, open a terminal window and type:

1
2
$ cd /Applications/TextMate.app/Contents/SharedSupport/Bundles
$ git clone git://github.com/dchelimsky/rspec-tmbundle.git RSpec.tmbundle

The output should be something like:

1
2
3
4
5
remote: Counting objects: 46507, done.
remote: Compressing objects: 100% (10783/10783), done.
remote: Total 46507 (delta 33212), reused 46206 (delta 33056)
Receiving objects: 100% (46507/46507), 5.94 MiB | 882 KiB/s, done.
Resolving deltas: 100% (33212/33212), done.

Now, reload your bundles in TextMate from the ‘Bundles > Bundle Editor > Reload Bundles’ menu.

To update, simply open a terminal window and type:

1
2
$ cd /Applications/TextMate.app/Contents/SharedSupport/Bundles/RSpec.tmbundle
$ git pull

Principles:

• DRY – Don’t Repeat Yourself
• KISS – Keep It Simple and Stupid
• Convention over Configuration
• Composition over Inheritance
• Tell Don’t Ask
• Law of Demeter
• CQS - Command/Query Separation
• S.O.L.I.D

Practices:

• TDD - Test Driven Development (The Three Laws of TDD)
• BDD - Behavior Driven Development
• Code Refactoring
• Pair Programming
• Sit Together
• Collective Code Ownership
• Continuous Integration
• Code Review

If you are using the same entities for both querying and updating (commands), you can’t get rid of the properties all together, but you can limit their use to querying by making them read-only.

Let me explain by giving an example.

Model behavior not state

Take a prescription object with one property, CeasedAt. (Ceasing a prescription means aborting the treatment.) To cease a prescription we simply set DateTime.Now on this property. Fine, that works.

1
2
3
4
public class Prescription
{
    public DateTime? CeasedAt { get; set; }
}

Then of course the requirements changes. We now have to specify a reason why the prescription is ceased. We add a new property to the prescription object, CeasedBecauseOf.

1
2
3
4
5
public class Prescription
{
    public DateTime? CeasedAt { get; set; }
    public string CeasedBecauseOf { get; set; }
}

Fine, but how can we ensure that this is set every time we set the CeasedAt property? Well, the problem is that we can’t. All the developers must know this when using this class, and let’s face it, there is a very small chance of that happening, at least over a period of time. Of course we can add a comment describing the requirement, but I don’t like comments. Not everybody reads them, and they tend to get outdated over time as the code changes and the comments doesn’t. I want the code to express it self.

So let’s try to express this requirement using nothing but code. We keep the CeasedAt property but make the setter private. Then we add a method, Cease.

1
2
3
4
5
6
7
8
9
10
11
12
public class Prescription
{
    public DateTime? CeasedAt { get; private set; }

    public void Cease()
    {
        if (CeasedAt != null)
            throw new InvalidOperationException("Prescription is already ceased.");

        CeasedAt = DateTime.Now;
    }
}

Much better! Not only is the code now both easier to understand as well as use, but it’s also easier to change since we have encapsulated how we cease a prescription. We are also protected against somebody somewhere accidentally setting CeasedAt on a already ceased prescription.

When requirement changes we simply add reason as a parameter to the Cease method.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Prescription
{
    public DateTime? CeasedAt { get; private set; }
    public string CeasedBecauseOf { get; private set; }

    public void Cease(string reason)
    {
        if (CeasedAt != null)
            throw new InvalidOperationException("Prescription is already ceased.");

        if (string.IsNullOrEmpty(reason))
            throw new ArgumentNullException("reason");

        CeasedAt = DateTime.Now;
        CeasedBecauseOf = reason;
    }
}

This will ensure at compile time that the requirement is fulfilled. The code also expresses the requirements more clearly. When we cease a prescription we have to specify a reason. In the previous example we could not know that from just reading the code, and therefore we were running a risk of introducing a bug if not all developers on our team was familiar with this requirement.

Don’t Repeat Yourself

One other problem with the first example where we weren’t encapsulating how to cease a prescription is that we violate the DRY (Don’t Repeat Yourself) principle. Let’s say that we can cease a prescription ten different places in our program, we then have ten places where we actually specify how to cease a prescription: by setting a property. I can almost guaranty you that this will lead to a future bug report, or at the very least, fragile and hard to change code.

We do a presenter first approach. This means that the presenter is created/loaded first, then it is asked to give you a UI that can be shown on the screen.

The Presenter

The interface implemented by all presenters looks something like this:

1
2
3
4
5
public interface IPresenter
{
    void Initialize();
    object UI { get; }
}

The initialize method is called whenever the presenter is constructed. The UI property returns the view. The reason that it is of type object, is that then there is no need to reference System.Windows.Forms in the presenter library. This is not crucial as long as you keep UI elements out of the presenters since they are not very unit test friendly.

Instead of the presenters implementing IPresenter directly, we create a specific interface that inherits IPresenter for each presenter. This interface is usually empty.

1
2
3
public interface IMyPresenter : IPresenter
{
}

In addition, the presenter must implement a callback interface. The view knows nothing about the presenter itself. Instead it gets a reference to this interface which contains one method for each operation that can be performed on the view plus one for each event that can be raised by a control in the view. Needless to say, we don’t create a method for all events, only the ones we need to respond on.

1
2
3
4
5
public interface IMyPresenterCallbacks
{
    void OnSave();
    void OnMyTextChanged();
}

As you may have noticed, both methods on this interface is declared without any parameters and returns void. This is important, otherwise presentation logic might leaking into the view. The presenter always asks the view when it needs information, the view never tells the presenter anything, thus parameter less. Instead of the presenter returning something to the view, it explicitly sets a property or several on the view, thus void. This is actually what makes the view passive – the presenter is doing all the work.

Enough abstractions, let’s move on to the actual implementation of the presenter.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public class MyPresenter : IMyPresenter, IMyPresenterCallbacks
{
    private IMyView _view;

    public MyPresenter(IMyView view)
    {
        _view = view;
    }

    public object UI
    {
        get { return _view; }
    }

    public void Initialize()
    {
        _view.Attach(this);
        _view.SaveButtonText = "Save";
        _view.SaveButtonEnabled = false;
    }

    public void OnSave()
    {
        // Save _view.MyText
    }

    public void OnMyTextChanged()
    {
        _view.SaveButtonEnabled = !string.IsNullOrEmpty(_view.MyText);
    }
}

Nothing magic going on here. As you can see the presenter implements both the IMyPresenter interface as well as the IMyPresenterCallbacks and it gets an instance of an IMyView injected in the constructor, which again can be retrieved form the UI property.

Attaching the presenter to the view so that they can communicate with each other is done on line 17 in the initialize method. Here we also set the default or initial state of the view.

The callback methods doesn’t do much in this example other then enabling/disabling the save button when the text is changed. Just notice that the presenter asks the view for the MyText property, and then tells the view to enable/disable its save button based on whether or not the MyText property is empty. Since this logic is moved from the view into the presenter, we can actually have unit tests that verify this behavior. Cool, or what?

So, how does the callback methods gets invoked? To find out we need to take a look at how the view is implemented.

The View

The base interface for all view looks like this:

1
2
3
4
public interface IView<TCallbacks>
{
    void Attach(TCallbacks presenter);
}

A simple generic interface with one method used by the presenter to attach itself. The TCallbacks type parameter is the type of the callbacks interface that the presenter implements. In this example; IMyPresenterCallbacks.

As you saw, MyPresenter got an instance of an IMyView. This is the interface specific to one view and it contains properties for all input fields such as text boxes, check boxes, drop downs etc., labels and state properties of the controls.

1
2
3
4
5
6
public interface IMyView : IView<IMyPresenterCallbacks>
{
    string MyText { get; set; }
    string SaveButtonText { get; set; }
    bool SaveButtonEnabled { get; set; }
}

Finally, we’ll look at how the view is implemented.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public partial class MyView : Form, IMyView
{
    private Button _saveButton;
    private TextBox _myTextBox;

	public MyView()
	{
		InitializeComponent();
	}

    public void Attach(IMyPresenterCallbacks callback)
    {
        _saveButton.Click += (sender, e) => callback.OnSave();
        _myTextBox.TextChanged += (sender, e) => callback.OnMyTextChanged();
    }

    public string MyText
    {
        get { return _myTextBox.Text; }
        set { _myTextBox.Text = value; }
    }

    public string SaveButtonText
    {
        get { return _saveButton.Text; }
        set { _saveButton.Text = value; }
    }

    public bool SaveButtonEnabled
    {
        get { return _saveButton.Enabled; }
        set { _saveButton.Enabled = value; }
    }
}

This class is a simple Windows Forms form or control implementing the IMyView interface. The properties on the interface is basically just wrapping the properties of the controls, and does not do anything else. Remember that any logic is in the presenter.

Attaching the presenter to the view enabling the presenter to react on events generated by the view is done in the attach method, which you saw the presenter called when it was initialized. On line 8 the Click event of the save button is attached to the OnSave method on the presenters callback interface and on line 9 the TextChanged event of the text box is attached to the OnMyTextChanged method. Here we do this using a lambda expression, keeping things nice and simple I think, but it can of course be done using normal event/delegate syntax. When the events are hooked up, the callback methods on the presenter gets called whenever one of these events is raised. And that’s about it.

Summary

At first this might look a bit overwhelming. Creating three interfaces, one presenter and one view just to get something to show up on the screen can seem costly, but I think the benefits outweighs the cost. After all it does not take many minutes creating these interfaces and classes.

First of all using this approach it makes almost everything testable. There is not much logic left in the view that are not tested. Secondly, since it introduces separation between the view and the presentation logic they can be developed separately by different developers and/or designers as long as the contracts (IMyView and IMyPresenterCallbacks) are implemented first.

• The Antlers - Hospice
• Sunset Rubdown - Dragonslayer
• Grizzly Bear - Veckatimest
• Animal Collective - Merriweather Post Pavilion
• The Flaming Lips - Embryonic
• Girls - Album
• Cymbals Eat Guitars - Why There Are Mountains
• Dinosaur Jr. - Farm
• Baroness - Blue Record
• Thåström - Kärlek Är För Dom

We’ve also entered a new decade, which means that I should probably also make up my mind about the best album of the 2000’s. Off course I can’t. It stands between Arcade Fire - Funeral and Radiohead - Kid A. You decide.