Kategorie ‘Code’

(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 []
Comments Off on Fließigkeiten

Tags:

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? []
Comments Off on Hohelied

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.

2 Kommentare

Tags:

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 []
2 Kommentare

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]

Comments Off on Direktor

... 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 []
1 Kommentar

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.

Comments Off on Unbiased

Eigentlich weiß ich das ja schon länger, aber heute ist es mir wieder schmerzhaft bewußt geworden: Interpretierte Sprachen1 sind zur Entwicklung ernsthafter Programme ungeeignet. Für Prototypen, einen schnellen Hack, oder als Shell-Skript-Ersatz sind sie eine feine Sache, aber nicht für echte Programme.

Man hört oft, Computer sind heutzutage so schnell, daß das schlechtere Laufzeitverhalten nicht ins Gewicht fällt, und falls doch ein paar Stellen kritisch sind, so ist das auch kein Problem: die Sprache kann C-Routinen aufrufen. Aber darum geht es nicht. Die echten Nachteile liegen nicht in der Ausführungsgeschwindigkeit, sondern in der fehlenden statischen Prüfung des Codes. Wenn man in einer kompilierten Sprache Quatsch schreibt, dann kann man darauf hoffen, daß der Compiler das bemerkt. In manchen strengeren Sprachen2 läßt der Compiler weniger Quatsch durchgehen als in nachgiebigeren3, aber es gibt erstaunliche viele Sorten Quatsch, die jeder Compiler findet. Interpretierte Sprachen kennen keinen Compiler, deswegen finden sie den Quatsch erst zur Laufzeit. Wenn sie ihn finden: Es gibt viele Pfade durch ein Programm, und einige davon werden nur selten benutz; deshalb ist es einfach, völlig vergurkte Programme zu schreiben, zu installieren, und zu benutzen. Es heißt dann oft Deshalb brauchen wir Tests, aber so nützlich Tests auch sind, so haben sie doch gewichtige Nachteile (jedenfalls wenn sie die einzige Möglichkeit sind, Fehler zu finden: Zuerst müssen sie überhaupt geschrieben werden. Ein Compiler versteht die Sprache, aber der Entwickler muß alle nötigen Testcases von Hand schreiben. Dabei kann man leicht etwas übersehen, und noch leichter aus Bequemlichkeit zu wenige (oder gar keine) Tests schreiben. Zweitens braucht das Abarbeiten der Tests Rechenzeit -- wahrscheinlich mehr, als man durch den fehlenden Compilerlauf gespart hat; und das Schreiben kosts Entwicklerzeit, und zwar eine Menge. Schließlich findet der Compiler oft einfach andere Fehler als Tests, und wenn man beides einsetzt, findet man mehr Fehler.

Ja, und dann gibt es noch das Problem mit externem Code. Bibliotheken, Module, oder wie man ihn auch nennen will. APIs sollten sich nicht ändern (jedenfalls nicht ohne guten Grund), aber manchmal tun sie es eben doch. Für gewöhnliche, binäre Programme gibt es wohldefinierte Mechanismen, um verschiedene Versionen einer Bibliothek gleichzeitig vorzuhalten, damit ältere Programme immer noch laufen. Einen entsprechenden Mechanismus für Python kenne ich nicht, und so ungewöhnlich ist es nicht, wenn ein sauber installiertes Modul mit ImportErrors um sich wirft. Wenn man eine solche Methode entwickeln wollte, hätte man auch mit einem zusätzlichen Problem zu kämpfen: Wenn ein Programmierer eine shared library verlinkt, dann nimmt der Linker automatisch die neueste installierte Version dieser Bibliothek. Die Versionsnummer wird dann in dem kompilierten Programm verewigt, und wenn man es irgendwann später startet, wird die richtige Bibliothek benutzt. Es liegt aber gerade im Wesen einer interpretierten Sprache, daß der Programmcode nur vom Programmierer verändert wird. Wenn dieser also nicht von Hand eine bestimmte Bibliotheksversion anfordert, dann tut das auch keine andere Instanz.

Im Ernst: man sollte Werkzeuge verwenden, die für die Aufgabe geeignet sind, anstatt sich verzweifelt an seinen Hammer zu klammern und überall Nägel zu sehen.

  1. z.B. Python []
  2. z.B. Ada []
  3. z.B. C []
Comments Off on Lessons learnedenglishdeutsch

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.

Comments Off on Linux, Ltd

Ärgerlich, wenn der Rechner allnächtlich den mühsam zurechtgezimmerten Code löscht. Praktisch, wenn alle Änderungen in der Code-Datenbank gespeichert sind und man zu jedem beliebigen Zeitpunkt zurückgehen kann. Wunderlich, wenn zusammen mit dem Code auch alle seine Spuren in der Vergangenheit verschwunden sind.

Jetzt habe ich über Monate immer mal wieder ein, zwei Stündchen darauf verwendet, das Leck zu finden. Heute war ich endlich erfolgreich:

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! Was soll das denn? Was ich teste, möchte ich bitteschön selbst entscheiden. Und wenn ich wirklich Upstream testen will, dann lege ich schon einen passenden Branch an. Aber es kann doch nicht sein, daß die Software das für mich entscheidet, und dann auch noch meinen Code aus der Datenbank löscht!

Comments Off on Eraseddeutschenglish