Points of Interest

Wenn Herr Maierrings dreimal klingelt…

ce — Tue, 17 Jan 2012 22:23:12 +0000

TV-Testscreen (opebnclipart.org, Public Domain)

Teile meiner Familie haben bereits vor rund dreißig Jahren ihre Rundfunkgeräte entsorgt – damals wahrscheinlich noch ein recht ungewöhnlicher Schritt. In meinem Freundes- und Bekanntenkreis sind jedoch heute Haushalte ohne (Fernseh)empfangsgerät nichts Ungewöhnliches. Das Fernsehen ist sicher nicht per se verkehrt, kann es aber nunmal als Massenmedium nicht allen Recht machen. Ob die gebotene Leistung 210€ pro Jahr wert ist muss jeder mit sich selbst ausmachen.

Zugegebenermaßen bin ich ein großer Freund des Deutschlandfunks. Dass zum Angebot ein Ogg-Vorbis-Datenstrom gehört, so dass man sich bei Bedarf interessante Beiträge gleich digital mitschneiden kann, ist ein feiner Service. Nicht dass ich davon Gebrauch gemacht hätte – aber ich könnte, wenn ich denn wollte :) .

Mein Versorger ist bemüht. Regelmäßig schaut Herr Maierrings persönlich vorbei. Wenn er gerade keine Zeit hat, schreibt man mir, damit ich was zu lesen habe. Die Schreiben sind anspruchsvoll gestaltet und die Wortwahl bietet einen hohen Unterhaltungswert – man sieht gleich, dass man es mit Profis zu tun hat :) .

Leider waren die jüngeren Schreiben deutlich langweiliger. Mir kam auch zu Ohren, dass Herr Maierrings vielleicht bald nicht mehr so oft vorbeikommen könne. Ob das mit der kommenden Haushaltsabgabe zu tun haben kann?

Ab nächstem Jahr gilt eine haushaltsbezogene Abgabe – IMO ein überfälliger Schritt, der grundsätzlich zu begrüßen ist.

Einige Mitbürger werden jedoch hart getroffen. Komplettverweigerer etwa zahlen plötzlich für eine Leistung, die sie überhaupt nicht in Anspruch nehmen, einen nicht unbedeutenden Betrag. Und da heutzutage ein Rechner mit Internetzugang zur kommunikationstechnischen Grundausstattung gehört, wird es keine Ausnahmeregelungen geben.

Auch Radiofans müssen eine Preissteigerung von etwa 312 % verkraften. Da die Gebühr für Fernsehgeräte gleich bleibt, stellt sich die Frage, wer die geplante Entlastung für (beispielsweise) Handwerksbetriebe erbringen wird. Überspitzt ausgedrückt zahle ich tagsüber dem Handwerker sein Hitradio auf der Baustelle und bekomme dafür nachts um 0:30 Uhr einen Livemitschnitt vom Münchner Klaviersommer geboten. »Das ist einfach ungerecht« :) .

Cool wäre, wenn

politische Einflussnahme zuverlässig ausgeschlossen würde.
der Teilnahmebeitrag 100€ pro Jahr nicht überstiege.
die öffentlich-rechtlichen Sender komplett auf Werbung bzw. eine Beteiligung an werbefinanzierten Sendern verzichteten.
die Anbieter Qualität statt Quantität lieferten.
das Radio- und Fernsehangebot über IP-Netze zuverlässig zu empfangen wäre.
die von den Teilnehmern finanzierten Beiträge dauerhaft in einem öffentlich zugänglichen Archiv zum Herunterladen bereitstünden.
ausschließlich unverschlüsselte und möglichst lizenzfrei zu nutzende Dateiformate Verwendung fänden.
…

Stimmt. Das geht alles nicht. Ich nahm mir ausnahmsweise heraus, eine völlig unrealistische Vision zu skizzieren :) .

Die Haushaltsabgebe ist in Ordnung. Das Verhältnis aus Preis und Leistung ist es nicht.

Kommunikationsmittel, Konvention, Präzision und Ästhetik

ce — Tue, 17 Jan 2012 00:02:46 +0000

This posting about means of communication, accuracy, and aesthetics, appears in german language only due to german language references. International readers, I apologize.

Kommunikationsmittel

Die Sprache, die Schrift, eine technische Zeichnung oder ein Blatt Noten sind »Kommunikationsmittel[…], mit deren Hilfe sich Menschen untereinander verständigen können.«. Ein Architekt vermittelt mit einer Zeichnung anderen, wie das geplante Gebäude aussehen soll, während ein Komponist durch Noten ausdrückt, welches Musikstück sich in seiner Vorstellung entwickelt hat. Damit das Ganze funktioniert, bedarf es einer Konvention – beide müssen “die gleiche Sprache” sprechen.

Interpretationsspielräume in der Kommunikation

Trotz der Konvention gibt es Interpretationsspielräume durch Unschärfen im Kommunikationsmedium. Ein Notenblatt beispielsweise kann weder Tonhöhen noch Rhythmus beliebig fein auflösen. Kommunikation enthält außerdem auch unbewusste Komponenten, die vom Empfänger in seiner Vorstellung in einen entsprechenden Kontext gesetzt werden. Speziell in der schriftlichen Kommunikation kann man zudem gelegentlich feststellen, dass der eine sich präziser artikulieren kann und dabei auch Wert auf ästhetische Gesichtspunkte legt, während der andere wesentlich pragmatischer zu Werke geht. Wer ein Bild malt wird bezüglich der Ästhetik andere Maßstäbe anlegen als jemand, der eine Einkaufsliste verfasst.

Was aber hat das mit agiler Softwareentwicklung zu tun?!?

Code ist ein Kommunikationsmittel

Wie eine technische Zeichnung ist ein Stück Code in der Softwareentwicklung auch die Repräsentation der Gedanken desjenigen, der ein bestimmtes Problem lösen möchte. Mit dem Code, den er schreibt, teilt er nicht nur der Maschine, sondern auch seiner Nachwelt mit, was er dabei erreichen wollte – der Code ist also ein Kommunikationsmittel. Die Wahrscheinlichkeit, dass später entweder der Autor selbst oder ein anderer Fehler beheben, Verbesserungen oder gar neue Funktionalität hinzufügen möchte, ist groß. Sofern der Code bestimmten Konventionen folgt, präzise formuliert und gut strukturiert ist, wird es in einem halben Jahr deutlich einfacher sein, die dann anstehenden Änderungen vorzunehmen.

Wer agile Softwareentwicklung als Profession betreibt wird vielleicht sogar auf testgetriebene Entwicklung setzen, in der die Tests zum Ausdruck bringen, welches Bild der Programmierer beim Schreiben des Codes im Kopf hatte.

Der Softwarearchäologe

Boris Gloger hat vorgestern in seinem Posting Agile Architektur ist änderbar! das Problem beschrieben und ein paar nette Metaphern genutzt. Das Verstehen und effiziente Ändern von Code, den man nicht selbst geschrieben hat, ist für alle Mitglieder eines ScrumTeams ein wichtiger Baustein zum Erfolg.

Boris schreibt:

Lesbarkeit: Der Code sollte so strukturiert und geschrieben sein, dass er leicht verständlich und lesbar ist.

Eigentlich sollte das eine Selbstverständlichkeit sein. Allerdings erfordert das Disziplin. Es ist einfach, Code zu schreiben, der etwas Nützliches tut. Es ist aber aufwändiger ihn so zu schreiben, dass die Gedankengänge auch später noch nachvollziehbar sind – sei es für den Autoren selbst oder für andere. Und nicht zuletzt spart lesbarer Code, der in »Usable Software« mündet, eine Menge Dokumentationsarbeit ein.

Doch halt – was ist mit Kommentaren? Boris schreibt weiter:

Inline-Dokumentation der Entscheidungen: Es sollte im Code erklärt sein, warum gewisse Entscheidungen so getroffen wurden, wie sie getroffen wurden. Der Code selbst ist ja die Dokumentation dessen, was der Code macht. Nur wieso man die Dinge so angegangen ist, wie sie vorliegen, wäre wichtig zu wissen.

Kommentare sollten nur dort zum Einsatz kommen, wo der Code nicht mehr selbsterklärend geschrieben werden kann. Beispielsweise weil man um eine Unzulänglichkeit des Betriebssystemes (»Was macht er denn da?!?«) herumkommen musste.

Kommentare wie
// Traversing the list for ( int i = 0; i < lst.size(); i++ )
oder
// Checking whether we can open the file if ( !f.open() )
sollten gelöscht, dafür die Bezeichner etwas sprechender gewählt werden.

Vor ein paar Tagen habe ich eine Codestelle geändert. Gestern bemerkte ich, dass ich vergessen hatte, den darüberstehenden Kommentar zu ändern. Den Bug habe ich gefixt. Indem ich den Code so umgeschrieben habe, dass der Kommentar überflüssig wurde.

Interlude

Goke hält mit ausgestreckten Armen ein iPad so vor sich, dass er die Noten gut lesen kann. Mit spitzen Lippen pfeift er die Melodie. Nach wenigen Sekunden stimmt Peek mit ein.

Schlussfolgerung

Jedes Mitglied eines ScrumTeams, das vom Erfolgsfaktor der kollektiven Codeverantwortlichkeit in der agilen Softwareentwicklung überzeugt ist, wird darauf drängen, dass der Code als Kommunikationsmittel lesbar geschrieben wird. Jeder kann damit aus dem Stand gleich morgen anfangen. Wichtig ist nämlich nicht das Wollen, sondern das Tun in kleinen Schritten.

Wenn sich später noch die Lektüre von Büchern wie Agile Developer Skills (ISBN 3868020608) von Christoph Mathis und Andreas Wintersteiger oder Clean Code (ISBN 3826655486) von Robert C. Martin anschließt - umso besser.

Since MoNav learned to speak

ce — Fri, 06 Jan 2012 01:15:26 +0000

About two weeks ago I blogged about my first attempts to teach MoNav to provide speech output. While everything worked well on my desktop machines, MoNav did tend to crash every now and then on the N900, rendering it pretty useless for the intended use.

As debugging was a bit difficult, I have just rewritten a suspicious part of the code. Et voilà, a test drive through the city of Karlsruhe the past evening was of great joy and pleasure.

The speech output still is not mass compliant, though. MoNav is too verbose, instructions are spoken too late, and MoNav needs too long to detect that the vehicle left the precomputed route. But that’s just tedious work in progress to be done during the next weeks and months.

And though I’m complaining, do not forget that MoNav in its current state actually is capable to guide you to your destination, while I’m pleased with what I achieved during the past weeks.

I’ll continue the work on speech output for car drivers before I’ll dive into making it compliant with the needs of cyclists.

In case you want to play with the current code, you’ll need to compile the branch from source:



hg clone https://code.google.com/p/monav/ monav-permaroute
cd monav-permaroute
hg update permaroute
qmake monavclient.pro
(/Developer/QtSDK/Desktop/Qt/474/gcc/bin/qmake monavclient.pro on Mac OS X)
make

You’ll also need updated map packages for this version to run properly. I’ve already precomputed some mapsets:
Germany_big
Germany
Alsace
Rheinland-pfalz
Baden-Wuerttemberg

The above lines are not intended for end users. It’s for all those openstreetmap addicts who are interested to follow the current development of MoNav.

Have fun!

Recently, as Maths made my Xmas Break

ce — Tue, 03 Jan 2012 01:58:34 +0000

In the last posting I mentioned that I made the routes in MoNav more persistent:

As a consequence, I’ve just written some code that detects whether the vehicle is still “on track”. The route only gets recalculated in case the vehicle left it for more than x meters. This makes the route much more persistent and will cause far less headache than the previous approach.

Since the GPS position is always a bit inaccurate, it will almost never be exactly on the computed route. Instead, it will aberrate a bit from it. What you want to achieve is to detect whether the current position still is either near the route, e.g. left or right of it, no more than x meters away and still in direction to the planned target, or in the opposite direction.

First the computed route:

This hardcopy shows a small deviation in the opposite direction of the route. MoNav does neither force the source indicator to the route’s polygon nor does it recompute the route, as long the distance is still near the originally planned route:

In case the position was in direction of the route, but somewhere in the houses nearby, MoNav will determine the nearest position on the computed route, shorten it accordingly and show the source indicator at the startpoint of the shortened route instead of somewhere in the houses nearby:

IIRC I’ve seen such a feature as an option called »Lock to road« in commercial routing software.

The problem seems to be easy to solve, and actually, it is. However, it requires some linear algebra (aka vector maths). Quoting lbackstrom:

Many TopCoders seem to be mortally afraid of geometry problems. I think it’s safe to say that the majority of them would be in favor of a ban on TopCoder geometry problems.

You can find a couple of places with solutions using a search engine, and the example of Rod Stephens finally did the job for me after porting it to C++ and adopting it to my needs (thanks for the kind permission to use it BTW).

So what is this posting all about? Remembering my school days, many pupils disliked maths, especially word problems. Which is a pity. The world is full of issues solvable by applying a little math, while people refrain from solving them due to some aversion. Got interested? Great.

Maths have been invented to better describe the world we live in. And computers executing maths help to make the world a better place, day by day. Be the one who converts maths into useful computer programs. And you’ll feel good during the Xmas break :) .

When MoNav learned to speak

ce — Mon, 19 Dec 2011 22:58:21 +0000

A couple of months ago I opened a branch named »ui-ng« in MoNav‘s repository to develop a new user interface. Meanwhile this branch became a playground for several hacks, and some of them are just spikes to check out whether some ideas work or not.

I denied to work on speech output this spring, as I knew this would become a rather lengthy task. But it was obvious that I won’t resist the temptation during the cold and dark winter months. So I added the first code to generate spoken turn instructions recently. It is an ugly hack, just to determine what was possible. The code as found in the »ui-ng« repo works, well, at least a bit. The instructions are far away from being useful, except for lonesome crossings or roundabouts without other crossings nearby.

I’m using prerecorded samples for now, as the current open source speech synthesis systems did not show the results I desired. OTOH, this means I cannot generate instructions with dynamic contents like distances or street names. Additionally, those samples currently are included in the application binary, which will pollute the memory of handset devices as soon I’ll add further localized samples (currently speech is available in german and english language only).

The main issue is that MoNav recalculates the route each time a GPS position update is received – which means each second on the N900. As the GPS position always is a bit inaccurate, MoNav will speak »Please turn right« when you pass, for example, a gas station and the GPS position is off the road by a couple of meters.

As a consequence, I’ve just written some code that detects whether the vehicle is still “on track”. The route only gets recalculated in case the vehicle left it for more than x meters. This makes the route much more persistent and will cause far less headache than the previous approach. As this happened just a couple of minutes ago, the code is not in the repo yet.

There’s still a lot of work to do, and I’m curious whether I’ll stay motivated enough to do all of the work ahead. On the other hand it’s just plain fun to explore the secrets of a usable routing application.

So stay tuned. The next week(s) will show whether I’ll »head straightforward« :) .

The Pipe Organ of St. Konrad, Aschaffenburg-Strietwald, Germany

ce — Mon, 19 Dec 2011 18:12:42 +0000

On saturday I had the occasion (but not the time) to play the instrument depicted above. Unfortunately I forgot to take a picture of its console with traditional stops on either side, as I was in a hurry.

It’s quite an interesting instrument, built in 2007 by Freiburger Orgelbau. The disposition of the stops qualifies the instrument for authentic playing of both baroque and romantic organ music:

I. Main (C–g3)

1. Bordon 16’
2. Prinzipal 8’
3. Gedeckt 8’
4. Flute harmonique 8’
5. Viola da Gamba 8’
6. Octave 4’
7. Gemshorn 4’
8. Superoctave 2′
9. Mixtur 4-5fach 1 1/’3’
10. Trompete 8’

Tremulant

II. Swell (C–g3)
11. Geigenprizipal 8′
12. Rohrgedeckt 8’
13. Salicional 8’
14. Vox coelestis 8’
15. Octav 4’
16. Traversflöte 4’
17. Nasard 2 2/’3’
18. Octavin 2’
19. Terz 1 3/’5’
20. Piccolo 1’
21. Trompette harmonique 8’
22. Hautbois 8’

Tremulant

Pedal (C–f1)
23. Prinzipalbass 16′
24. Subbass 16’
25. Octavbass 8’
26. Gedacktbass 8’
27. Octav 4’
28. Bombarde 16’
29. Trompete 8’

Obviously it is dominated by 8’ stops. Its timbre is rather full and warm instead of brilliant. I hope there will be a second chance for playing it. Here are the stops I’m most interested in:

Prinzipal 8’ – full and warm
Flute harmonique 8’ – one of my all time favorite stops. The length of those pipes is twice the length necessary, while a small drilling in the middle of the length ensures the pipe’s pitch is correct.
Trompete 8’ – not a bawler at all
Vox coelestis 8’ – if you like programming pads with two detuned oscillators on synthesizers, this stop is for you. You will ask “How can I create such a sound on a synth?!?”
Terz 1 3/’5’ – a third. A unique stop. I had absolutely no luck programming it on a synthesizer.
Hautbois 8’ – another lingual stop. Another sound you won’t be able to program on a synth.
Bombarde 16’ – nomen est omen. The right pedal stop for bombastic pieces. Grand Jeux comes to my mind :)

Legs of Rabbit

ce — Mon, 19 Dec 2011 17:59:00 +0000

That’s two legs of rabbit, one of my absolute favs when it comes to meat. Gently roasted and then stewed in some white wine at 80°C, it will help to make this one a worthwhile evening :) .

Edit: Later that same evening:

User Stories Applied & Agile Estimating and Planning

ce — Mon, 12 Dec 2011 23:58:48 +0000

Overview

Though we introduced two physical boards for managing the product and the sprint backlogs, I’m still searching for a method to organize their items in a manner that fits our needs best. There are two books sitting on my couch which I hope to read during the Xmas break. Both are written by Mike Cohn and seem to be standard works for agile addicts (and even recommended by Ken Schwaber).

User Stories Applied

Here’s just a short citation of its¹ back cover:

Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process that saves time, eliminates rework, and leads directly to better software.

Of course the book is not only about user stories, but also about all of the adjacent topics.

Agile Estimating and Planning

Again a short citation of its² back cover:

Using the techniques in Agile Estimating and Planning, you can stay agile from start to finish, saving time, conserving resources, and accomplishing more.

Again, this book is about management of agile software projects in common and not only about estimating and planning. I hope to learn a lot by reading them.

¹ Mike Cohn, »User Stories Applied« 2004, ISBN 0-321-20568-5

² Mike Cohn, »Agile Estimating and Planning« 2006, ISBN 0-13-147941-5

Rest in peace, Gramma

ce — Sun, 11 Dec 2011 10:08:22 +0000

Scrum User Group Karlsruhe – December 2011

ce — Wed, 07 Dec 2011 22:14:28 +0000

Today the local Scrum User Group met at the usual location. Thomas Spielhofer came from Vienna to gather feedback concerning the study »Successful agile leadership« (German Tongue PDF). Subsequently we discussed the points presented by Thomas.

I’ll not post more details as it’s late already and other things on today’s to-do-list are still open. In case you are living nearby, feel free to visit the next meeting in two months.