kirjoittaessani

(Hinweis: der Artikel ist sicher leichter zu verstehen, wenn man sich die Grafik auf Vincents Seite daneben legt)

Nachdem ich Gitflow nun einige Zeit in mehreren Projekten verwendet habe, möchte ich noch ein paar Dinge berichten, die mir aufgefallen sind. Zur Erinnerung: Man benutzt mehrere Zweige,1 die nebeneinanderher laufen. Neben develop, auf dem die Entwicklung vorangetrieben wird, gibt es master, der nur veröffentlichte Versionen2 enthält, Feature-Zweige (auf denen größere Neuerungen entwickelt werden; ein Zweig pro Feature), Hotfixes3 und Releases.4

Man kann zwar mehrere Feature-Zweige gleichzeitig offen haben, um einen neuen Hotfix- oder Release-Zweig zu starten, muß der vorhergehende aber abgeschlossen werden. Das war zunächst etwas schwer verdaulich für mich, ist aber letztlich sicher sinnvoll: Releases folgen aufeinander, sie können nicht parallel laufen; eigentlich könnte man auch mit einem einzigen Release-Zweig leben, nur wird dann das Tagging schwieriger. Für Hotfixes gilt das nicht so eindeutig, aber git flow verwendet einen Hotfix-Zweig pro Version, nicht einen pro zu behebenden Bug.

Heute habe ich dann etwas Dummes gemacht: nachdem ich einige Zeit an Feature X gearbeitet hatte, habe ich ein paar Bugs in der Produktionsversion behoben -- ein klassischer Hotfix. Die git flow Tools sorgen dafür, daß diese Fehlerkorrekturen in develop und in den Releases auftauchen -- nur mein Feature-Zweig war weiter verbuggt. Was tun? Ich habe mich dafür entschieden, den Feature-Zweig mittels Rebase an der aktuellen develop-Version zu starten. Das war ein großer Fehler. Durch das Rebase gab es nämlich Diskrepanzen zwischen meinem lokalen Repository und der zentralen Version, die sich nicht leicht (und vor allem nur fehleranfällig) korrigieren ließen. Git flow bemerkt das auch und verweigert an viele Stellen gleich den Dienst. Ich habe es zwar hinbekommen, aber mein Commit-Graph ist ziemlich unübersichtlich geworden.

Lektion gelernt: man kann jederzeit Feature-Zweige nach develop Mergen,5 aber nicht umgekehrt. Die letzten Bugfixes sind bei einer reinen Entwicklerversion oft auch überflüssig; und wenn man sie wirklich braucht, ist wahrscheinlich Cherry-Picking die beste Methode.

Übrigens hat git eine unangenehme Eigenschaft, die mich überhaupt erst in diese missliche Lage gebracht hat: Man kann die Geschichte umschreiben (rewriting history), i.e. es gibt git-Kommandos, die nicht nur neue Vertizes zum Commit-Graphen hinzufügen, sondern bestehende Vertizes löschen oder ändern. Das widerspricht meinen Erwartungen an ein Versionskontrollsystem sehr, es liegt aber wohl im Konzept der verteilten Repositories, und ließe sich nur mit schweren Nachteilen ausschließen.

1. Branches [↩]
2. oder zumindest solche, die man veröffentlichen könnte [↩]
3. schwerere Bugs, die zwischendurch behoben werden müssen [↩]
4. Feinschliff zur nächsten Version [↩]
5. ich schrieb ja schon, daß man diese Begriffe nicht sinnvoll übersetzen kann [↩]

Das Versionskontrollsystem git habe ich ja schon gelegentlich erwähnt. Heute ist mir aufgefallen, daß git bei aller Komplexität und Mächtigkeit dadurch, daß sich Repositories so einfach einrichten lassen, auch wunderbar leichtfüßig1 ist. Früher2 habe ich echte Versionskontrolle3 nur für größere Softwareprojekte verwendet, kleinere Projekte habe ich allenfalls mit RCS verwaltet.

Derzeit stecke ich mehr und mehr auch Kleinkram in git: Konfigurationsdateien -- früher mehr schlecht als recht in RCS4 -- lassen sich so wunderbar handhaben. Ganz nebenbei bietet git auch noch eine Art Deployment: ich kann auf meiner Maschine entwickeln und dann einfach auf den Server, den ich eigentlich konfigurieren will, klonen. So bleiben alle Projekte und Projektchen schön übersichtlich beisammen; und dank Gitzilla ist auch für eine sinnvolle Dokumentation gesorgt.
Das einzige, was ich jetzt noch vermisse, ist eine gute und universelle Testumgebung: irgendetwas, das für ein neues Projekt keiner aufwendigen Neukonfiguration bedarf, das aber das Testen von neuen Konfigurationen ermöglicht, bevor sie auf den Produktionsserver geschoben5 werden.

1. lightweight [↩]
2. ^TM [↩]
3. z.B. CVS [↩]
4. oder gar nicht verwaltet [↩]
5. deployt? deployed? [↩]

Erkenntnis des Tages: Gitflow macht Spaß!

Außerdem fange ich an, ein zweites kürzlich entdecktes Werkzeug regelmäßig zu nutzen: Gitzilla. Das ist -- man ahnt es fast -- eine Git--Bugzilla-Integration. Nach der Installation läuft Gitzilla unsichtbar im Hintergrund. Wenn man nun in einem Git-Commit-Text eine Bugnummer aus dem angeschlossenen Bugzilla erwähnt, dann erscheinen automatisch Informationen zu diesem Commit als Kommentar in dem Bug.
Das ist sehr praktisch, um eine Gesamtdokumentation zu erstellen (statt Bugzilla und Git-Historie nebeneinander her laufen zu lassen)

Wer mag, kann die Bugnummer sogar erzwingen, aber für mich als Einzelkämpfer ist das übertrieben.

Zum Schluß noch ein kleiner Tipp für alle, die es selbst ausprobieren möchten: Gitzilla wird beim Push in ein (zentrales) Repository aktiv, nicht schon beim lokalen Commit. Das steht zwar in der Dokumentation, ich habe mich zunächst aber trotzdem gewundert, als nichts passiert ist. Diese Repositories habe ich mit mit --shared --bare in /home/git auf meiner Maschine angelegt, so sind sie zwar mir zugeordnet, aber trotzdem von meinen eigenen Daten getrennt.

Jeder weiß, daß man Dokumente, in denen viel Hirnschmalz in wenig Text verpackt ist1, in einem Revision Control System hält. Ich habe früher CVS für größere Projekte und RCS für Kleinkram2 verwendet.

For ein paar Jahren bin ich dann auf git umgestiegen: Neben dem einfachen Einrichten des Repository3 macht vor allem das leichte und schnelle Branchen Spaß. Zugegeben, git hat auch seine Schwächen, und die Bedienung ist nicht immer einfach4.

Trotzdem überwiegen in meinen Augen zumindest gegenüber SVN und CVS (und natürlich RCS) die Vorteile. Vor ein paar Tagen bin ich zufällig über einen Blog-Eintrag von Vincent Driessen gestolpert, der dem Werkzeug git sozusagen als Überbau noch einen Prozeß oder einen Satz Richtlinien hinzufügt -- Anweisungen, wann man welche Branches erzeugen soll, und wohin sie gemerget werden. Das Modell gefällt mir auf Anhieb recht gut, und weil es dazu auch ein Tool gibt, das das Einhalten des Prozesses stark vereinfacht, werde ich meine Repositories demnächst wohl nach und nach umstellen.

Vincents Modell hat natürlich auch Kritiker, und wer tiefer einsteigen will, sollte sich die Diskussion zu Jeffs Blog-Eintrag durchlesen. Wahrscheinlich am meisten nachgedacht hat Adam Dymitruk. Die Feinheiten seines Modells sind für mich zu dieser späten Stunde definitiv zuviel, aber mir gefällt die Idee, Feature Branches unabhängig zu halten, so daß man jedes Feature jederzeit wieder ausbauen kann.5

Edit: HTML an falscher Stelle
Edit 2: Typo

1. z.B. Source Code und Konfigurationsdateien [↩]
2. z.B. Dateien aus /etc [↩]
3. ja, ich benutze normalerweise auch lieber deutsche Begriffe, aber heute lasse ich das aus gutem Grunde mal sein: wenn man gut eingeführte termini technici übersetzt, versteht am Ende niemand etwas [↩]
4. manche Kommandos muß ich heute noch immer wieder nachschlagen, checkout -b vergesse ich regelmäßig, wenn ich es nicht oft genug benutze [↩]
5. jedenfalls bis zum nächsten Release [↩]

Wer gelegentlich auf der Kommandozeile arbeitet, kennt sicher den einen oder anderen redirector, um Ein- oder Ausgaben von Befehlen in Dateien umzuleiten:

ls > /tmp/liste
grep blub < /tmp/list
grep -r hallo . 2> /tmp/fehler
ls /tmp >> /tmp/liste

Heute hatte ich das Vergnügen, einen neuen zu benutzen. Grund war ein Programm, das zunächst prüft, ob der File-Descriptor 3 geöffnet ist. In einer normalen Shell ist das nicht der Fall, wenn das besagte Programm als Plugin läuft, aber schon. Zur Fehlersuche wollte ich es unter der Shell starten, aber den Plugin-Modus simulieren. Die Lösung:

exec 3<> /tmp/t

legt die Datei /tmp/t an und öffnet sie mit dem gewünschten Descriptor. Danach starte ich einfach das zu untersuchende Programm.

[via The Linux Documentation Project]

... und warum es keinen interessiert

Der persönliche Computer

Als alles begann, füllten Computer ganze Räume und brauchten Heerscharen an Bedienpersonal. Durch Fortschritte in der Elektronik wurden sie aber zunehmend kleiner, leistungsfähiger und einfacher zu bedienen. Nannte man die ersten Modelle in der Größe einer Waschmaschine noch Mini-Computer, so brach in den siebziger Jahren das Zeitalter der Mikrocomputer an, die Geräte hatten nur noch die Größe einer Schreibmaschine und waren -- oft als Bausätze -- für Hobbyisten erschwinglich. Eine Professionalisierung brachte schließlich einen Rechner, der klein und preiswert genug war, daß er (zunächst in Firmen) von nur einer einzelnen Person genutzt werden konnte: der Personal Computer war geboren.

Die Universalmaschine

Ein Vierteljahrhundert lang ist der PC nun preiswerter, (etwas) kleiner und (viel) schneller geworden. Gleichzeitig hat sich mehr oder weniger im Verborgenen eine andere Entwicklung vollzogen, die den Charakter des PCs aus einem anderen Blickwinkel beleuchtet: dank fallender Preise und fortschreitender Miniaturisierung finden sich in mehr und mehr Geräten embedded Systeme, eine Art Kleinstcomputer, der anstelle aufwendiger analoger Verschaltungen (oder gar mechanischer Steuerungen) Stereoanlagen und Waschmaschinen Leben einhaucht. Wer schon einmal versucht hat, gegen seine Waschmaschine Schach (oder Go) zu spielen, hat gemerkt, daß der PC nicht nur ein persönliches Gerät ist, sondern auch ein sehr universelles: ein computerisiertes Haushaltsgerät bleibt seinem Zweck treu, aber ein PC kann mit entsprechender Software ganz beliebige Aufgaben übernehmen.

Clever & Smart

In den letzten Jahren hat eine weitere Spielart des Computers für Furore gesorgt: nachdem die klobigen Autotelefone des letzten Jahrhunderts unter anderem durch Embedded-Technik zu kompakten Winzlingen kleiner als ein Telefonhörer geschrumpft sind, ist mittlerweile das Zwitterwesen Smartphone aufgetaucht: halb Telefon, halb PC.

Wolken am Horizont

Doch wer nun einen tragbaren PC mit Telefonfunktionalität erwartete, der wurde unter Umständen enttäuscht: wer ein iPhone erwirbt, hält keine uneingeschränkte Universalmaschine in Händen, sondern ist auf das Placet des Herstellers angewiesen, wenn er Software (und sei es selbstgeschriebene) installieren möchte. Vereinzelt geäußerte Befürchtungen, den PCs desselben Herstellers könnte über kurz oder lang ein ähnliches Schicksal drohen, wurden allgemein mit Hinweis auf die andere Natur des PCs (als Universalmaschine nämlich) abgetan.

Nun hat die Firma Apple etwas getan, das sich in meinen Augen wie der Anfang einer sehr schlechten Entwicklung ausnimmt: es gibt für das Betriebssystem keine Installationsanweisungen-CDs mehr. Windows-Benutzer könnten diese Aussage unter Umständen mißverstehen: ich meine damit nicht, daß man sich nach dem Kauf eines vorinstallierten Rechners eine Recovery-CD selbst brennen (oder für viel Geld eine Vollversion in der Pappschachtel kaufen) müßte. Nein, ich kann meinen Rechner -- egal ob vorinstalliert oder mit einem nachgekauften System -- nur über das Internet installieren. Das Installationsprogramm löscht sich nach getaner Arbeit. Selbst, wenn ich fünf Rechner installieren will (was ich ganz legal mit nur einer Lizenz tun kann), muß ich fünfmal einen Installer von über vier Gigabyte herunterladen.

Und nun?

Für mich ist das eine Katastrophe: wenn ich meinen eigenen Rechner nur dann neu installieren kann, wenn es dem Hersteller paßt, dann muß ich befürchten, bald noch mehr Kontrolle abgeben zu müssen. Der Wert der Universalmaschine PC wäre dahin, ich hätte nur noch einen besseren Fernseher auf dem Schreibtisch. Für mich ist das Grund genug, nach zwanzig Jahren1 Markentreue zum ersten Mal ernsthaft über einen Wechsel nachzudenken. Seltsamerweise scheint die Angelegenheit sonst niemanden zu stören. Ein wenig Googeln hat zwar ein paar Leute zutage gefördert, die sich über die Bandbreitenverschwendung beim Besitz mehrerer Rechner ärgern, aber den Kontrollverlust bemerkt (oder zumindest bemängelt) niemand.

Thou shalt not pass

Damit die Geschichte hier nicht zu einseitig wird, möchte ich noch auf einen potentiell viel gefährlicheren Schachzug aus dem anderen Lager hinweisen: wer als Hardware-Hersteller künftig Windows-zertifizierte Systeme anbieten will, muß einen Mechanismus einbauen, der nur noch kryptographisch signierte Betriebssysteme bootet. Diese Signatur stellt nur Microsoft aus -- in sehr naher Zukunft kann man also zum Beispiel Linux nur noch benutzen, wenn Microsoft das gestattet.
Na, gruselt es schon?

Was tun

Im Gegensatz zu Apples lustigen Ideen gibt es hier genug kritische Stimmen im Netz. Das dürfte natürlich daran liegen, daß eben nicht Microsofts eigene Kunden, sondern gerade die anderen gefährdet sind. Außerdem ist die Bastelfreiheit(freedom to tinker) gerade unter diesen Anderen (z.B. Linux-Entwicklern) ein sehr hoch gehaltenes Gut.

Im Umkehrschluß sieht es ganz danach aus, daß es Apples Kunden egal ist, was sie mit ihren Maschinen machen können. Sie brauchen vielleicht gar keinen PC, sondern nur eine Schreibmaschine mit Bildverarbeitung und Musik-Player. Naja, und wenn Cupertino sowieso schon die Finger dein hat, macht es auch nichts, daß die Synchronisation von PC und Smartphone weniger und weniger über ein USB-Kabel und dafür mehr und mehr über einen Server bei Apple läuft. Darüber regt sich nämlich auch keiner auf. Ihr Schafe!

1. angefangen mit dem LC II [↩]

Grmbl. Die erste Version dieses Beitrags hat WordPress für iOS gefressen.

Ich habe vor einigen Jahren meinen etwas schwierigen, vor allem durch last.fm bedingten Umstieg von analoger Musik auf MP3 beschrieben. Auch wenn sich mein Kopf (oder Bauch?) immer noch schwer tut: inzwischen bin ich im musikalischen Digitalzeitalter angekommen, ein iPhone ist schlicht viel transportabler als ein Plattenspieler, und wenn es nur bei der Hausarbeit ist.
Ich hatte mich damals nach einem sehr kurzen, wenig erfreulichen Versuch mit der Open-Source-Software Audacity mach einiger Suche für die Programme Peak und Soundsoap von Bias entschieden, um LPs aufzunehmen, zu entknistern und zu schneiden.
Nachdem mein Plattenspieler nun über ein Jahr komplett stillgestanden hat, fällt mir die Titelauswahl in letzter Zeit wieder etwas schwer: immerhin habe ich höchstens ein Drittel meiner Sammlung digitalisiert.
Also flugs die Software gestartet, den Rechner verkabelt, und -- Moment. Die Audiosoftware will neu freigeschaltet werden, wohl, weil ich den Rechner irgendwann austauschen mußte. Das bekomme ich erstmal nicht hin, und bei der Fehlersuche stelle ich fest, daß es die Firma Bias nicht mehr gibt.

Ups. Keine Ahnung, ob ich irgendwie meine bezahlten Programme wieder benutzen könnte, aber spätestens wenn sie mit einem der nächsten Betriebssysteme nicht mehr kompatibel sind, ist Ende im Gelände. So ist das eben mit Closed Source -- da kann man froh sein, wenigstens die alten Dokumente noch lesen zu können. Ich habe jedenfalls den ganzen Kram von der Festplatte geworfen und stattdessen die aktuelle Version von Audacity installiert; vielleicht werde ich ja doch noch warm damit.

Actually, I have known this for some time, but today, it has bitten me again: Interpreted languages1 are not suited for application development. Period. Use them for quick hacks, or for prototyping, or in lieu of a shell script. But never for real applications.

People tend to say Computers are so fast today the overhead does not really matter, and if it does for a few inner loops, no problem: our language can interface with C. But that is beside the point. The real disadvantage of these languages is not their (somewhat inferior) execution speed, but their lack of static checking. If you write bogus in a compiled language, chances are the compiler will catch it. Some stricter languages2 will catch more kinds of bogus than more lenient ones3, but there are surprisingly many ways to write bogus that every compiler will catch. Interpreted languages do not have a compile phase, they just throw an exception when encountering bogus at runtime. If they encounter it: There are many execution paths through a program, and some may not be followed very often, making it easy to write, install, and use completely broken software. You may say Well, write tests then, but as useful tests are, they come with large disadvantages when relied upon as the only means of detecting errors: Firstly, they have to be written. A compiler knows about the language, but the developer has to write all necessary testcases by hand. It is easy to overlook something, and it is also very easy to be lazy and write too few tests (or none at all). Secondly, executing tests takes machine time (probably more than what was saved by not compiling), and writing tests takes developer time (lots of it). Finally, the static analysis a compiler provides tends to catch different errors than tests do, so combining the two will simply catch more problems than either method on its own.

Oh, and then there is the problem of external code. Libraries, modules, whatever. APIs should not change (needlessly), but sometimes they do. With ordinary binary code, there is an established way to keep around different versions of a given library, so older programs using an older API can still function. I am not aware of a similar mechanism for Python, so getting ImportErrors from a module that installed just fine is not that unusual. In fact, implementing such a method for an interpreted language would be somewhat more involved than for a compiled one: When a programmer links to a shared library, the linker will take that to mean the latest installed version of that library. The version number is then encoded into the application binary, so the correct library will be used whenever the application is started. However, the very nature of an interpreted language means that the program is not touched by anyone but the developer. So if the developer does not demand a particular version, nothing else does, either. Seriously: use a tool that fits the job rather than clutching a hammer and trying to see nails everywhere.

1. like Python [↩]
2. like Ada [↩]
3. like C [↩]

Linux und die Speicherverwaltung -- das ist gar kein einfaches Thema. Wenn man dann noch versucht, seine User mittels ulimit im Zaume zu halten, wird es nur schwieriger. Gerade habe ich etwas sehr erhellendes gefunden: die meisten Sachen funktionieren einfach nicht.

Unpleasant: night after night, your machine keeps deleting your laboriously developed code. Convenient: everything is in a local git repository, and any point in time may be reconstructed. Strange: not only has the code disappeared, but all traces of its history as well.

In the past few months, I have spent an hour or two almost every week to find the leak. Today, I have met with success:

In the normal fast-forward case the behavior remains unchanged. However, now local modifications and commits will be erased, and upstream rewrites are handled smoothly.  This ensures that the upstream
branch is tested as expected.

Argh! What bally idea is that? I would like to decide for myself what I want to test, thank you very much. If I really want to test Upstream, I will create a branch for that purpose. It is not up to some piece of software to decide in my place, and then remove my code from the repository!