codemotion Berlin 2013 technology lab: The aftermath

No Comments

Two days ago, at the codemotion Berlin 2013, we, i.e. Michael Lex and Ben Ripkens, gave a technology lab. We had an ambitious plan: In three hours we wanted to show typical agile development practices like test-driven development (TDD), acceptance test-driven development (ATDD), continuous integration (CI), continuous delivery (CD) and more while having the attendees work on a small demo project.

The idea for this lab is based on the professional scrum development training course and the agile code camp. Both events take place over the course of multiple days and additionally focus on agile processes. The professional scrum developer course even covers a few software craftsmanship topics. Shrinking the course duration from several days to a few hours sounds like magic. Unfortunately, we are no magicians (and we failed trying to be).


Attendees hacking on the project


Originally it was planned to solely focus the technology lab on shiny new technologies like Neo4j, Riak and Node.JS. We shifted to development practices though as we figured that this is exactly what Berlin’s developer community needs: The start-up scene, of which there is a highly active one in Berlin, has little need for big data technologies. Sure, many of them are helpful, but would it not be more useful to help them ship awesome products and through this help them reach a state where they might actually need to cope with big data issues?

A plan was made: Avoid bureaucracy, avoid some of the overhead that typically comes with development methods (we should probably avoid our agile evangelists for the next few weeks after publishing this) and instead show them techniques and practices, that are cheap, easy to follow, and result in a higher software quality.

The Legendary movie database project was chosen for the lab. The domain is simple: You have movies and actors. Actors can play roles in movies. That’s it! The application would therefore support basic CRUD (create, read, update, delete) operations for movies. Attendees would add CRUD support for actors and work on some usability improvements.

In case you lost count: This is actually the fourth instalment of the movie database! There are also versions that implement ROCA, use AngularJS with requireJS and a mobile version with Sencha Touch.

Technology Stack

As far as the chosen technologies are concerned, we deviated from codecentric’s standard technology stack and chose one which attendees can easily dive into while leveraging existing knowledge. Specifically, we chose JavaScript as the main language. By doing so we were able to use the same language for server and client code. This led to the next technologies: Node.JS for the server side combined with express as a web framework and AngularJS for the front end. Data persistence was done using Neo4j. While not actually necessary, Neo4j is interesting and simple at the same time and therefore a good match for the technology lab.

We further integrated a fair share of testing libraries and frameworks. On the server side, the choice fell on the mocha framework, which is great for testing asynchronous code. For the unit tests, we mocked the Neo4j service using Sinon.JS. On the client side, we used Karma together with Jasmine for both unit-tests and end-to-end-tests.

You can check out the project on GitHub to see the whole technology stack. The project comes with a readme that explains all necessary steps for building, testing and running the application. Dependencies are properly declared in the package.json and can be looked up through the NPM registry.


The timebox was the hardest challenge. The goal required every team to have a continuous integration and delivery infrastructure as well as local development environments and a version control system. To cope with this, we set up everything in advance:

  • Six forks of the project on GitHub under six different users that were created just for this purpose. Attendees were organised in groups in the beginning of the technology lab and added to these projects as collaborators (which grants them commit permissions).
  • The six repositories were connected to Travis-CI for continuous integration. Every commit would therefore result in an execution of a static source code analysis, unit and integration test execution as well as deployment to Heroku.
  • Heroku was used as the target platform. Each team got his own Heroku app. The redeployment was triggered automatically by Travis-CI.

This resulted in a time frame of about 10 minutes from the push to GitHub until a finished deployment to Heroku. The best part: Attendees are not required to fiddle around with Travis-CI secure environments and Heroku configuration.

We prepared thumb drives with VirtualBox images for the attendees’ local development environments. The virtual box image contained everything necessary like an editor, a local database instance, all project dependencies, manuals and cheat sheets for the central frameworks and libraries and of course a fresh clone of the project’s repository.

Lab Outcome

As you might have expected, three hours were not enough time for this technology lab. In fact, the attendees just managed to get an overlook about the application’s sources and made a few modifications to the server and client side. Tests were not written by any of the participants, but questions were asked a lot about test execution and inner workings of the testing frameworks. Overall, the number of source files does not seem to have been a problem, but the number of libraries and their combination was too hard to grasp.

Agile practices suffered in the same way that tests suffered: While the interest in Travis-CI and Heroku was great and the simple configuration got much applause, the attendees had little use for continuous integration during the lab. It was simply not enough time to work independently on tasks and therefore to collaborate through the version control system and see the benefits of CI and CD. At least one agile practice got full attention: Pair programming was done throughout the three hours. Confronted with this bunch of new technologies, the attendees actively shared their insights and worked together by twos or threes on one machine.

On the other hand, preparation and setup went perfectly fine. Every attendee had VirtualBox installed and was able to import the virtual machine without any issues. The first participant to finish the setup was able to work on the code and commit something to their repository after 15 minutes. The decision to go without detailed setup instructions and instead rely completely on VirtualBox was proven right.

In the end, both, the attendees and we as coaches, were satisfied with the technology lab. The attendees further encouraged us to do the technology lab over the course of a full day as this would enable them to dive deeper into other interesting parts of the application like Neo4j and Karma (both of which the participants barely got in contact with). A full-day-course would also leave enough time, to not just learn about agile practices, but really use them. It is one thing to see how easy it is to configure Travis-CI and Heroku, but only by writing tests (and seeing the CI go red), that you can really appreciate it.

In addition to more time, code documentation combined with an architecture overview would surely help the participants. Most tasks were accompanied by hints, which proved to be very helpful for both teams. We need to evaluate how we further support the participants, without simply telling them the solution. Something which is not always easy.

We would love to do this technology lab again, either at a conference or as a separate event. We had a great time. The positive feedback and the great interest in the chosen practices and technologies confirmed that we are moving in the right direction. We hope to see you again next time, but then hopefully for more than just three hours ;-).


Your email address will not be published. Required fields are marked *