Meet us in Berlin this weekend

We're on our way to Berlin for the Plat_Forms 2011 results presentation and awards ceremony. It will take place tonight (Friday) at the Freie Universität Berlin. You can meet us there if you’re interested. No word yet about results, but we’re rooting for the Ruby teams.

The results presentation will be followed by an unconference this Saturday. It’s free to attend, just add yourself to the attendee list. I will give a crash course into Test Driven Development. Thomas will talk about how we’re sharing knowledge at makandra and how makandra notes has eventually evolved into a knowledge management solution for everyone. There will be some other sessions as well.

If you have trouble finding us, just e-mail me your cellphone number (henning dot koch at makandra dot de). I will occasionally check my e-mail and give you a call.


Fri, 25 Nov 2011 09:51:00 GMT

by henning

I hate infinite scrolling

From the very bottom of my heart, I hate infinite scrolling. I hate how it makes the scrollbar jump while I'm dragging it, I hate how it obscures how much of a document I've already read, or how much content there is left. I hate how it seems like such a good idea at first glance, but ultimately just annoys the shit out of everyone. I believe that every time a developer implements infinite scrolling, a kitten orphanage catches fire, everyone dies, and the world becomes a worse place.

Don't implement infinite scrolling.

  • Stefan Huska said about 11 hours later:

    Agree. You will spend more time on these sites and you will never know how. Procrastination is a problem today and this “tool” is not helping us. :-)

  • Aristotle Pagaltzis said 1 day later:

    That’s a good point.

  • vpetkov said 7 days later:

    Forget about the scrollbars. man. Nobody cares about them anymore. And as Aristotle already said I like it, actually. The only problem is with reloading the page. And that isn’t a real issue.

    Article pagination - now that is something annoying.


Tue, 22 Nov 2011 21:19:00 GMT

by henning

Scalable, redundant failsafe Rails hosting infrastructure

Over the past two and a half years the applications we host for customers grew constantly up to several dozen projects today. We insisted on our principles at each point of time over the years: Keeping things simple. We successfully develop software using this principle and we successfully operate our customers’ applications using this principle. Dijkstra knew that “simplicity is prerequisite for reliability” and we state that it is the prerequisite for security, maintainability, scalability and basically whatever else you want.

Up to now we hosted our projects on a single more or less powerful machine, having a backup on a secondary server that kept database and files in sync. Failover (which we fortunately never had to use) was handled by manually routing traffic from the primary to the backup machine. As the number of projects grew we were searching for a (simple but stable, powerful but cheap) solution that offers

  • fully automated, real-time fail-over for HTTP traffic
  • scalable design
  • economical efficiency
  • ready for our upcoming Ruby on Rails cloud™ infrastructure

What came out of what you see in Figure 1. The setup consists of a publicly accessible layer where DNS points to (web) servers. All traffic is terminated there. Incoming traffic is routed to the background application servers internally.

makandra Rails hosting infrastructure

For the web slaves, we have two machines running FreeBSD 8.2 that act as reverse proxies (utilizing nginx) to the backend application servers (Passenger). As most of our applications use SSL there are quite a lot of public IP addresses configured on both BSD machines. Failover for the web servers¹ (on IP level) is handled by the amazing CARP protocol.

CARP can be configured to run in MASTER/BACKUP mode which means the MASTER gets all the traffic and BACKUP only comes into play when the master fails. CARP can also run in load balancing mode where traffic is distributed among the participating machines. To decide whether the servers are up, the master machine sends out advertisement packets so the backup slaves know it is alive. If the backups do not see the advertisement packets for some time, one of the backup slaves becomes the new master. See FreeBSD handbook and OpenBSD FAQ for more details.

The web servers have both an interface within our public VLAN (that is Internet) as well as the private one, which is used for connections to the application servers. Failover (or load balancing) for the backend application servers is carried out by nginx’ proxy module.

This failover on IP level is so important for us because we have dozens of domains pointing to unique IPs (as mentioned, because of SSL) at our infrastructure and we do not even have control over some of the DNS servers. In case of hardware problems with the web servers, we have the secondary waiting to take over automatically with nearly no downtime. The very same for the application servers: If one of them dies, the secondary automatically takes over.

A nice side effect of this setup is that we can easily make use of nginx’ caching possibilities and SSL traffic is loaded off to separate machines. We’re currently planning to add a layer to our infrastructure where customers can have dedicated rails instances in the backend and profit from the failover web slaves, too.

We rolled out this new infrastructure a few weeks ago using Puppet for automated configuration of all involved parts. We are optimistic to give a detailled report about our (positive) experience at some point in the future.

¹ In case you wonder about the hostnames: We name our machines after professors of the computer science department at the University of Augsburg where most of us studied (or are still enjoy studying in case of our student trainee and those writing their thesis at makandra :)).


Wed, 21 Sep 2011 12:58:00 GMT

by thomas

My life on NZT

I was deeply moved by Limitless, a film where Eddie, a deadbeat writer, gets hold of a cognitive enhancer drug called NZT-48. NZT gives Eddie near-unlimited focus and energy, allowing him to push an unhuman workload (and getting him into a lot of trouble).

One of the reasons Limitless touched me was that my workload has been increasing at the office, requiring me to go through tasks at a quicker pace. There's a constant pressure to quickly process and close items on my list. There's no longer time to fuck around with anything, because there's ten other things screaming for my attention at any given time.

Unlike Eddie, I don't have crystal pills of NZT to help me through day. Instead I'm practicing GTD and will myself to quickly push a task to the next higher state of entropy so I can move on. And in some ways, it's been working. My productivity has been increasing steadily, and it's quite a rush to see the amount of stuff that you can process in a day if you set your mind to it.

Unfortunately, this way of operating sucks for the people you're working with. While I was busy mowing through my todo list, my availability to my colleagues has been decreasing dramatically. An example for why this sucks: Last week I gave a junior developer bad advice for dealing with a particular programming problem. When I reviewed his commits a day later I saw pages of tortured code, bending over backwards to solve the problem using the leaky abstraction I had suggested. I'm sure my colleague had noticed that the problem resisted being solved that way. I'm also sure he had considered approaching me because of this. But I was busy talking on Skype all day, getting shit done.

There's a hard limit to how much good you can do in a project if you only have time to touch it twice a day. Even if those touches are brillant deeds of focus and craftmanship, you've basically become the hit-and-run manager who stops by your desk occasionally, kicks over what everyone's been working on and disappears until he does the same thing again tomorrow.

If you are working with a team in any sort of managing capacity, being available for a high-frequency feedback loop is one of the greatest contributions you can bring to a project. It's one of the greatest productivity boosts you can bring to your team. So think about optimizing that for a change, rather than finding better ways to spread yourself thin.

Also, buy the soundtrack of that movie. It's awesome.


Wed, 08 Jun 2011 21:45:00 GMT

by henning

Plat_Forms 2011 post mortem

In January we spent some days in Nuremburg at the 2011 Plat_Forms competition. The event pitched 16 teams of programmers in different web technologies against each other in order to provide insight into the pros and cons of each platform.

The work actually began a week before the competition started. We had to figure out logistics, configure a staging server and decide what pre-baked code we were going to bring. The rules permitted to reuse anything that existed before January 17th. Since we're doing a lot of blank-sheet Rails projects at makandra, software reuse is something we think about a lot. The tricky part was that the requirements wouldn't be revealed before the competition, so what sort of code do you box in a situation like this? We eventually decided to ditch anything too high-level and only package a few essentials:

  • Sign up, sign in, sign out
  • Role-based permissions
  • CRUD on users for admins
  • A pretty application layout
  • CSS and form controls for things like control groups, buttons bars, tag pickers, etc.

The event took place at the Nuremberg conference center where the 16 teams were channelled into two different rooms with desks and chairs. We picked a place in the smaller of the two rooms, which hosted only four teams, hoping that we would have some more quiet there. We installed a lot of hardware on the small desks, including three big-ass screens and a coffee maker :) After we had set up our working environment Monday night, we went for drinks and then to bed.

Tuesday morning we were back at the conference center and received the requirements we were expected to implement over the next two days. The task was to implement an application called "Conferences and Participants" (or "CaP"), where users could sign up, post conferences, sign up for those conferences, befriend other users, invite them to a conference, etc. The specs were 29 pages long and (in my opinion) a lot more than what can be implemented by three developers in three days. The point of the event was to find out how you would deal with that. The features where divided into MUST, SHOULD and MAY categories, so we fed all MUST requirements into Pivotal Tracker and went to work.

My memory of the next two days is something of a blur, but a few things stand out:

  • It's amazing how productive you can be when you dedicate yourself to a single job for two days. Another interesting experience was to work on requirements that don't change while you are processing them, albeit this is one of the major points where the Plat_Forms event failed to simulate reality.

  • I liked how we were able to reuse existing code for the CaP application. We have a fetish for packaging solutions to everything into reusable bits. Most parts of the Rails project we brought along mapped to a MUST requirement and we could use more than one pre-baked Modularity trait to implement functionality like the search query grammar.

  • We definitely could have spent a little less time on making stuff look shiny, but we're so used to combining programming and UI design that didn't want to change the way we operate for a two-days competition.

  • We didn’t like that a large part of the requirements was to basically implement the application a second time as a REST web service. The API was specified in a level of detail where no pre-baked API solution could be used. It was rather boring to spend hours mapping data from our model to the one specified, and no one can see the results.

  • A topic we had debated fiercely was whether or not two days would be enough time to amortise the expense of writing tests. We eventually decided to mostly write Cucumber features (high-level integration tests) and skip the lower-level RSpec examples except for cases where Cucumber felt awkward. Looking back I'd probably say that having tests didn't save or cost us a lot of time one way or the other. What I can say is that they allowed us to plow through the requirements at a constant pace rather than irregular burts. Tests also gave us the peace of mind to work on new features until minutes before the competition ended, without the fear of regression bugs. I'm curious whether test coverage will be part of the jury evaluation, since the organizers wrote that modifiability would be an aspect they are interested in.

The final moments of the contest were exciting in all the wrong ways. We had to package a preinstalled application server in a VMWare Server image and hand it over to the organizers before the deadline. And we almost missed that deadline because VMWare Server for Linux is a piece of shit and needs to die. We wasted hours before the contest to getting it to run and then it quit working an hour before the contest ended, complaining about unrecognized kernel modules (WTF!). Arne was able to save the day with some arcane Linux sorcery, but I’m never touching a VMWare product again.

In the end, we managed to complete all the must requirements and some should requirements. At least one other team seems to have completed significantly more of the optional requirements. I hope we will get the chance to look at their code, as we felt some of the requirements come with some tricky details.

After the event the teams and organizers met up at the Indabahn, which is nice mix of restaurant, lounge and dance club. There we had the chance to talk to the other participants after there had been literally zero time during the compo.

So was it worth it? Seeing that three people spent three days not earning money, plus preparation time and travel expenses, an event like Plat_Forms is quite an expensive undertaking for a small development shop like us. Nevertheless it was quite an experience and we’re looking forward to reading the results this fall. Our hope is that the Ruby teams will come out on top. If the results bring more attention to a rising technology like Rails, it was well worth the time and effort.

You can see some of our work at You will need to sign in to see most of the screens:

Screenshot of our CaP application

There are also a number of admin screens and the API, both of which you won’t see unless you are clever.


Fri, 29 Apr 2011 13:47:00 GMT

by henning

In which a tiny weekend project changes our company forever

It's been six months since we hacked together makandra notes and used it to open source our knowledge base. Since then we wrote about 600 notes and posted hundreds of helpful links. A large and thankful audience certainly fueled our enthusiasm to keep going. But even more important, makandra notes changed the way we operate.

What happened is that we don't need to ask anyone to document their findings anymore. Feeling the rush of riding on a wave of yesterday's solutions, everyone understands the value of packaging solutions and never solving the same problem a second time. Our developers do it, our student trainees do it, even our sales people post the occasional note. People I had to force to use our (awful!) Wiki last year are now kicking my ass for keeping a cool piece of code to myself. This is awesome.

We are currently working on a way that lets other teams use the software behind makandra notes, which has been the number one request since we launched the site last year. If you have any ideas for this, please let us know. We cannot promise anything, but we will appreciate and read every piece of feedback we get.


Wed, 16 Mar 2011 10:48:00 GMT

by henning

HTML5 audio is a ghetto

I recently had the opportunity to create a Who Wants To Be A Millionaire game with all the sounds and whistles from the original TV show. It was for the purpose of a birthday party, and grilling your buddy with questions from their teenage life in front of a huge crowd is one of the funnest activities you can have legally.

I had already started to lay out the game UI in Flash, when I remembered all the fancy new HTML 5 features I normally can't use because of any browser that is not Webkit. In this case however I had 100% control over which browser was going to be used (Chrome!). So I closed Flash and wrote the whole thing using HTML, CSS and Javascript. I had a lot of fun doing this (CSS3 is awesome!), but found HTML5's new support for audio to be severely lacking.

Modern browsers can load an MP3 or OGG for playback by using either an <audio src="http://url"> tag or instantiating a new Audio('http://url') in Javascript. Unfortunately there's no good place to find out which methods you can call on an Audio object. Right now the best source for information on HTML 5 audio is a couple of blog posts. This we can improve on, and I believe that the W3C style of documentation needs to go. Note that this is coming from a Ruby developer, and Ruby people couldn't document their way out of a paper bag.

You have no real control over when an audio file starts to load. When you create a new <audio> element? When you set the src on that element? When you append that element to the document tree? No one will tell you. Maybe no one knows.

For consistency, there's also no way to tell if a file has finished loading. There are three gazillion callbacks and not one will tell you when you can absolutely, positively play a sound.

The next few annoyances have more to do with Chrome's implementation than HTML5, but seeing that HTML5 is basically powered by Webkit right now, it matters.

When you move the playback position of an audio file, it produces a nasty popping sound in your speakers. From my limited understanding of audio engineering, this happens when you disrupt the sound wave at a point that is not a zero crossing. In Chrome this occurs regardless of whether the sound is playing or paused when the playhead is moved. This is super-annoying, especially since the only way to play a sample from the beginning is to pause it, set the position to zero, and hit play again. I only had to play a sample every few seconds for my quiz, but maybe you'd like to rethink using HTML5 audio for your upcoming Javascript shooter game.

Maybe the most annoying problem was that Chrome randomly refused to load some of the 40 sounds I was using for my game. It would give no error, the Audio object would simply play dead when attempting to play the sound. This happened undeterministically every 5th page load or so (and of course it happened during the performance ☺).

HTML5 is awesome, but I'll stick with Flash for audio for now.


Mon, 07 Feb 2011 23:35:00 GMT

by henning

We're going to Plat_Forms 2011

So we qualified for the 2011 Plat_Forms competition. Plat_Forms pitches 16 teams of programmers in 5 different technologies (Java, Perl, PHP, Ruby and Javascript) against each other in order to provide insight into the pros and cons of each platform. See the 2007 task and results (short or TLDR version) to get an idea of whats's going to await us.

All of us are very excited about the contest and hope that all of the Ruby teams will kick ass.

Good luck to all participating teams. See you in January!


Mon, 20 Dec 2010 20:07:00 GMT

by henning

In which we open source our knowledge base

We don't like to solve the same problem twice. That's why whenever we figure out something, we document it for the rest of the team. Over the last year we collected quite an amount of code snippets and HOWTOs this way.

This September we decided to take our in-house knowledge base and publish it for everyone to see. makandra notes contains some 200 HOWTOs and 500+ links for Ruby, Rails, RSpec, Cucumber and Javascript and is growing every day.

Whether you're looking to deliver Paperclip attachments securely, test concurrent Ruby code or marry Capybara with SSL-enabled applications, chances are we already solved your problem for you.

We hope that our notes will become a valuable resource for other developers working in our field. And if we could help you, or if you have an idea how to make makandra notes better, please let us know.

  • Henning said 8 months later:

    @Chris: Thank you for the encouragement :)

  • Tyler Durden said 10 months later:

    Is it possible to get the Software behind the notes for private use?

  • Henning said 10 months later:

    @Tyler: We might have something exciting in store for you. Please be patient a little while longer.


Mon, 27 Sep 2010 20:47:00 GMT

by henning


Fool me once, shame on you, fool me twice, shame on me!

In April, Apple banned the use of Adobe third-party tools for the development of iPhone apps. Developers and companies watched in terror how their investment in the iOS platform was declared illegal overnight, for no understandable reason other than that Apple said so.

This week Apple reverted that ban. If you are among those applauding the move, you might be suffering from a case of Stockholm Syndrome.

The next time Apple nullifies your development efforts in order to shut down a competitor, you cannot cry foul. This time you knew what you were getting into.

  • Christian Aust said 9 days later:

    Starting a business on the back of some other company’s products? Well, screwed you are. If Apple/Microsoft/Adobe/SAP/Oracle/… withdraw the basis of your revenues, it’s you who’s suffering. That’s the price for entering a huge ecosystem with considerably low investments.

    Flash is last millenium’s technology, no mater what. It’d be nice if it was on devices like the iPhone, but admit it: It really sucks. Big time. What’s wrong with a decision which aims at protecting the overall quality of a product?


Sat, 11 Sep 2010 07:19:00 GMT

by henning