updated: added sven’s point from the comments

Explaining agile to customers is hard, sometimes more, sometimes less so. In order to improve communication and make it clear what to expect and what not to I came up with the following checklist of what agile projects are about:

You DO get a working, maintainable, production ready, 100% quality piece of software in a fixed amount of time.
You do get a first working, maintainable, production ready, 100% quality version of that software after a very short time (usually 1-2 weeks).
You DO get to launch your software in time.
We DO pair program all the time to ensure that quality and it doesn’t slow us down.
We DO write automated tests to ensure that quality and it doesn’t slow us down.
You DON’T necessarily get all the features you wanted after an iteration.
That’s why it’s important that you DO prioritize what’s most important for you.
We DO estimate how long each feature will take us to implement. But it’s only an estimate.
We DON’T accept a functional specification you bring in as a basis for our work.
We DON’T believe this would work. We DON’T believe it is possible to completely specify a software upfront with tolerable effort.
We DO use your functional spec as a basis for a discussion where we’ll write down stories for each feature together with you. Those form the basis of our work.
We DO embrace changing requirements by working in short iterations.

We DO deliver successful software projects when working like this.

__________________
Signature Customer

Anything I forgot? The comments are open.

Wow, this was the month of conferences. First we visited Barcelona for the Euruko: a great conference taking place every year in a different city. We attended it the 3rd time. The talks ranged from practical like “Cooking with Chef“, over entertaining like “Fun with Ruby (and without R***s), program your own games with Gosu” to just geeky like the lightning talk about “Vimmish and how much fun gramma parsers can be”. I really liked the 2 days 1 track format and the people I met there. And you can be sure that we will be in Krakow next year too.

5 days later I visited Amsterdam for Ruby on OS X, which I already blogged about.

And a little more than a week later, until yesterday, four of us attended the RailsWayCon here in Berlin, which tries to fill the gab that the RailsConf Europe left. The first day was reserved for whole day tutorial sessions.

The second day offered a lot of advanced topics to choose from in 3 tracks. I chose to hear more about Asynchronous Processing from Mathias Meyer and the nitty gritty details about Events from Lourens Naudé. The keynote about the Present and Future of Programming Languages by Ola Bini was also very interesting.

Upstream also took an active part at the conference: Alex gave his talk about CouchDB Frameworks for Ruby and CouchApp (using his new presentation tool boom_amazing) and I introduced MacRuby, the Ruby that plays nice with Objective-C.

On the third day Yehuda Katz revealed some more details about Rails 3. The talk by Michael Koziarski about Rails Performance was good for a reality check. In the afternoon everybody was tired after 3 days of conference and the talks lost quality. Still a very good conference with potential.

Edit: I updated some infos, to address things Eloy pointed out in the comment.

I had the opportunity to be at the Ruby on OS X conference in Amsterdam. As the name suggests, it was a conference focused on the state of Ruby on the OS X Platform. The talks generally gave a good background about the current status and where Ruby on OS X is going. All talks will be available in video format, according to fingertips. In the meantime, here are my conference notes for a quick overview. Though they vary very much in detail, depending on my personal interest and my ability to focus after getting to Amsterdam during the night before the conference.

The first talk was about LimeChat an IRC chat program by Satoshi Nakagawa written in RubyCocoa. Some LimeChat highlights are the compact interface, its unobtrusive operation, the always-accessible server list, the build in online paste service support and the customizable themes. Satoshi pointed out some edges between RubyCocoa and Objective-C. He mentioned necessary conversion between NSString and RubyString, because they aren’t comparable, the required NSMutableString for Unicode Characters and that the creation of Ruby threads causes interruption of the application loop. Further, he reported that the usage of ruby socket lib or net/http causes hang-ups, thus he used the Objective-C equivalent libs. On the other hand he pointed out that performance was good enough, memory usage and leaks weren’t an issue either, even during longer operation. Determining factor for memory usage was the complexity of the DOM tree in the WebView backed chat window. So no major problem here. LimeChat is currently being ported to MacRuby.

The second talk was held by Rich Kilmer who presented the state of HotCocoa and MacRuby. I watched and read similar talks by him online already, so I only wrote down some interesting bits. In the beginning he gave some insight into the relation between Ruby and Apple. For example ruby gems were changed for Apple in a way that is allow to install certain gems in an extra repository where they are protected from user access. Apple will ship the next OS X version with Ruby 1.8.7. He also stated very clearly, that RubyCocoa will still be supported by Apple in the future. Which makes not much sense to me, because since the appearance of MacRuby the development is effectively come to an halt. But, as Eloy stated in the comment, Apple promised to support it into the future, because developer have put lot of effort into applications based on RubyCocoa.

Then Rich introduced MacRuby. Laurent stated during this part of the presentation, that although memory allocation is a little slower in MacRuby, Objects don’t need more Memory than their pure Objective-C counterpart. After outlining the improvements of MacRuby, Rich came to his Cocoa-mapping layer HotCocoa. HotCocoa tries to provide sensible defaults for most Cocoa GUI Objects. It also provide short names for important, mostly rather long named Objective-C Constants. All the mapping files take care of themselves to include their corresponding framework. He than explains HotCocoas delegation feature, which allows you to provide delegate methods by defining its logic in a block. A documentation for all these mappings, which can be viewed only in lib/ruby/1.8/hotcocoa/mappings until now, will be available soon.

Further, he explained the HotCocoa command line tool. Which, like the Rails script command, generates some infrastructure to build and deploy MacRuby apps from the command line. This infrastructure will be extended soon by providing a more MVC like directory structure. Another addition will be the support of a virtual file system which allow to ship self contained applications and hide the source code. At the end of his talk he mentioned the possibility to bring MacRuby code to other platforms with the use of a ahead of time compilation.

Without further ado the talk about Rucola by Eloy Duran followed. Rucola is a CLI focused MVC framework for RubyCocoa. It provides rake tasks for compiling, testing, bundling and update feed setup. Like known from Rails, it supports multiple environments. For the ease of development it offers generators for various purposes e.g. for test stubs. It also provides libs to help with testing. Rucola will also be available in MacRuby.

After the lunch-break John Shea talked about his experience with MacRuby and game programming. He just needed 2 hours to implement Tetris in 2D with NSView. Doing this in OpenGL was a little harder. He showed different other games made by him which use OpenGL and were implemented mainly with MacRuby (99%). OpenGL can be used through CoreGraphics Interface with MacRuby. That way, he achived to display 100K polygons including textures with 58.1 Frames. Also some nice particle effects implemented with MacRuby where shown. As limiting factor when using MacRuby he pinpointed the garbage collection and the method dispatch performance. Latter should be fixed with MacRuby 0.5 as Laurent stated later.

The following talk by Manfred Stienstra was about testing Cocoa Apps with the Rucola framework. As a testing framework it uses test spec together with mocha for mocking.

One major point of the talk was how to test controllers. Rucola provides methods to generate fake outlets to test the controller against. But this didn’t work with Objective-C controller. Thus as another mean a small compiler in Rucola can be used to compile and return a controller from a nib file. Working fake outlets for Objective-C Controllers will be supported as expected on MacRuby though.

Sometimes an existing application loop is required. Manfred suggested to setup and run this loop in a separate thread in the background while testing. Also the issues of UI testing came up. A practical approach was to load the nib file and inspect the content.

A less technical, but still not less interesting talk about shipping OS X desktop applications with an interpreted language was given by Koen Bok from Sofa. At first he talked about shipping the source with the product. In his experience it is better to face the legal and commercial risk by protecting the code by law than invest time and money in obfuscation. So you will be legal prepared, if problems arise, which didn’t happen so far to Sofa. The second part was targeted specifically at people who came from web development to the Mac. You should be prepared to be still a second grade citizen on the OS X platform. As Ruby people we should use our advantages of mature frameworks and tools we know from our work with e.g. rails. Third, the user experience is a major factor on OS X with a higher baseline than web applications. Thus more work is required e.g. for Drag and Drop behavior or keyboard shortcuts. Also snappiness is an important factor for the user experience at OS X. So optimizing speed/snappiness is an optimization of the user experience. The iPhone is a good example to learn from. As for the general interface design it is a good idea to have a designer in the team, or as Koen stated it. Get a Designer!

The last official talk was about Gosu, an easy-to-use game development library and Rubenstein, a satirical re-implementation of Wolfenstein in Ruby with the help of Gosu. Julian Raschke, the creator of Gosu and Ninh Bui from phusion and the author of Rubenstein, held the talk. First Ninh explained some theory about Raycasting for rendering a 3D game. Then he looked at some optimizations, like splitting the space in discreet elements of pixels to speed up the Raycasting. At last he explained how he used Gosu for texturing in Rubenstein.

Then Julian got into detail about Gosu. The library consists only of 9 classes and has a really easy to use API. It is around for 3 years already, and the main focus stayed on the easy usability. It is available for Mac, Linux and Windows (gem install gosu). Julian showed some games created with Gosu and talked how it helps to interact with other frameworks, e.g. open-gl for 2D/3D effects or Chipmunk for physics simulation. At last both demoed Rubenstein, hilarious. That marked the official end of ruby on OS X.

At the Hackfest after lunch Laurent Sansonetti, the brain behind MacRuby, showed some internals about the currently experimental 0.5 branch, which is based on LLVM. He talked about its current state, which mile stones they reached already to make MacRuby 0.5 installable, and showed some dark corners of ruby code, which make the job so hard.

I also got a glimpse on a new iPhone game from Julian made with Gosu, which looked pretty good. But before you get too excited about the thought of ruby on the iPhone, it was made with C++ version of Gosu. The Game will be officially released soon.

Later I joined Cristi, Eloy, Julian, Laurent and others for a beer and a night out in Amsterdam till I caught my train back to Berlin early in the morning.

Ruby on OS X was totally worth the effort to get there spontaneously. This rather long day I learned a lot about Cocoa and MacRuby, met very nice people, as on every ruby conference so far, and got an impression of Amsterdam that made me want to visit the city again, but than with more time.

After my talk about Ruby CouchDB frameworks at Scotland on Rails where I dismissed a few of of the libraries available (including my own Couhch Potato) as not fitting the CouchDB way of doing things, I have been hacking away the past few weeks working on a complete overhaul of Couch Potato.

As a first result I have just released version 0.2 of the framework. Its new goals are simplicity, embracing the CouchDB semantics and testability. In order to achieve this I had to introduce some major changes:

I disconnected models from the database - there are no more save/get/find methods in the models. Instead you can hand the models to a database object that will save/load documents for you - this allows for unit tests that are completely disconnected from the database

I have dropped associations and thrown away all the ActiveRecord like view creation/querying, replacing it with a new, more CouchDB like system. That new system is lighter, simpler and easier to extend.

The following paragraphs will show you how to work with the new Couch Potato.

Saving / loading models

As I said I have decoupled the models from the database, a model doesn’t have permanent access to the database anymore. Instead you instantiate a database object yourself and tell it to load or save a model object. This change isn’t so much about CouchDB as it is about testability. Having the database separated means you can now have true unit test of your models without talking to the database. Here is how you save/load models:

The database is responsible for running the model’s validations and lifecycle callbacks, saving the document to the database and afterwards setting the _id and _rev on the model. This way a lot of the persistence related logic is removed from the models making them more lightweight and most importantly easier to test (see below).

New Views

Overhauling of the views had two main goals:

• provide a simple and extensible way for saving/querying views that works the way CouchDB works
• since models don’t have access to the database anymore, find a new way to query them

Here is how you create and query a simple view:

The way views work is now essentially reversed (inversion of control, rings a bell?). Instead of the view method calling the database the new view method creates a specification for a CouchDB view. The view is passed to the actual database in order to query CouchDB. Again this makes testing easier (see next section) but it also gives Couch Potato a clean interface in order to make creating views easier through abstractions. There is now a hierarchy of view specification classes that you can use to more easily create and query views. The above example used the CouchPotato::View::ModelViewSpec which is the default. This spec creates a view whose map function emits one (or an array of) attribute of the model and returns full documents.

Other view specs let you create more customized views, for example the RawViewSpec, which lets you define your own map/reduce functions and return the raw CouchDB results hash.

For more examples see the Documentation in the CouchPotato::View::*ViewSpec classes.

Testing

As I have mentioned repeatedly decoupling the database from the models makes testing easier. With the new Couch Potato you can unit test your models without hitting the database once. First of all that makes your test lightning fast, and secondly it allows you to more easily test for example your lifecycle callbacks because you can call them directly passing them a stub or mock database.

Here’s an example: (with RSpec)

If you don’t like calling the run_callbacks method you can also use the actual database object but without a real connection to CouchDB. Couch Potato is based on the excellent CouchRest - a more low level CouchDB framework. The CouchPotato::Database constructor expects an instance of a CouchRest database which we can replace with a stub:

For more details and examples please see the README, the RDocs and watch this blog. If you want to know all about Couch Potato I encourage you to read through its source code and specs - it’s not that much code actually. Note that all this is still work in progress and time will show how well all of this works. I would be happy to hear your feedback.

We recently deployed an app on a VM with CentOS 5.3. To our delight, the packet manager yum wasn’t pre-installed. We spent some time to get it running. The Howto on http://eric.lubow.org/2008/misc/adding-yum-to-centos-5/ was a great help, but it was for CentOS 5.2. So this is an update to Eric’s blogpost.

You need to have rpm and wget already installed. Create a temporary directory, paste the following code in a file in that directory, make it executable and run it:


mkdir temp && cd temp
vim yumdownload



#!/bin/bash


for file in \
elfutils-0.137-3.el5.i386.rpm \
elfutils-libs-0.137-3.el5.i386.rpm \
elfutils-libelf-0.137-3.el5.i386.rpm \
expat-1.95.8-8.2.1.i386.rpm \
gmp-4.1.4-10.el5.i386.rpm \
libxml2-2.6.26-2.1.2.7.i386.rpm \
libxml2-python-2.6.26-2.1.2.7.i386.rpm \
m2crypto-0.16-6.el5.3.i386.rpm \
python-2.4.3-24.el5.i386.rpm \
python-elementtree-1.2.6-5.i386.rpm \
python-iniparse-0.2.3-4.el5.noarch.rpm \
python-sqlite-1.1.7-1.2.1.i386.rpm \
python-urlgrabber-3.1.0-5.el5.noarch.rpm \
readline-5.1-1.1.i386.rpm \
rpm-4.4.2.3-9.el5.i386.rpm \
rpm-libs-4.4.2.3-9.el5.i386.rpm \
rpm-python-4.4.2.3-9.el5.i386.rpm \
sqlite-3.3.6-2.i386.rpm \
yum-3.2.19-18.el5.centos.noarch.rpm \
yum-fastestmirror-1.1.16-13.el5.centos.noarch.rpm \
yum-metadata-parser-1.1.2-2.el5.i386.rpm
do wget http://mirror.centos.org/centos-5/5.3/os/i386/CentOS/$file;
done



chmod a+x yumdownload
./yumdownload

This will get you all rpms you might need before be able to install yum.

Now try installing them all by typing:

rpm -Uvh *.rpm

This might not work, at least not for us. So try to install yum directly with rpm -Uvh yum-3.2.19-18.el5.centos.noarch.rpm and let the errors guide you. When you run into a circular dependencies, install the rpm by ignoring the dependencies. eg.

rpm -Uvh --nodeps yum-fastestmirror*


This should finally allow you to install yum. Good Luck.

After my Ruby sittin’ on the Couch talk about Ruby Frameworks and CouchDB at Scotland on Rails last week a bit of a debate started. In the talk I did compare the available Ruby Frameworks and discussed how well they fit the CouchDB way of doing things. In my conclusion I recommended using either CouchRest or RelaxDB for development and at the same time urged people not to use one of the ActiveRecord like libraries like CouchFoo.

As it seems to me the intention of my talk hasn’t reached all of its audience yet I’ll try to make my point again using this blog post.

The frameworks I looked at could be divided into two classes: the ones using CouchDB semantics (e.g. CouchRest/RelaxDB) and the ones trying to provide an ActiveRecord like interface for the applications (e.g. CouchFoo). The reasons I recommended not to use ActiveRecord semantics are:

CouchDB is not about relations

In ActiveRecord we have to model our domain models so they fit into a relational schema. That means flat tables and relationships between two tables, through a third and fourth table etc. To get results from the database we usually join a few tables and get back the resulting rows, nicely converted into Ruby objects for us. That is (sort of) fine for a relational database because all it has are those tables but it doesn’t work at all with CouchDB.

To use CouchDB to its full potential you need to understand and use its views

CouchDB doesn’t have a concept of tables at all. And the way you pull your data from CouchDB is fundamentally different. Instead of joining data from different tables via an SQL query you procedurally build up an index of data by providing the map and reduce functions which you then query.

In order to fully use CouchDB you have to write custom map/reduce functions and abstracting that into an API that was designed for generating SQL queries doesn’t allow you that.

I could go into more details but that really is my main point. I know from my experience that changing the wiring in your head after too many years of ActiveRecord is hard so I don’t expect anyone to immediately agree with me but I do believe that the only viable way of using CouchDB is through the interface that was designed for it and not by an abstractions that just happened to be there first.

I’m looking forward to a lively discussion, either in the comments or on other blogs.

Ruby on Rails 2.3 is almost there and brings a bunch of pretty cool new features. One of them is called templates and it allows you to customize the bootstrapping of new applications in order to automate the initial setup of your new app and hence get up to speed faster.

I find the naming a bit confusing: since we already have view templates in Rails I will refer to this new feature as application templates from now on.

So what does an application template do? Whenever you start a new rails application you are already using the Rails default template by issuing the rails command. It creates the usual app, config etc. folders and generates a bunch of scripts and configuration files for you. Application templates simply extend this process by allowing you to add your own setup steps. This is done by writing your own template file (or grabbing someone else’s).

Pratik Naik has already written an excellent tutorial on this so I’m not going to repeat what’s already written. Basically Rails offers you a few convenience methods for adding for example routes, plugins, gems or files to your new application.

So this blog post is more about showing off my very own template that I wrote today. (For the impatient: here it is).

Of course I’m not the first and only one who has written such a template so before I started I found this collection of templates which I immediately started to steal borrow from. As you probably know every programmer has its own style, uses his own unique set of tools in his (or her) own way. Which is why I found all of the templates I saw didn’t really fit my very own needs. The ones I found were pretty basic (to me) so when I rolled my own I took what I needed from what was there and added a whole bunch of my own stuff:

• setup of configuration files for Rspec, Cucumber and Culerity (Culerity is my plugin for driving Celerity - think Selenium but withour having to use a real browser - with Cucumber)
• a working user registration/login process using authlogic, including all controllers and views
• an XHTML application layout with jQuery (+ a few plugins) and blueprint CSS set up
• a simple capistrano deployment script
• German localization for all the built-in helpers
• a Thinking Sphinx configuration file

I pretty much need all of the above for 99% of my Rails projects and it costs me at least a day every time to set this all up. Well, not anymore Now I can run rails my_new_app -m http://gist.github.com/75038 and immediately after that start working on the distinct features.

I’m already planning to add a few extra. First of all the user authentication needs cucumber features so I don’t break anything when extending that. I also want to add configuration and deployment for a staging server. And maybe make the whole script a bit more configurable, i.e. install thinking sphinx or not etc.

The script is already pretty large so I’m not sure how much more I would want to put into it. Since you can apply templates to exisitng apps it will probably make sense to split the whole thing up at some point, so I could put the authentication part into its own template.

If you want to get started with application templates now I suggest you simply start with mine and/or the others and grab whatever you need. Just make sure you re-publish what you added so we can all build upon everyone’s work. Thanks.

On a recent Rails project we have been working a lot with PDF documents. The application generates PDF invoices and account statements, places markers and comments into existing documents and also merges multiple single page PDFs into one. We do all this with a few PDF tools:

• the PDF::Writer library for Ruby to generate PDFs
• pdftk - to merge multiple PDFs into one or overlay them
• pdftotext part of the xpdf library, to extract texts from PDFs

On OSX all of these can be installed via MacPorts. Debian has packages as well.

While PDF::Writer is a Ruby library pdftk is a command line tool. We simple call it using Kernel.system and check the return code via the $? variable.

With all this PDF processing the need for testing the contents of the generated documents arose. We have factored out all the PDF processing into a bunch of extra classes which we simply unit test with RSpec: make sure the parameters are passed to the command line correctly, that the right exception is thrown for each return code etc.

In addition to unit testing we also write customer driven acceptance tests with Cucumber, where we assert on a high level the outcome of certain actions. With HTML pages we can simply use the built-in steps that in turn use Webrat to parse the HTML like this:

Now in our case the invoice link links to a PDF but we still want to know what’s inside the document. The solution we came up with looks like this:

What this does in the background is follow the link as usual, write the response into a temporary file, convert that to text using pdftotext and write the result back into the response. This way we can make assertions about the contents of the PDF almost as if it were an HTML page (except for tags of course). Here is the implementation:

On Thursday I gave a talk about Bug fighting with TDD and how it will help you to write better software at the Ruby User Group in Berlin. Sorry, I won’t put the slides online, although people asked about it. I think they are a pretty useless collection of keywords and pictures without the talking. Instead I like to provide a collection of links to dive into the whole testing matters.

First a collection of tools you can choose from for various testing scenarios. They all have their pros and cons, it just comes down to which will do the job best for you.

Tools for Unit Testing

• Rspec
• Test/Unit (part of Rails)
• shoulda

Tools for Mocking

• Flexmock
• Mocha
• RR

Tools for Acceptance Testing

• Webrat
• Cucumber
• HtmlUnit (with JRuby)
• Selenium

Tools to generate test objects

• Machinist
• FactoryGirl
• ObjectDaddy

Misc tools

• Autotest
• Tarantula
• Culerity

To save you the initial searching where to start, I collected some links where you find basic information about testing in general or with certain tools.

Getting started

• A Guide to Testing Rails Applications
• An introduction to RSpec
• Functional Testing awesomeness with Webrat
• How I Test Controllers, 2009 Remix
• Shoulda tutorial
• Mock objects explained and intro to Mocha (de)

For everyone who wants to get more into the subject, I drilled down my feed reader to collect some interesting blog posts on testing matters.

Opinions and In-sign

• The Great Test Framework Dance-off
• Thoughts on Developer Testing
• Spikes, test-after, and learning how to test
• A case against a case against mocking and stubbing
• A critical look at the current state of Ruby testing
• One Line Tests Without the Smells
• Mocks Aren’t Stubs
• Testing as Communication: Real-World Techniques Notes
• When duplication in tests informs design
• Writing Code That Doesn’t Suck (vid)

So much for my two cents to make the software world better.

—

Does your company need help with software testing? We can help: check out our new product Scene Investigation.

Last week was my first Erlang gig. I paired up with Jan Lehnardt (core committer of CouchDB). Our goal was to implement a new statistics module for CouchDB within one week. Jan knew more about the CouchDB code and Erlang, I contributed my knowledge about testing and pair programming.

Integration Testing in JavaScript

Since the testing infrastructure in CouchDB left some room for improvement we decided to introduce some new concepts. The existing tests were written in JavaScript penetrating the database via its HTTP/JSON interface. The tests were really long and coarse grained which lead to a problem: When one of the tests broke it wasn’t very easy to figure out which one. We didn’t want to replace or add too much to the existing, self-made test framework so we just added a bit of sugar: BDD style specs with meaningful names:

The TEquals function is just our extension of an existing function T which is responsible for reporting errors when the assertion doesn’t match. By passing the name of the test spec we can now display that name along with the error message:

Error in ’should show the number of 404 responses’: ‘CouchDB.stats_request(’httpd’, ‘not_found’)’ should be ‘1′ but was ‘0′.

Unit Testing in Erlang

In addition to those integration tests we wanted to add some unit testing on a lower level. Turns out the only unit testing framework for Erlang seems to be EUnit, which is a very barebones (at least when you come from something like RSpec) xUnit type of tool. You define a test by appending “_test” to your function name and then you have a bunch of assert statements at your disposal. Well that’s at least something and it worked. Here is an example:

We added the test_setup for starting and tearing down processes needed for our tests. Then we pass a fun with the actual test code. We got through the week pretty ok with this but I really missed a few things:

Erlang

I’ve read the book, I’ve watched numerous screencasts but this was my first real life project in Erlang. Many people complain about its syntax and while this isn’t the most beautiful language I’ve ever seen I have to say it’s not really a big problem. I got used to it on the first day.

What is really powerful in Erlang is pattern matching. Instead of simply assigning a value to a variable you can always match against the structure of that data to extract parts of it:

This example lets you pull out numerous details from the tuple in a single statement. You can do the same for case statements or when overloading functions. So this pattern matching is a powerful concept seen everywhere in Erlang code. It makes the code you write pretty dense which is cool on the one hand but sometimes also makes it hard to read so you have to be careful how much you want to cram into a single line of code.

CouchDB is built using make - which felt like 1990. I’ve never used make much myself so I’m not really qualified to talk about it but we did spend a good amount of time in our MakeFile because of some whitespace problem, and we still haven’t managed to integrate our new tests into the build process. I’d love to see something like Rake being used instead.

All in all this have been very pleasant first steps though. Pairing up for this turned out to be a very good idea, I have learned a lot about Erlang and am eager for more now.