Author: Daniel Havlik

(We are addressing a local audience near our offices so we are keeping this post in German. Sorry. Basically we want developers and admins in our area to meet up, exchange ideas, and enjoy BBQ and beer.)

Last week I met Stephan Diehl, Michael Hierweck, Veit Schiele, and Jens Vagelpohl in Berlin for a sprint. Our chosen topic was “Python web application deployment”. In this post I’d like to recap our discussions, gocept’s perspective on those, and the deployment tool “batou” that we have been incubating in the last months.

The Python BarCamp Cologne 2012 happened last weekend. It was well organized by Reimar Bauer and the Cyrus office space is just very well suited for this kind of event: lots of space, rooms, equipment, drinks, …

My most favorite discovery was Sentry – an open-source exception logging tool that has a nice UI and is simple to set up. Kudos to the Disqus crew! I’m looking forward to making this available as a managed component in gocept.net as soon as I get time to do so. 🙂

Other interesting topics that I joined were: a discussion about WSGI servers, parallelization, template engines, debugging and the infamous lightning talks.

Obviously I couldn’t restrain myself and so I offered a session on service deployment trying to answer some questions that people had and presenting some of the code we wrote when extracting our knowledge into batou.

Another session that I tried to foster was about #failure: in addition to talking about the cool things that we found working I wanted to hear about stuff that doesn’t work: software, organisational issues, etc. We kind of got stuck on bashing anything with the label “Enterprise” and the standard library.

On enterprise: the most weird experience I had lately boils down to this video by RedHat about their JBoss offering – say what?

The stdlib bashing wasn’t aggressive at all: we found some specific quirks and tried to get some understanding why things are the way they are. For me, basically, the standard library is what comes out of “batteries included” – it will have something in there that helps you out accomplishing what you want (like a pack of AA batteries) but if you’re serious about it you might need to roll some different module (like a car battery). I don’t think dropping the standard library would be a wise choice and I also don’t think that “one size fits all”.

I also got a surprising invite to presenting at the GUUG meeting next year and I’m pretty excited about that!

So, thanks again to Reimar and the other people organizing and sponsoring this event!

We recently had an issue with our backup server which was also running Nagios including pnp4nagios to gather performance data.

We quickly started to deploy a new Nagios server which started gathering statistics again right away.

After pulling the historical RRD databases from the backup we discovered no easy way to integrate the both datasets. After fiddling with some tools we extended an existing script that can be used to integrate different RRD sources into a single file to match our use case.

The resulting script simply replaces all “null” data rows in the new database that the old database has data available for. A second script provides the ability to merge whole directory trees of RRDs.

I fiddled a bit for making my VIM tell me when obvious (statically detectable) mistakes sit in my code when saving. This speeds up the testing process a bit when e.g. syntax errors exist and helps me adhere to PEP 8.

We were embedding a spinner to give user feedback while loading data from a server which might take a little longer (but can also be pretty quick in most cases).

Implementing the spinner itself isn’t that hard, but we found that quick responses from the server caused visual artifacts flickering up because the spinner was only visible for a few milliseconds (probably roughly 30ms).