The Log Book of Manuel Kiessling

The following roots in something I heard from Jon Jagger at QCon London 2011 after his fantastic talk about Deliberate Practice. It was related to Test Driven Development. He asked “Why do cars have brakes?”. It made us think “To stop!”, but he said “No – to go faster”.

(Jon points out he didn’t invent it, he heard it from Kevlin Henney).

I have been thinking about this ever since, and here is what I came up with.

Imagine I would give you the keys to my car. I would tell you “here are the keys, you can drive wherever you want, including the highway, have fun!”

How fast would go? My car is not exactly a sports car, but it can do around 200 km/h. I guess we both agree that you would drive around 50 km/h within cities (the maximum allowed in Germany), and probably up to 200 km/h on the highway, as long as there is no limit.

Fine. Now image this: I would give you the keys to my car. I would tell you “here are the keys, you can drive wherever you want, including the highway, have fun! Oh, just one thing, the brakes don’t work.”

Now let’s forget for a moment that in reality, you probably wouldn’t start at all, if you had to drive, then how fast would you go? 10 km/h, maybe 20? Driving extremely cautious, always trying to look as far ahead as possible if you are going to need to halt? Yeah, I thought so.

But why is that? The brakes don’t have anything to do with the speed of my car – it’s still capable of doing 200 km/h just fine!

It’s because the ability to stop is what enables you to go real fast. With only a bit of exaggaration you could say that having a brake allows for a very “iterative” way of driving – no cars within the next 300 meters, let’s accelerate a bit – oh, there’s a car coming over from the right, let’s brake a bit – ok, now I can accelerate again – ah, there is a signal that suddenly turned red, no problem, I will stop here.

For me, this metaphor is the best I could find by now to explain to myself (and in the future, to others), why I really want to develop test-driven, and why it actually makes me faster, not slower, although I’m doing more.

Just as the brake doesn’t directly influence your driving speed, but does so indirectly, your tests won’t influence your coding speed directly, but indirectly. It’s because once they are in place, they allow you to iterate over your code and refactor it at what I, from my own experience, can only describe as the speed of light compared to conventional programming.

With tests in place, it’s like: Mh, what if I would split this rather long method into two? – ok, works; What if I put a bit more of dependency injection into this class? – ah, now this test here fails, no problem, I will have it back to green within minutes, I know exactly where to go to fix this; Hey, I could give this method here a better name – ok, still green; There’s this performance bottleneck deep inside this one class that is heavily used by a lot of other classes, let’s see if I can fix this – my tests will tell me if I accidently changed behaviour.

Compare this to conventional programming: You will never know for sure what breaks somewhere else if you change something. If you want to find out, you need huge amounts of manpower to have your webpage or UI tested for regression. What really happens is that you slow down to a near halt: because you don’t know what’s around the next corner when developing, and you know there is nothing that will immediately stop you and save you from harm if you take that next corner, you will drive, err, code so cautious, you won’t make any real progress.

On which Jon commented: “Yes. As the pragmatic programmers say, paraphrasing – you don’t know why it’s broken because you didn’t know why it worked in the first place.”

I’m really into visualizations. More often then not I can only really “get” something (a complex system, an abstract idea, a process etc.) when I see it visualized. You could call this the transformation of gut feelings into images.

So, I had this (rather obvious) gut feeling that working iterative in software projects makes a lot of sense, I’ve heard all the arguments and explanations and examples and stuff like that, and I probably already “got it”, but I thought it could make sense to clearly work out why exactly it makes sense, by visualizing it. Surely it’s no rocket surgery what happens here, but I kind of like it and would like to share it.

So here’s my approach:

The customer tells a product manager what he wants him to build. Let’s see how a waterfall approach leads to the product team failing at this:

The reason why what is finally delivered isn’t what the customer expected is that the project goes through the hands of different people and different stages, and every time the project is given to another person or team, the amount of misunderstanding grows. That’s only natural because we cannot copy ideas from one brain to another in a 1:1 manner.

Here is why an iterative approach makes sense:


The project really starts the same: There is a certain amount of misunderstanding, and the team does things wrong. But due to the regular feedback from the customer, this wrong direction can be corrected. It might then move into another direction which is still a bit wrong, but then comes the next correction, and finally everything is on track.

Platform Health Viewer (kurz PHV) ist mein aktuelles Ruby on Rails Hobbyprojekt.

Sobald es einen stabilen Zustand erreicht, wird dieses Tool das Sammeln und Visualisieren verschiedener statistischer Daten, wie sie typischerweise von Internetplattformen erzeugt werden, schnell und leichtgewichtig ermöglichen. Beispiele für diese Daten sind Dinge wie die CPU Last einzelner Systeme, Benutzerlogins, Anzahl der Seitenaufrufe usw.

Die Applikation basiert in erster Linie auf Rails, der HTTP Server für die Datenanlieferung ist in node.js geschrieben, die Weboberfläche nutzt sehr ausgiebig jQuery und für die Erzeugung von SVG Graphen die Raphaël Bibliothek. Massendaten werden in SQL gespeichert, weitere Daten liegen in einer CouchDB.

Der Projektcode ist auf Github abrufbar unter https://github.com/ManuelKiessling/PlatformHealthViewer.

Das folgende Video ist eine kurze Einführung zur aktuellen Alphaversion des Projekts. Es enthält außerdem eine lustige Sprecherstimme und eine sehr kreative Interpretation der englischen Grammatik.

Im Folgenden das ins Deutsche übersetzte Transskript des Videos:

Hi. Platform Health Viewer – oder PHV – ist mein aktuellen Hobbyprojekt.

Ich brauche eine einfache und leichtgewichtige Möglichkeit, die verschiedenen Kennzahlen der Webseite, für die ich verantwortlich bin, zu sammeln und zu visualisieren. Sachen wie die CPU Perfomance wichtiger Systeme, Userlogins, HTTP Anfragen.

Deshalb habe ich angefangen mit Ruby on Rails, jQuery, CouchDB und node.js zu experimentieren, und hier ist eine frühe Alphaversion, die ich demonstrieren möchte.

Mein Hauptziel ist es, den Prozess von der Einspeisung der Daten in das System bis hin zu ihrer grafischen Visualisierung so einfach wie möglich zu gestalten.

Um Daten in das System zu bekommen, benötigt man lediglich einen HTTP Aufruf, was es sehr einfach macht, die Daten der unterschiedlichsten Quellen zu sammeln.

Probieren wir ein Beispiel aus. I möchte die CPU Performance meiner lokalen Maschine visualisieren.

Ich werde diese Daten bekommen, indem ich einen Standard Unix Befehl verwende: sar.

Dies ist ein wichtiger Aspekt meines Ansatzes: Für den Platform Health Viewer spielt es überhaupt keine Rolle, woher die Daten stammen – man ist bei den Mitteln der Datenbeschafung völlig frei. Dadurch kann man wirklich alles in das System übermitteln, angefangen bei allgemeinen Daten wie der CPU Last bis hin zu äußerst individuellen Sachen wir den Logins auf der eigenen Webseite.

Ok, so bekomme ich den CPU “usr” Wert auf meiner OS X Kommandozeile:

sar 1 1| grep Average| cut -b 14-15

Fein, das wird’s tun.

Wie liefern wir diese Werte in das System? Es reicht ein simpler HTTP Post Aufruf mithilfe von curl:

curl –data “event[value]=`sar 1 1| grep Average| cut -b 14-15`&event[source]=macbook&event[name]=cpu_usr_percentage” http://localhost:3000/queue_event

Wie man sieht, die Nutzdaten des Aufrufs bestehen aus lediglich drei Parametern: Der Quelle des Events, dem Namen des Events, und seinem Wert.

Noch mal: Man ist an dieser Stelle komplett flexibel, man ist nicht gezwungen Eventnamen und -quellen zuvor im PHV zu konfigurieren – man definiert diese einfach im Moment der Dateneinlieferung, das das System akzeptiert diese. Wir werden gleich sehen, wie man mit den verschiedenen Events, die in das System geschrieben werden, sinnvoll umgeht.

Ok, ich verwende jetzt ein kleines Hilfsskript das ich geschrieben habe, um die CPU sys, idle, usr und nice Werte in das System zu liefern:

cat script/agents/macosx/cpu_overview_percent.sh

Wie man sieht, geschieht alles unter der Verwendung normaler Unixbefehle.

Starten wir also das Skript:

bash ./script/agents/macosx/cpu_overview_percent.sh http://localhost:3000/ macbook

Ich übergebe hier nur zwei Parameter, die URL zum Platform Health Viewer (der für diese Demonstration auf demselben Host läuft), und den Namen meiner Eventquelle, die ich “macbook” nenne. Eventnamen und -werten kommen direkt aus dem Hilfsskript.

Man sieht, wie das Skript alle vier CPU Kennzahlen in das System liefert. Schauen wir uns diese Daten innerhalb des Platform Health Viewer an.

Nun, das Dashboard ist nach wie vor leer, da wir noch keinerlei Visualisierungen definiert haben. Aber der “Tageditor” zeigt ebenfalls noch keinerlei Events an. Das liegt daran, dass die in das System eingelieferten Events noch nicht zu sogenannten Eventtypen normalisiert wurden.

Dies ist bewusst ein zusätzlicher Schrit, denn es erlaubt dem System, eingehende Events so schnell wie möglich in die Datenbank speichern zu können, ohne sie in Hinblick auf Name und Quelle normalisieren zu müssen. Diese Normalisierung erledigt ein Rake Task:

rake queue:convert

Dieser Task liest die Events aus der Anlieferungs-Queue, erzeugt bei Bedarf neue Eventtypen, oder verbindet die Events mit bereits existierenden Eventtypen, falls diese bereits existieren. Abschliessend wird die Anlieferungsqueue geleert.

Zurück im Tageditor, können wir die vier Eventtypen nun sehen.

Ein Eventtyp ist die Kombination einer Eventquelle und eines Eventnamen, also ist “macbook – cpu_idle_percentage” ein Eventtyp.

Schauen wir nun, wie wir den Tageditor verwenden können um etwas sinnvolles zu basteln. Das Gruppieren von einem oder mehreren Eventtypen unter einem Tag macht unsere eingelieferten Daten visualisierbar. Ich bin übrigens nicht ganz glücklich mit dem Begriff “Tag”, vielleicht fällt mir da noch etwas besseres ein.

Wie auch immer, erzeugen wir nun einen einfachen Tag den wir benutzen können, um genau einen Wert zu visualisieren.

Ich werde diesen Tag “macbook_cpu_usr” nennen. In diesen laufen dann alle Events, deren Quelle “macbook” und deren Name “cpu_usr_percentage” lautet. Ich könnte diese Parameter auch in die Textbox eintippen, aber es ist einfacher sie schlicht per Drag&Drop in das Formular zu ziehen.

Ok, fügen wir diesen Tag also hinzu.

Wir haben nun also einen ersten Tag, und um zu sehen, ob er wie erwartet funktioniert, kann ich die Werte der zugeordneten Events in einer Vorschau kontrollieren.

Liefern wir jetzt ein paar weitere Werte in das System und schauen, ob sie dann hier angezeigt werden.

Ok, ich starte also mein Hilfsskript erneut um neue Werte in den Server zu liefern, und starte dann wiederum den Rake Task um die Werte zu normalisieren.

Ein erneuter Klick auf “Show latest events” zeigt diese neuen Werte nun an.

Ich starte die Datenanlieferung jetzt in einer Schleife, um viele Werte zu erhalten.

Ok, wir haben nach wie vor keine Datenvisualisierung, also gehen wir das jetzt an. Ich wechsle in’s Dashboard und füge einen Frame hinzu, dies ist ein Container der unsere Graphen enthalten wird.

Ein Frame ist die Visualisierung aller Werte die mit einem Tag verbunden sind, also muss ich den Namen des Tags angeben, das ich mit diesem Frame visualisieren möchte.

“Add frame”, und los geht’s. Ein einfacher Liniengraph, der einen meiner CPU Werte repräsentiert. Der Graph ist im Übrigen ein SVG, erzeugt mit Raphael, einer fantastischen JavaScript Bibliothek.

Und dank jQuery kann ich diesen Graphen frei bewegen und skalieren.

Erzeugen wir nun einen Graphen für alle meine CPU Werte. Zurück im Tageditor ziehe ich nun alle meine Eventtypen zusammen.

Ich kann übrigens Tags erzeugen, indem ich Eventquellen und -namen mit bereits existierenden Tags kombiniere, wie man hier sieht.

Ich überprüfe alle Werte die meinem neuen Tag zugeordnet sind, und dort sieht man alle CPU Werte, die mein Skript gesammelt hat.

Wieder zurück im Dashboard gehe ich her und erzeuge einen weiteren Frame, für meinen neuen Tag. Wie man sieht, enthält dieser Frame vier Liniengraphen und zeigt mir so eine hübsche Übersicht meiner kompletten CPU Performance. Natürlich wird hier eine Legende benötigt, etwas das bisher noch nicht implementiert ist.

Nun, das ist es, das ist der aktuelle Stand des Projekts. Ich würde mich sehr über Feedback freuen, der Code kann auf Github geforkt werden oder schreibt mir eine Mail.

Danke für’s Interesse.

Platform Health Viewer is my current Ruby on Rails pet project.

Once stable, it will allow users to easily collect and visualize different types of statistical data which is typically produced by internet platforms, like CPU performance, user logins, HTTP requests etc.

The main application is build on Rails, the server used for data collection is written in node.js, the web interface makes heavy use of jQuery and uses Raphaël to create SVG graphs. Mass data is saved in a SQL db, other data is stored using CouchDB.

The project’s code is hosted on Github at https://github.com/ManuelKiessling/PlatformHealthViewer.

This video is a short introduction to the current alpha version of the project. A funny voice and lots of grammatical shortcomings are included for free:

Transcription of the video:

Hi. Platform Health Viewer – or PHV – is my current pet project.

I need an easy and lightweight way to collect and visualize the different key performance indicators of the web platform I’m responsible for – stuff like CPU performance of important systems, user logins, http requests.

So I started to play around with Ruby on Rails, jQuery, CouchDB and node.js, and here is an early alpha I would like to demonstrate.

My primary goal was to make the process from feeding data into the system to visualizing that data as simple as possible.

In order to get data into the system, all you need to make is an HTTP call, which makes it very easy to collect data from very different sources.

Let’s try an example. I would like to visualize the cpu usage of my local machine.

I’m going to collect this data using a standard unix command, sar.

That’s an important aspect of my approach: It doesn’t play any role for the Platform Health Viewer where the data comes from, you’re completely free to choose how to collect it. This way you can feed really anything into the system, from generic data like CPU load to highly individual stuff like the user logins of your specific web site.

Ok, here is how I can get my cpu “usr” value on my OS X command line:

sar 1 1| grep Average| cut -b 14-15

Great, that will do.

How do we push these values into the system? It’s a simple http post request using curl:

curl –data “event[value]=`sar 1 1| grep Average| cut -b 14-15`&event[source]=macbook&event[name]=cpu_usr_percentage” http://localhost:3000/queue_event

As you can see, the payload of the post requests is just 3 parameters: the source of the event, the name of the event, and its value.

Again, you’re completely free here, you don’t need to configure event names and sources inside PHV – just define them when pushing data into the system, it will happily accept it. We will see in a moment how to make sense of different events that were pushed into the system.

Ok, let’s use a small helper script I wrote in order to feed the CPU sys, idle, usr and nice values into my system:

cat script/agents/macosx/cpu_overview_percent.sh

As you can see, this is all done using only standard unix commands.

Let’s start the script:

bash ./script/agents/macosx/cpu_overview_percent.sh http://localhost:3000/ macbook

I’m just providing two parameters here, the URL to my platform health viewer installation, which resides on the same host for this demo, and the source name, which I call “macbook”.

As you can see, my script pushes all four CPU usage values into the system. Now let’s have a look at this data within platform health viewer.

Well, the Dashboard is still empty, because we did not yet define any visualizations. But the “Tageditor” doesn’t show any events, too. This is because the events I pushed into the system have not yet been normalized to event-types.

This is an additional step, because it will allow the system to push incoming events into the database as quickly as possible without the need to normalize those events regarding their name and source. This normalization is done using a rake task:

rake queue:convert

This task reads the events from the incoming queue, creates new event-types as needed, or connects the event values with existing event types if they already exists. It then deletes the incoming queue.

Getting back to our tageditor, we can now see our 4 event types.

An event type is the combination of an event source and an event name, so “macbook – cpu_idle_percentage” is one event type.

Let’s see how we can use the tag editor to create something useful. Grouping one or more event types into a tag is what makes our data suitable for visualization. I’m not quite happy with the term “tag” by the way, maybe I will come up with something better.

Anyway, let’s create a very simple tag which we can use to visualize exactly one value.

I’m going to name my tag “macbook_cpu_usr”. It will hold all events whose source matches “macbook”, and whose name matches “cpu_usr_percentage”. I could type those parameters into the text box, but it’s easier to just drag’n'drop them there.

Ok, let’s add this tag.

Now we have this first tag, and to check if it works as expected, I can preview the values of the matching events.

Let’s push some new values into our system and check if they are visible here.

Ok, I’m starting my helper skript again in order to post new values to the server, and I start my rake task in order to normalize these values.

Clicking again on “Show latest events” now shows these values.

I will now start data push and normalization in a loop in order to get a lot of values.

Ok, we still have no data visualization, so let’s do this now. Let’s switch to the Dashboard and add a frame, which is a container that will hold our graph.

A frame is the visualization of all values connected to a tag, so I need to provide the name of the tag I want to visualize with this frame.

“Add frame”, and here we go. A simple line graph representing one of my CPU values. The graph is actually an SVG, created using Raphael, an awesome JavaScript library.

And thanks to jQuery, I can freely move and resize the graph.

Let’s create a graph with all my CPU values in it. Back to the Tageditor, I’m going to drag all my values together.

I can also create tags by combining event-sources and -names with already existing tags, as you can see here.

Let’s check the values of my new tag, and there are all the different CPU values my script collects.

Back to the Dashboard, I’m going to create another frame for my new tag. As you can see, this one contains 4 linegraphs and gives me a nice overview of my system’s CPU performance. Of course, a graph legend is needed, something that’s not yet implemented.

Well, that’s it, that’s the current state of this project, I would love to hear your feedback, you can fork the code on github and drop me an e-mail.

Thanks for your interest.

Ich hatte tatsächlich einmal eine ganz eigene Idee. Und sie war gut, auch nachdem ich sie mehrmals durchgekaut und von allen Seiten beleuchtet hatte.

Wieso eigentlich sollte man die Prinzipien und Methodiken von testgetriebener Softwareentwicklung nicht auch auf den Bereich der IT-Systemadministration übertragen? Also in aller Kürze: Ich definiere Tests, die das vom noch zu implementierenden System erwartete Verhalten prüfen, sehe zu wie diese Tests fehlschlagen, und erfülle dann schrittweise diese Tests, indem ich das System aufbaue. Test driven administration – TDA.

Da war ich ganz alleine drauf gekommen, und ich war sehr stolz.

Dann habe ich gegoogelt. Die Idee existiert seit mindestens 2006.

Aber hey, gut ist die Idee trotzdem, also beschreibe ich sie hier.

Warum möchte man testgetrieben administrieren? Die Gründe sind dieselben wie bei testgetriebener Entwicklung: Habe ich Tests, bin ich gegen Regression geschützt, d.h. ändert ein Stück Code / ein System sein Verhalten aufgrund von Änderungen, weisen mich die Tests darauf hin.

Gehe ich testgetrieben vor, sind die Tests nicht irgendwas, das ich ganz unbedingt machen sollte, das aber doch am Ende runterfällt, sondern sie sind garantiert vorhanden. Mit den bekannten angenehmen Begleiterscheinungen, dass die Tests einen zwingen, sich Gedanken darüber zu machen, wie das Ziel eigentlich beschaffen sein soll, und automatisch dazu führen, die Lösung schlank und elegant umzusetzen.

Code und IT-Systeme sind aber nicht dasselbe, wie würde man also in der Praxis konkret vorgehen? Hier mein Vorschlag.

Zuerst benötigt man ein Testwerkzeug. Um in der Softwareentwicklung Unittests zu bauen, benutzt man Tools aus der xUnit Familie wie JUnit oder phpUnit. Das Äquivalent zu diesen Tools in der Systemadministration sind Monitoringsysteme wie Nagios oder Zabbix.

In der Softwareentwicklung formuliert man Unittest so, dass man eine kleine Einheit des Gesamtsystems, also in der Regel die einzelnen Methoden einer Klasse, mit einer gewissen Erwartungshaltung (“wenn ich diese Parameter reingebe, erwarte ich jenen Rückgabewert”) aufruft, und dann die erwartete Rückgabe mit der tatsächlichen vergleicht.

Was wäre dementsprechend “erwartetes Verhalten” bei einem IT-System? Nehmen wir an, die Anforderungen lauten wie folgt:

Benötigt wird ein Linux-System, welches unter der IP 123.456.789.000 einen Webserver bereitstellt, und die Festplattengröße des Systems soll 100 GB betragen.

In der Realität wären die Anforderungen natürlich umfangreicher, aber ich halte das Beispiel einfach.

Aus den Anforderungen lässt sich das gewünschte Verhalten ableiten:

• Bei einem Ping auf 123.456.789.000 muss eine Antwort erfolgen
• Die Abfrage des Betriebssystems unter dieser IP muss “Linux” ergeben
• Ein HTTP Request gegen diese IP unter Port 80 muss eine HTTP Antwort zur Folge haben
• Bei der Abfrage der Festplattengröße muss ein Wert von 100 GB zurückgeliefert werden

Daraus wiederum kann man im Monitoringsystem Tests formulieren. Diese lässt man einmalig laufen, um zu verifizieren, dass sie tatsächlich fehlschlagen. Und dann beginnt man damit, ein System aufzusetzen, das die Testbedingungen erfüllt, bis schliesslich alle Tests “grün” sind.

Das ist der Kern der Idee. Im weiteren Verlauf überwacht man die Tests regelmäßig (was man mit einem Monitoringsystem ja eh tut), und hat damit das Thema Continuous Integration gleich mit erschlagen. Ansonsten geht man genauso wie auch beim TDD vor: Möchte man Änderungen an einem System vornehmen, passt man zuerst die Tests an, verifiziert dass sie fehlschlagen, und ändert dann das System, um die Tests wieder zu erfüllen.