Täglich stempeln gehen

Interessante Web-Applikationen können so einfach sein: Ryan Bates, in der Rails-Gemeinde durch seine Railscasts bekannt, demonstriert mit Daily Stamp eine nette kleine Applikation, die alles hat, was man braucht: Einfachheit, ein paar nette Gimmicks, und ein klar definiertes Ziel.

Nebenbei diente sie als Beitrag zum Rails Rumble 2009. Bemerkenswert: Alle dort gezeigten Applikationen sind innerhalb von nur 48 Stunden entstanden.

Digital Edition? Nein, danke.

Ich wußte es ja: DRM fällt selbst dem geduldigsten Käufer (der ich nicht bin) irgendwann einmal auf die Füße. Vor einiger Zeit habe ich in einem Anfall von "muß ich gleich haben" und entgegen meine Prinzipien ein DRM-geschütztes Buch gekauft, daß zum Lesen Adobes Digital Edition benötigt.

Nicht genug damit, daß das Lesen damit wirklich wenig Spaß macht(e), da offenbar bei jedem Umblättern sehr, sehr sorgfältig geprüft wurde, ob ich das überhaupt darf, was gerade bei Fachliteratur, wo man doch schnell mal zwischen Seiten hin- und herspringt, sehr lästig ist. Nein, nach dem Update auf Snow Leopard überraschte mich dieses Meisterwerk des Softwareingenieurskunst mit dem Hinweis, daß es eine neue Version gäbe: Entweder ich installiere jetzt sofort das Update, oder ich schere mich zum Teufel und lese mein gekauftes Buch eben nicht. Na schön, nach wenigen Minuten "Installationserlebnis" war das neue Digital Editions installiert und konnte gestartet werden.

Mein. Einziges. Existierendes. DRM-geschütztes. E-Book. Läßt. Sich. Nicht. Mehr. Öffnen.

Weil? Ja, was soll ich sagen? Keine Ahnung, Adobe murmelt irgendwelchen nutzlosen Techno-Mumbo-Jumbo und verweigert die Anzeige.

Wie komme ich an mein Buch? Keine Ahnung. Ist mir jetzt auch egal.

Fazit: Ich gehe jetzt in einen Buchladen und kaufe mir das Buch. Nochmal. Vorher lösche ich Adobe Digital Editions (erledigt.). In Zukunft kaufe ich nur noch DRM-freie Bücher. Und wenn es keine mehr gibt, mir egal, kaufe ich eben weiter toten Wald.

P.S. Es gibt natürlich weiterhin Anbieter, die PDFs ohne DRM verkaufen -- da steht dann eben auf jeder Seite mein Name.

P.P.S.: Es gibt keine "gute" DRM-Technologie. Es sei denn, man betrachtet gedruckte Bücher als DRM-geschützt (was Quatsch wäre, weil sie sehr, sehr nicht-digital sind).

Perfect Gem...

Nur eine kleine Erinnerung an mich selbst: technical.pickles hat unter Craft the perfect gem with Jeweler einen Überblick über das Erstellung und Verwalten von Ruby Gems mit Jeweler geschrieben. Macht das Leben leichter.

Dropbox: Platz im Netz

Gestern bin ich auf Dropbox gestoßen, ein Dienst, der Dateien im Netz ablegt, versioniert und synchronisiert. Die Kosten für Dropbox sind moderat (angefangen bei einer kostenlosen Variante mit 2GB Platz), die Software ist intuitiv: Neben der auch bei anderen Diensten bestehenden Möglichkeit, Dateien zwischen zwei Maschinen zu synchronisieren, gibt Dropbox dem Nutzer die Fähigkeit an die Hand, auf alte Versionen einer Datei zuzugreifen. Damit lassen sich schnell einfach Backup-Szenarien umsetzen.

Für bestehende Dropbox-Benutzer gibt's die Möglichkeit, andere Benutzer zu werben: Wer z.B. dem Link in diesem Blog folgt, um sich bei Dropbox anzumelden, beschehrt mir ein paar MB zusätzlichen Speicherplatz. Eine interessante Wendung ist aber, daß ein neuer Benutzer, der einer Einladung folgt, selbst ebenfalls zusätzlichen Gratis-Speicherplatz erhält, was es auch für den Eingeladenen interessanter macht, einer Einladung zu folgen.

Wie es mit der Sicherheit der im Netz abgelegten Daten aussieht, ist mir bisher nicht bekannt. Es bietet sich also zunächst einmal an, nur Daten seiner Dropbox anzuvertrauen, die man guten Gewissens auch anderen zugänglich machen kann.

Insgesamt ein interessanter Start eines praktischen Dienstes, insbesondere im Vergleich mit JUnit MAX. Ein gewisses Vertrauen zu den Anbietern muß man allerdings schon aufbringen.

Max ist tot

Kent Beck hat gerade JUnit MAX beerdigt: Das TDD-Tool für Eclipse wird vorerst nicht weiterentwickelt, sondern aktiv "abgemanaged".

Was für Becks Three Rivers Institute ärgerlich ist, ist für Eclipse-Benutzer traurig, weil ein nützliches Tool aus dem Arsenal von Java-Entwicklern verschwindet. Allerdings versorgt uns MAX auch auf dem Totenbett noch mit wertvollen Lektionen zum Lernen:

1. Auch gute Ideen brauchen Werbung.
2. Nutzerbasis ist wichtiger als Marge.
3. Paid Beta ist ein sicherer Weg in den Untergang.

JUnit MAX hat praktisch jede Gelegenheit vermieden, in Entwicklerkreisen bekannt zu werden. Einzig Kent Becks Blog- und Twitter-Leser sind gelegentlich auf MAX gestoßen (wie in den Kommentaren zum Blog zu lesen ist). Die initiale Nutzerbasis war also begrenzt. Ganz offensichtlich hat Kent Becks guter Name und die spärlichen Informationen über sein Produkt allein nicht gereicht, im Info-Meer sichtbar zu werden. Aktives Marketing wäre also unbedingt notwendig gewesen.

Der Versuch, MAX frühzeitig über ein Subscription-Modell zu finanzieren, hat das Wachstumspotential von vornherein beschränkt. Als folglich die Anzahl der neuen Subscriptions zurückging, wurde versucht, das finanzielle Loch über höhere Preise pro Subscription zu stopfen, was vorhersehbar neue Subscriptions weiter reduzierte. Die Schlußfolgerung ist eigentlich zu trivial, um sie wiederzukauen, aber trotzdem: Die Breite der Nutzerbasis ist umgekehrt proportional zu den Kosten für den Nutzer.

Letztlich ist aber die Idee der Paid Beta der verdiente Todesstoß für jeden neuen Dienst im Netz. Unabhängig von der "Innovationshöhe" eines Dienstes dient der Beta-Test in erster Linie dem Anbieter des Dienstes, Nutzer des Dienstes müssen i.d.R. mit willkürlichen Einschränkungen des Dienstes leben. Für das Testen eines Produktes werden Tester daher traditionell bezahlt. Die Umkehrung dieser Situation ist wohl glücklicherweise genügend potentiellen Kunden aufgefallen, bevor aus MAX ein Verbraucher-Präzendenzfall werden konnte.

Zum Schluß wünsche ich Kent Beck natürlich, doch noch irgendwie einen Erfolg aus MAX zu machen. Möglichst auch einen finanzellen Erfolg.

Googles nächster Wurf: Chrome OS

Google hat es wieder mal geschafft: Alle reden über Chrome OS, und das, obwohl es gerade mal angekündigt wurde (und das Licht der Welt nicht vor Mitte 2010, also in einem Jahr, erblicken wird): Was beschehrt uns Google da jetzt wieder grandios Neues?

Zunächst mal ist Chrome OS im Kern ein Linux. Das ist nicht überraschend, schließlich gibt es im Moment gerade mal drei Hauptstränge bei der OS-Entwicklung: BSD-Unix inklusve der Abkömmlinge Solaris und (Mac) OS X, Windows NT und dessen Nachfolger, und eben Linux -- und in der Vergangenheit hat Google eine gewisse Affinität zu Linux bewiesen. Ernsthafte Neuigkeiten waren da ja schon aufgrund des Entwicklungsaufwands für ein komplettes OS nicht zu erwarten.

Was Chrome OS uns also voraussichtlich bringen wird, ist eine Art Linux-Distribution mit einer neuen Oberfläche. Auch die Oberfläche wird voraussichtlich auf etablierten Systemen aufsetzen.

Technologisch wird es also möglicherweise hinreichend unterschiedlich von bekannten Linux-Distributionen sein, um das bloße Übertragen von Paketen zu verhindern, aber andererseits auch nicht wirklich neu. Vielmehr halte ich es für einen ähnlichen Ansatz wie Apples iPhone: Auf der Basis von etablierter Technologie wird ein neuer Ansatz der Nutzung forciert, bei dem die Nutzer die lokale Gewalt über ihre Daten zugunsten eines ausgelagerten Managements aufgeben.

Und das könnte durchaus interessant werden: Die Debatte um Datenschutz und Unabhängigkeit vs. Nutzerbequemlichkeit ist wiedermal eröffnet. Dabei ist der Ausgang absehbar: Ich behaupte, die Mehrzahl der IT-Nutzer ist nicht an IT selbst interessiert, und würde den täglichen Kampf gegen Spams und die Jagd nach Updates und Patches lieber heute als morgen ad acta legen.

Vielleicht ist Chrome OS ja die Möglichkeit für die Entwickler der etablierten Systeme, sich von der oftmals selbstherrlich mißverstandenen Losung "educate your user" loszusagen, die Komplexität für den Anwender zu reduzieren und IT endlich wieder als Werkzeug und nicht als Selbstzweck zu begreifen. Alternativ werden sie über kurz oder lang alle Nutzer verlieren, die einfach nur tägliche Aufgaben erledigen wollen -- und das sollte die Mehrheit der Nutzer sein.

Und das wäre wirklich mal etwas Neues.

Refactoring für Sterbliche

Yahuda Katz, einer der Rails Großmeister (wenn es diesen Titel denn gibt), hat vor ein paar Tagen einen guten Blog-Artikel zum Thema Refactoring verfaßt: 6 Steps To Refactoring Rails (For Mere Mortals) beleuchtet ein paar grundsätzliche Vorgehensweisen zum Refactoring (und zwar nicht nur für Rails). Ich denke, nachdem es schon ganze Bücher zum Thema Refactoring gibt, ist das tatsächlich die Essenz des Refactoring, trotzdem halte ich zwei Punkte für besonders wichtig:

Erstmal bedeuted Refactoring, daß neuer Code die gleiche Funktion erfüllt (und keine neuen Features einführt), zweitens funktioniert Refactoring nur mit Tests. Vielen, vielen Tests, die alle funktionalen Bereiche des Codes abdecken.

Meine bescheidene Erfahrung sagt, daß vor dem und während des Refactoring ein ganzer Haufen neuer Tests entsteht. Grundsätzlich muß sowohl der alte als auch der neue Code die Tests bestehen; wenn der alte Code das nicht tut, gibt es nur zwei Szenarien: Der alte Code war fehlerhaft (was ja immer sein kann), oder die Tests stellen auf die neue Codestruktur ab (was möglicherweise etwas fragwürdig ist).

Zuletzt noch eine Anmerkung, die für Nicht-Rails- und Nicht-Ruby-Entwickler vielleicht etwas untergeht: Refactoring passiert nicht auf dem Master-Branch, sondern etwas abseits, da zwischendurch mit Sicherheit ein ganzer Haufen Fehler auftritt (ein SCM ist ohnehin Pflicht). Alle Nutzer von klassischen SCMs haben hier natürlich schlechte Karten, da ihr Code in Dateien organisiert ist, die vom SCM als separate Einheiten gesehen werden. Aber es gibt Hoffnung: Ein Refactoring ist ein guter Grund, sich mal git anzusehen. (Soviel zum Thema Propaganda.)

Joel Test

Gerade stolpere ich über einen interessanten Link zu Joel on Software: The Joel Test: 12 Steps to Better Code. Ich nehme mal an, das Punkte wie source control und 1-step-builds eine notwendige Bedingung für alle halbwegs professionellen Entwickler sind (und natürlich auch für die Rock Stars, die sich nicht gerne "professionell" nennen lassen).

Was ich jetzt gerne noch hätte wären ein nach Punkt 8 ruhiger Arbeitsplatz...

Git, Github und Firewalls

Jeff Tchang hat in Using Github Through Draconian Proxies notiert, wie man git und Github auch durch die in Unternehmen oftmals vorgefundenen strikten Firewalls benutzen kann. Das funktioniert natürlich auch mit anderen Zielsystemen. (Wozu gibt's diese Firewalls eigentlich noch? Ein Affe mit einer Büroklammer kann die umgehen!) Ich bin noch nicht dazu gekommen, es auszuprobieren, aber sollte die Notwendigkeit entstehen, weiß ich jetzt, wie's geht.

(Nicht die Sache mit dem Affen.)

Git-Parabel

Unter The Git Parable hat Tom Preston-Warner eine nette, wenn auch sehr lange Einführung zu Git geschrieben. Entgegen der üblichen Vorstellung der vorhandenen Konzepte und Kommandos beginnt er mit einer Real-World-Anforderung und beschreibt die Umsetzung mit einfachen Mitteln. Am Ende der Geschichte steht natürlich git, aber vielleicht sieht man es ja jetzt mit anderen Augen...

Über Logfileeinträge

Hat Java die Stacktraces erfunden? Ich weiß es nicht. Auf jeden Fall haben sich mit Java Stacktraces als extrem hilfreich bei der Lokalisierung von Anwendungsfehlern in Entwicklung und Betrieb (aller Art von Anwendungen) etabliert. Leider hat sich damit auch eine lästige Unsitte etabliert: Applikationen schreiben im Fehlerfalle keine Fehlermeldungen mehr, sie schreiben Stacktraces. Immer. Damit werden Administratoren mit Fehlermeldungen wie "NullPointerException" oder "RecordNotFoundException" in ihren Logfiles konfrontiert, gefolgt von fünfzig Zeilen Mumbo-Jumbo, wenn ein Anwender in einem Blog warum auch immer manuell eine falsche Blog-ID eingegeben hat. Zugegeben, ein erfundenes Beispiel.

Hier also meine persönliche Minimal-Anforderungen an Logfiles:

• So wenig wie möglich loggen, nichts loggen, wenn es nichts zu loggen gibt. Nicht gefundene Seiten in einem CMS gehören ins Monitoring, nicht ins Applikationslog.
• Logeinträge auf den "Konsumenten" zuschneiden; sie müssen den Konsumenten zur Handlung befähigen. Der Konsument ist i.d.R. ein Administrator, kein Entwickler.

Zum Schluß: Monitoring ist nicht identisch mit Logging, selbst wenn es Logs verwendet.

Mein Aktiver Lebensstil

Ich erinnere mich noch an die Coke-Werbung vor einem Jahr: Coke Zero, das ist der volle Geschmack mit Zero Zucker, so, wie das Leben sein soll. Na schön, der Süßstoff da drin ist auch nicht jedermanns Sache.

Wie verblüfft war ich da dieses Wochenende, als ich auf der Rückseite einer Flasche Coka Cola las: "Enthält Zucker, der Dir Energie für Deinen aktiven Lebensstil gibt." Und das knapp unterhalb eines Symbols, welches andeuted, ein Glas Coke (250 ml) versorge mich mit 8% des durchschnittlichen Tagesbedarfs an Kalorien. Hurra, denke ich mir, 8%, das ist ja nicht besonders viel, dann zisch ich doch die ganze Flasche wech!

Auf der anderen Seite spricht das Etikett eine andere Sprache: 250ml Coke enthalten 27g Zucker, was immerhin 29% des Tagesbedarfs deckt. Eine 1l-Flasche ist also schon locker bei 116% des empfohlenen Tagesbedarfs an Zucker. Anders herum: Wenn ich außer der Cola keinen Zucker zu mir nehme, muß ich nach dreieinhalb Gläsern Schluß machen. Da es praktisch unmöglich ist, irgend ein "processed food" ohne Zucker zu finden, sind drei Gläser genug. Wenn Coke also für aktiven Lebensstil gedacht ist, sollte sie nur noch gegen Vorlage eines gültigen Mitgliedsausweises eines Sportvereins ausgegeben werden. Tischfußball und Murmeln gilt nicht.

Moral von der Geschichte? Angriff ist die beste Verteidigung. Morgen früh bin ich dann mal wieder im Fitnesstudio, die Cola abarbeiten.

RailsConf 09...

Nur ein Post-It: DHH sprach auf der RailsConf 09. Ein interessanter Vortrag, was Geschichte und Zukunft von Ruby on Rails angeht.

Ach ja, nur eine Bemerkung: Warum heißt DHH nur noch DHH? Warum nicht David? Oder David Heinemeier Hanson? Ist das so wie bei den Straßen in England, die eine kürzere Nummer haben, je wichtiger sie sind? Oder bei den Huffman-Codes? Ich finde das diskriminierend: Mit ketchup bin ich offenbar vier Größenordnungen unwichtiger. Aber hey, wenigstens habe ich einen ganzen Namen! :)

Noch ein Vergleich: Mercurial vs. Git

Google Code bietet in Zukunft seinen Projekten die Möglichkeit, anstelle des in Würden ergrauten Subversion das DVCS Mercurial zu verwenden. Den Einstieg für den begleitenden Flamewar liefert ein Vergleich zwischen Mercurial und Git.

Der Titel des Vergleichs ist irreführend: Es werden nur zwei DVCS verglichen, und auch jeweils nur oberflächlich. Den Titel "Analyse" verdient das gedruckt knapp zwei Seiten lange Dokument ohnehin nicht, zumindest nicht, wenn man nicht Google ist und nicht aus der Sicht der Google spezifischen, Python-lastigen massiv verteilten Infrastruktur sieht.

Github Branch Merges

Beim Mitarbeiten an auf Github gehosteten Projekten kommt früher oder später der Punkt, an dem man a) seinen eigenen Branch aktualisieren muß, und b) die Arbeit eines anderen integrieren muß. Beide Aktionen sind grundsätzlich einfache git Merges.

Github bietet jetzt eine Fork Queue an, in der man bequem auswählen kann, welche Commits auf den ausgewählten Integrationsbranch geschoben werden sollen. Hier lauert eine Falle: Diese Funktionalität ist ein Interface zum git cherrypick, nicht zum git merge. Im Ergebnis wird der gewählte Commit (und zwar ausschließlich der gewählte Commit) auf den Integrationsbranch geschoben; es wird nicht gemerged.

Wird diese Technik angewendet, um einen eigenen fork mit der letzten Version vom "upstream" zu aktualisieren, entstehen parallele Branches, die u.U. nicht mehr automatisch zu mergen sind.

Ein einfaches Vorgehen, einen "fremden" Github-Branch zu integrieren, sieht wie folgt aus:

Vorbereitung:

1. git config remote.upstream_repo.url = (public) URL des fremden Respository

2. git config remote.upstream_repo.fetch = +refs/heads/*:refs/remotes/upstream_repo/*

3. git config branch.upstream.remote = upstream_repo

4. git config branch.upstream.merge = refs/heads/master

Fremden Branch laden:

1. git pull upstream

Merge:

1. git checkout my_integration_branch

2. git merge upstream

3. eventuelle Konflikte auflösen, ggf. einchecken

4. git push origin my_integration_branch

Mit dem letzten Kommando wird der integrierte Branch auf die Quelle des eigenen Repositories publiziert -- bei Github sollte das immer das eigene Github Repository sein. Pronzipiell läßt sich das aber auf beliebige Git-Repositories anwenden.

Git Commits zusammenfassen

Versionskontrollsysteme haben normalerweise ein Problem damit, einmal eingecheckte Versionen zu manipulieren, und das ist auch gut so (später mehr dazu).

Solange der Branch eines Entwicklers aber noch nur lokal auf seiner Maschine liegt, darf er noch manipuliert werden. Eine sehr praktische Lösung, wie eine Linie von experimentellen Commits in einen einzelnen, publikationswürdigen Commit zusammengedampft werden kann, ist git rebase --interactive.

Auf dem MadBlog gibt's einen kurzen Artikel git awesome-ness [git rebase --interactive], in dem das Vorgehen beschrieben wird.

Git Status in der Bash

Gerade auf git ready gefunden: Eine kleine Anleitung, wie der Status des aktuellen Repositories immer in der Shell angezeigt wird (hier der zugehörige Gist). Cygwin-User können damit den Git-Luxus auch auf Windows genießen. Hier meine PS1, die "visuell kompatibel" zu Cygwin ist:

PS1='\[\e]0;\w $(parse_git_branch)\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w $(parse_git_branch)\[\e[0m\]\n\$ '

Update 2013-02-12: Mittlerweile gibt es einen besseren Weg zum Ziel (siehe Git Status in der Bash, Teil 2).

Aus dem Nebel der Vergangenheit

Beim Rumspielen mit einen neuen Drucker ist mir ein altes Bild in die Hände gefallen, daß ich gleich mal drucken wollte. Leider ist es eher klein geraten.

Der Schnappschuß entstand vor vielleicht vier Jahren in der Nähe von Admond in Österreich unter Zuhilfenahme einer (Trommelwirbel!) Webcam. Das Gerät hat in sofern ein analoges Gefühl vermittelt, als daß ich den ganzen Urlaub lang geknipst habe, und erst zuhause nachsehen konnte, was davon überhaupt brauchbar war. Nach heutigen Maßstäben nicht viel: Die Auflösung war erbärmlich, und bei den Farben bin ich mir auch nicht so sicher.

Aber dafür ist es ganz gut gelungen, finde ich. Retro rulez.

P.S.: Nein, ich will nicht wieder mit dem Ding knipsen müssen.

Der Schwarm!

Mir fällt leider kein vernünftiger Titel ein: Unter dem Namen Ruby Swarms: Visualizing Rails & Git beherbergt igvita.com einige sehr interessante Visualisierungen von Coding-Aktivitäten. Sehr sehenswert!

Einen Git-Branch löschen?

Da schreibe ich gerade noch, wie praktisch es bei Git ist, einfach einen Teil des Repositories als separates Projekt herauszulösen, und dann das: Ein zum Hochschieben der Tags abgesetztes git push --all schiebt alles, was im lokalen Repository ist, auf den github, darunter auch das komplette alte Projekt, aus dem ich das Teilprojekt gerade erst herausgelöst habe. Wie peinlich.

Jetzt gibt es zwei Fragen: Warum tauchen plötzlich die alten Commits wieder auf, und wie werde ich sie wieder los?

Die Antwort auf die erste Frage ist leicht: Der alte Branch war nach dem Zurechtschneiden immer noch in dem Repository vorhanden, das früher einmal das Monsterprojekt beherbergte. Er war nur eben abgehängt. Normalerweise war der Branch nicht sichtbar, und da nach den Anweisungen von github vom frisch geglaubte Projekt mittel git push origin master explizit nur den master-Branch hochgeladen wurde, fiel nicht gleich auf, welches Problem da noch wartete: Das remote Repository war tatsächlich schlank, das lokale Repository aber nicht.

Den Schlammassel lokal wieder loszuwerden ist dann doch nicht einfach. SCMs sind sehr gut darin, sich Sachen zu merken, und nicht sehr kooperativ, wenn sie etwas vergessen sollen -- Git ist da keine Ausnahme. Kurz, ich habe ewig probiert, und nichts hat geholfen. (Letztlich sollte es helfen, alle Referenzen auf die ungewollen Commits zu entfernen. Also alle Branches und Tags löschen, die dahin zeigen.) Viel wichtiger ist natürlich, die ungewollt hochgeschobenen Daten vom github wieder zu löschen.

Die Lösung ist allerdings verblüffend einfach: Zuerst werden die ungewollten Objekte (Tags und ggf. Branches) auf einem remote repository (z.B. github) gelöscht, dann wird von da ein frischer Clone gezogen:

# tag "stoertMich" und branch "obsolete" loswerden

git push origin :stoertMich

git push origin :obsolete

# irgendwohin, wo der frische Clone aufwachen soll

cd ..

# ...und frisch clonen

git clone

Die Seite, der ich diese Einsicht verdanke, ist, verglichen mit den Ausmaßen des Problems, irritierend schlicht: github's Guide: Remove a remote branch. Allzu leicht übersieht man die Doppelpunkte, die praktisch die Lösung des Problems sind. Ich habe sie daher mal rot eingefärbt.

Ein kurzer Blick in die Packs (unterhalb von .git) verrät, daß da kein uraltes, gigantisches Monster mehr schlummert, sondern nur ein schlankes, blankes Repository mit dem exakt herausgelösten ehemaligen Teilprojekt.

Und wieder gerettet.

Git Ready!

Git ist das Nächste Große Ding zum Thema SCM, das ist offensichtlich. Noch ist zwar Subversion das Maß der Dinge, wenn es um populäre SCM-Systeme geht, ist aber schon lange nicht mehr unangefochten: Git hat die Linux-Entwickler und eine eindrucksvolle Gemeinde von Ruby (on Rails) Entwicklern auf seiner Seite. Wer mit RoR entwickeln will, braucht mittlerweile Git, und wer Git hat, braucht kein Subversion -- kann es aber weiterhin benutzen. Embrace and, äh, wie hieß das noch? Will Linus die Weltherrschaft? Mein Gott, erwartet uns hier ein neuer Flamewar?

Genug der Vorrede, frisch vom github kommt die Empfehlung für git ready, wo ab sofort täglich Informationen zu Git versprochen werden.

Was haben die Römer...

Ok, mir ist klar, daß jederman selbst auf YouTube danach suchen kann, aber sei's drum, ich will dieses Video einfach hier reinhängen:

Dabei sei gesagt, daß Monty Python einen Sack voll Sketche auf YouTube veröffentlicht (für den Fall, daß das noch nicht bis in alle Winkel dieses Planeten vorgedrungen ist). Ja, genau! Jede Menge Monty Python, direkt von Monty Python, mit dem Segen von Monty Python! Das ist er, der Grund, weshalb ich mein Modem gegen eine DSL-Leitung eingetauscht habe. (Na ja, das ist jetzt vielleicht etwas zu dick aufgetragen...)

Wie dem auch sei, empfehlenswert ist der Monty Python Channel auf jeden Fall.

Kann Dein SCM das?

Vor einer kleinen Ewigkeit, als ich noch dachte, CVS sei die beste Erfindung seit geschnitten Toastbrot (hey, ich war jung und brauchte das Geld für andere Sachen, z.B. Toastbrot!), habe ich begonnen, meinen selbstgeschriebenen Code in CVS Repositories einzuchecken. Leute, die mich damals kannten, hielten mich für, na ja, ein bißchen komisch, weil ich Sourcecode aufgehoben habe, der schon lange aussortiert war, aber ich bin sicher, sie haben heute andere, ganz neue Gründe dafür.

Aber das tut nichts zur Sache. Der Server ist schnell aufgesetzt, und so füllte sich das Repository mehr und mehr mit Daten. Dann fanden auf einmal alle Leute CVS ganz toll, also dachte ich mir, es wird Zeit, zu Subversion zu wechseln, bevor alle denken, ich wäre, na ja, nicht mehr komisch genug.

Gesagt, tun, getan. Bei der Gelegenheit habe ich dann entdeckt, daß ich in all den CVS-Jahren nur einen einzigen Branch angelegt habe, und den auch nur, um das mal zu probieren. Im Nachhinein hat sich das als gute Idee herausgestellt. Also, nur einen Branch zu verlieren, meine ich.

Aber Subversion macht alles besser, ich konnte das Repository leidlich gut importieren, und in Subversion kann man prima branchen. Und taggen. Und viele andere Dinge. Eine ganz neue SCM-Euphorie bemächtigte sich meiner, und ich fange an, Projekte zu bauen, nur, um irgendwas in Subversion zu importieren, zu branchen und zu taggen. Interessanterweise bin ich extrem selten zum branchen gekommen, und ich kann mich an keine Merges erinnern. Hängt wohl mit der gewöhnungsbedürftigen Semantik von Subversion zusammen. Aber ich will nicht undankbar erscheinen: Für Projekte, in denen man weder sinnvoll branchen noch sinnvoll mergen kann (also z.B. bei der Versionierung von Bildern), kann ich mir vorstellen, auch nochmal Subversion zu benutzen.

Und schließlich kam der Moment, den alle Subversion-Verwalter ab dem zweiten Aufruf fürchten: Das Repository wird unhandlich groß, und man entscheidet sich, es aufzuteilen. Selbstredend soll die History erhalten bleiben.

Die Idee ist einfach: Im Repository projekte liegen fünf Projekte project_uno, duo_twin_double, triproj, quadra und p5 friedlich nebeneinander, jedes soll jetzt in ein eigenes Repository. Gründe für diese Aufteilungen finden sich immer, deshalb verzichte ich auf die Aufzählung. Aber wie schneide ich aus einem Subversion-Repository einen Zweig Objekte?

Na ja, ich will's nicht schwierig machen: Es geht nicht. Die innere Struktur von Subversion erlaubt das Ausschneiden von Subtrees offenbar nicht. Irgendwo habe ich dann gelesen, daß aufgrund der inneren Struktur der Werte im Zusammenspiel mit dem mechanischen Aufbau der Physik die Beobachtung zu machen geht nicht. (An der Stelle habe ich Kopfschmerzen bekommen und aufgegeben.)

Szenenwechsel. Unser Subversion-Repository wird links auf einer Liege von der Bühne geschoben, überall rote Tinte, die Krankenschwester füllt ein Formular aus und guckt auf die Uhr, Auftritt git im schwarzen Rollkragen-Armani-OP-Kittel als jung-dynamischer Chefarzt (ohne Vorhang, wir haben's eilig). Kurzer Blick auf den Patienten, Organisation der Operation in die Phasen Zurechtlegen, Zuschneiden und Zumachen, und etwas Beeilung bitte, der nächste Patient wartet schon, das kann ja nun wirklich nicht so schwer sein. Der Patient bekommt ein Sedativ, und los geht's.

Zurechtlegen: In unserem Szenario haben wir fünf Projekte in einem Repository. Das wird erstmal kopiert:

# ~/projekte/ > cd ..

# ~/ > git clone projekte p1

Checking out files: 100% (1930/1930), done.

# ~/ > cd p1

# ~/p1/ >

Intermission: Es sei bei dieser Gelegenheit ausdrücklich festgestellt, daß dieser Schritt wirklich extrem wichtig ist. Wir haben vor, alles bis auf ein Unterverzeichnis aus dem Repository unwiederbringlich zu löschen. Mit anderen Worten: Alles außer dem Verzeichnis, was wir im nächsten Schritt auswählen, wird gleich weg sein.

Stimme aus dem Off: Mach lieber eine Kopie mehr als eine zuwenig. Ehrlich. Bitte. Mach. Das. Sorgfältig. Und. Richtig. Nicht vergessen, wir reden hier von git: Schieb eine Kopie auf github, oder schick sie einem Kollegen, oder Deinem Bruder, oder Deinem Friseur, egal. Nur hab nicht im nächsten Schritt die einzige Kopie des Repositories unter'm Messer. Du würdest es bereuen.

Und weiter.

Zuschneiden: Ein Blick in das Repository verrät uns, daß wir es mit einer exakten Kopie des unter ~/projekte gespeicherten Repositories zu tun haben. Wir finden darin ein Verzeichnis project_uno, in das unsere fleißigen Entwicklerameisen emsig tonnenweise Code geschaufelt haben (natürlich haben wir selbst mindestens die Hälfte davon geschrieben, sonst dürften wir nicht so über unsere netten und geschätzten Kollegen reden). Aus diesem Verzeichnis project_uno machen wir jetzt ein eigenes Repository:

# ~/p1/ > git filter-branch --subdirectory-filter project_uno -- --all

(Meldungen von git hier, die abzutippen oder neu zu erfinden ich zu bequem bin, die der geneigte Zuschauer bei dieser Folge aber bitte genauestens zu lesen, zu verstehen und als nicht weiter kompliziert einzustufen hat.)

Genau, das war's schon. Ein einziger gekonnter Schnitt, und wir sind fertig. Schneller als ein Blinddarm, soviel ist sicher.

Zumachen: Zunächst einmal kümmern wir uns um die remote Referenzen: Das neue Repository einfach per push zu publizieren kann unangenehme Folgen haben, aber auch ein pull könnte uns Probleme bereiten. Da ich nicht dumm genug bin, das auszuprobieren, glaube ich den Warnungen und entferne erstmal die Remote-Verbindungen:

# ~/p1/ > git remote show

origin

# ~/p1/ > git remote show origin

* remote origin

   URL: /home/me/projekte

   Remote branch merged with 'git pull' while on branch master

     master

   Tracked remote branch

     master

# ~/p1/ > git remote rm origin

So, jetzt kann es nicht mehr so einfach passieren, daß eine versehentlich verschüttele Kaffeetasse ein git push auslöst und unser Original verschandelt, von dem wir geklont haben. Ok, ganz ehrlich, viel kann da nicht passieren, aber sicher ist sicher. Wir haben jetzt ein schickes Repository, was wir unsererseits gleich mal klonen und verteilen können.

Nachdem wir wissen, wie's geht, wiederholt der Pförtner die Schritte für die anderen vier Projekte, die Vorstellung ist vorbei, das Original-Monster-Repositories unterschreibt noch schnell, in Zukunft keine Änderungen mehr zuzulassen und wird in ein Taxi am Bühneneingang geschoben, von wo es nie mehr zurückkehrt (es lebt jetzt mit einer Frau und drei Kindern auf Hawaii und arbeitet da in einer Telefonmarketing-Firma, ist aber ansonsten recht glücklich), und die jetzt getrennten siamesischen Fünflinge gehen gemeinsam auf Welttournee (sie sind sehr erfolgreich, allen zu erzählen, wie wunderbar es sicht getrennt lebt, und treten gemeinsam bei praktisch jeder Fernsehtalkshow auf, ohne jemals irgendetwas von Bedeutung getan zu haben). Git ist schon wieder auf dem Golfplatz und erklärt jedem, der es hören oder nicht hören will, wie unnütz und rundheraus dumm und häßlich Subversion und der Rest der häßlichen Verwandschaft ist, und wie glücklich alle sein können, daß es ihn gibt, aber da hört schon keiner mehr hin, weil alle an der Bar sitzen und sich über nervige Typen in Armani-Anzügen auslassen.

Na, das war ja mal Drama. Also, jetzt mal ganz ehrlich: Kann das Dein SCM?

Git und Windows: Elf Schritte (und in paar Fotos)

Die netten Leute von github haben sich mal aufgerafft und eine Kurzanleitung zusammengebaut, mit der jeder, der in der Lage ist, einen Brief zuzukleben ohne sich Gummierung in die Augenbrauen zu schmieren, auch die Grundfunktionen von git unter Windows in Betrieb nehmen kann.

Das Schöne daran: Im Gegensatz zu den üblichen Methoden verzichtet diese Anleitung auf Cygwin (was vielen Windows-Nutzern den Zugang erleichtern sollte). Allerdings will ich nicht verschweigen, daß man mit einem unixoiden Unterbau noch mehr Freude an git haben kann...

Traumreisen ohne MBP?

Ja, da kann man schon ins Träumen kommen: Apples neues 17" MacBook Pro (MBP - wer erfindet eigentlich immer diese Abkürzungen?) erweckt erstmal den Eindruck, daß diesmal wirklich alles richtig gemacht wurde. Ein großer Bildschirm, diesmal auch entspiegelt erhältlich, viel RAM, aktuelle Prozessoren, aktuelle GPUs, ein schickes und schlankes Gehäuse, und obendrauf sagenhafte 8 (acht!) Stunden Laufzeit. Na, ist das ein Grund, sich dieses Jahr kein neues Auto sondern einen Mac zu kaufen?

(Oh, sorry, ähnliche Kommentare haben im Anschluß an den entsprechenden Artikel auf Golem natürlich wieder den üblichen Flamewar gestartet. Da halte ich mich lieber raus.)

Offenbar nutzt Apple die Erfahrungen aus dem iPod-Bereich jetzt auch für die Notebooks. Aber, typisch für mein ambivalentes Verhältnis zu meinem Lieblings-Hardwarehersteller, irgendwie habe ich das Gefühl, zum Schluß doch noch eine Kröte schlucken zu müssen: Der sagenhafte Monster-Akku ist fest eingebaut. Was sie sich wohl dabei gedacht haben? Ist der Akku leer, hilft kein Ersatzakku, egal, wie weit die nächste Steckdose entfernt ist. Und: Ist der Akku verschlissen, muß ein neuer bei Apple eingebaut werden.

Über die Kosten (laut dem heise-Artikel "Macworld: 17-Zoll-Macbook mit mattem Display"179 Euro) will ich hier mal nicht meckern, das Gerät wendet sich an betuchte Anwender, und für 8 Stunden Laufzeit und immerhin 1000 Ladezyklen ist das nicht zu teuer. Im Grunde sollten die Ich-laß-das-Preisschild-dran-Typen jetzt unglücklich werden.

Nein, das Problem ist: Wenn man so eine Maschine besitzt, will man damit arbeiten. (Ich würde es wollen.) Und ein toter Akku sorgt in diesem Falle dafür, daß die Maschine (und alle Daten darauf) aus dem Büro muß, möglicherweise für Tage (und dann auch noch fremden Leuten zugänglich sind). Das kann schon unangenehm werden.

Wie wär's mit einem Kombi-Angebot? Zwei Wochen Urlaub auf Hawaii, in der Zeit macht Ihr MBP eine Wellness-Kur in Kalifornien. Flug und Hotel nicht inklusive.

Verteiltes SCM

Eigentlich suchte ich ja nach einem Hoster für Ruby on Rails-Projekte. Aber wie immer im Leben passiert dann etwas Anderes. In diesem Falle stolperte ich über ein Video: Tech Talk: Linus Torwalds on git. Das ist wirklich bemerkenswert unterhaltsam, auch wenn ich zugeben muß, daß in etwas mehr als einer Stunde nur zwei Aussagen von Substanz getätigt werden:

• SCM muß verteilt sein
• Performance ist wichtig

Inhaltlich ist über den Rest des Videos nicht viel zu sagen: Ein netter, junger, begrenzt freundlicher Mann produziert sich mit sichtbarer Erfahrung auf der Bühne, ein Haufen Techies sitzen drum rum. Man merkt nach einiger Zeit, daß man es mit Google-Leuten zu tun hat: Keine anhimmelnden Gesichter, nur blanke Skepsis.

Erinnerung: Wenn ein Techie einem anderen Techie begegnet, von dem auch die Großmutter seiner Frau schon mal gehört hat, der also bereits mehrfach mal in den üblichen Massenmedien erwähnt wurde, legt er seine Haltung gegenüber dem Fremd-Techie im Vorfeld fest, und zwar entweder auf "Elvis!!!(kreisch)" oder auf "Du hast keine Ahnung, wie wir das hier im Maschinenraum machen", und behält diese Einstellung eisern zumindest bis zum Ende der Konfrontation bei.

Zurück zum Thema.

Die Argumente, warum ein SCM unbedingt verteilt sein muß, sind leider etwas verwaschen (obwohl ich die gleiche Meinung habe, mit der Abweichng, daß ich schon gerne ein Master-Repository habe, wenn auch nur, um einen zentralen Referenzpunkt zu haben) und mengen sich mit der Argumentation, warum Performance wichtig ist: Weil dann eine andere Arbeitsweise möglich wird. Aber natürlich ist mir unten in meinem Maschinenraum auch noch kein besseres rationales Argument eingefallen.