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.
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.
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.
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 :)).
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.
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 platforms.makandra.com. You will need to sign in to see most of the screens:
There are also a number of admin screens and the API, both of which you wonâ€™t see unless you are clever.
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.
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.
Modern browsers can load an MP3 or OGG for playback by using either an
<audio src="http://url"> tag or instantiating a
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.
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.
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!
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.
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.
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.
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.