Ketchup Log

Einmal Commit und wieder zurück

2011-10-25T16:51:00.001+02:00

Gelegentlich soll es ja passieren, daß man Sachen in sein Git Repository eincheckt, die man nicht einchecken will. Zum Beispiel hat eine Datei mal falsche Rechte, was nicht sofort auffällt, aber unschön ist. Was tun, wenn schon committed wurde? Oder wenn gar die Commit-Message falsch war? Richtig: Man guckt erstmal, was zum Thema bei stackoverflow steht. Und das ist:

Der einfachste Weg: Egal, ein Commit hinterher, der die Situation bereinigt. Vorteil: Unkompliziert. Nachteil: Es sieht nicht gerade hübsch aus. (Ok, das steht nicht bei stackoverflow, das ist also mein Beitrag zum Weltwissen.)

Zweite Variante:

git commit --amend

Vorteil: Git läßt einen die Commit-Message nochmal eingeben. Nachteil: Die falsche Datei kann man so nicht korrigieren.

Dritte Variante:

git reset --soft HEAD^

gefolgt von der Korrektur und einem abschließenden

git commit -c ORIG_HEAD

Vorteil: Es können wirklich alle Änderungen ausgeführt werden. Mit -c ORIG_HEAD werden Author-Informationen und der Timestamp vom ursprünglichen Commit übernommen.

Wie man nicht bei Auktionen steigern sollte

2011-10-23T10:26:00.001+02:00

Aus aktuellem Anlass zwei Dinge, die man nicht tun sollten, wenn man ein wertvolles Schiller-Manuskript per Auktion für sein Museum ersteigern will:

Interesse im Radio ankündigen. Es ist nicht weise, der Welt zu verkünden, daß das Objekt der Begierte eine absolute Sensation ist -- das ist die Aufgabe des Verkäufers.
Finanzrahmen ankündigen. Die stolze Aussage, man habe zweihundertausend Euro für die Aktion zusammengescharrt, sagen jedem Konkurrenzbieter, wieviel Geld er braucht.

An dieser Stelle steht das Scheitern der geplanten Aquise eigentlich schon fest. Folglich ist es unsinnig, sich anschließend zu beschweren, das Bieter aus der Privatwirtschaft mehr Geld für den Ankauf aufbringen konnten.

Bleibt die Frage: Was passiert jetzt mit den zweihunderttausend Euro?

Über Versionsnummern

2011-10-21T17:57:00.000+02:00

Dritter Anlauf: Über Versionsnummern. Wie jedem schnell klar wird, der in einem größeren Softwareprojekt mit Versionsnummern zu tun hatte, ist das Thema kompliziert. In erster Linie, weil man schnell übersehen kann, daß ein einzelnes Stück Software viele Versionsnummern hat.

Da wäre zunächst einmal die Produktversion. Das ist die Bezeichnung, die draußen draufsteht. Wenn Microsoft ein Windows 7 verkauft, heißt das nicht, daß es sieben Versionen von Windows gibt. Vielmehr heißt es, Microsoft eine "Aggregation" aus Softwarekomponenten unter dem Namen "7" verkauft, die sich funktional von allen anderen Aggregationen unterscheidet. Entscheidend ist hier, daß 7 "anders" ist als beispielsweise Vista oder XP.

Eine Produktversion kann man eng oder lose definieren. Im Idealfall beschreibt eine Produktversion genau eine Kombination aus Komponentenversionen, aber das kommt letztlich darauf an, was Marketing und Rechtsabteilung draus macht. Wir haben uns mittlerweile an verwaschene Produktversionen gewöhnt, ja wir erwarten mittlerweile, daß eine Software regelmäßig kostenlos aktualisiert wird, womit Aussagen wie "Das ist ein nacktes Windows 7." an zwei unterschiedlichen Tagen zwei unterschiedliche Softwarestände beschreiben.

Technische Versionen sind da spezifischer: Sie beschreiben einen exakten Sachverhalt. Die Version 2.2.21 des Apache Webservers beispielsweise beschreibt einen exakten Stand von Quelltextversionen. Mit der Versionsnummer als Schlüssel läßt sich daraus jedes einzelne Zeichen in jeder einzelnen Zeile jeder einzelnen Datei der Software ableiten. ("Holistisch" klingt hier zwar gut, stimmt aber leider nicht. Trotzdem habe ich das Wort jetzt in meinem Artikel.) Je nachdem, wie sorgfältig die Entwickler bei der Festlegung der externen Abhängigkeiten waren, läßt sich auch die technische Version aller verwendeten Softwarepakete ableiten, obwohl die Schärfe der Definition aus praktischen Gründen an den Rändern immer weiter abnimmt.

Aber so vernünftig das auch klingt: Diese Versionsnummern werden willkürlich vergeben. Die Regeln zur exakten Bildung der Versionsnummer mögen strenger sein, aber im Grunde ist die Versionsnummer 2.2.21 nichts als ein einzelnes Symbol, ein Name, die einem spezifischen Quelltextstand bewußt zugeordnet wurde. Am besten paßt hier eigentlich die Bezeichnung "Release".

Anders die Buildnummern und die Versionsnummern einzelner Dateien im Source Code Management. Die Versionsnummern einzelner Dateien folgen keinem bewußten Willen, vielmehr klettern die Versionsnummern einiger Dateien schneller als die anderer. Teile des Codes bleiben jahrelang unberührt, andere werden im Minutentakt verändert. Die Versionen einer einzelnen Datei zu nummerieren hat keinen Wert und verleitet zu falschen Annahmen (weshalb sich verteilte SCMs das Leben leichter machen und es gleich ganz unterlassen, Versionen zu nummerieren). Buildnummern hingegen steigen kontinuierlich an, daher läßt sich aus zwei vorhandenen Nummern eine Reihenfolge der Builds ableiten. Nach wie vor ist es natürlich gefährlich, eine andere Bedeutung in diese Nummern zu interpretieren als die, daß Build 2 nach Build 1 ausgeführt wurde, insbesondere sind alle Annahmen zur Korrelation zwischen Nummer und Qualität unsinnig.

Wenn man über Versionsnummern spricht, muß man also wissen, was man damit meint. Benutzer von Software meinen, wenn sie von Versionen sprechen, oftmals die Produktversion, seltener eine technische Version ("Release"), normalerweise nicht die Buildnummer und praktisch nie die Dateiversion.
Es sollte klar sein, daß Produktversionen und technische Versionen sowie technische Versionen und Build- oder SCM-Versionen nur lose zusammenhängen und nicht synonym verwendet werden können. Wenn jetzt continuous builds auf traditionelle Testcenter treffen, wird die Sache spannend genug für einen eigenen Artikel.

Raubkopien

2011-10-07T16:03:00.001+02:00

Und wieder einmal zeigt sich, daß die größte Gefahr für ein IT-System nicht von außen, sondern von innen kommt: heise.de: Größter Fall von Softwarepiraterie weltweit.

Spaß beiseite: In großen Unternehmen ist das Problem "Unterlizensierung" wahrscheinlich viel schwerer in den Griff zu bekommen. Undurchsichtige Lizenzvarianten, Interoperabilitätsprobleme, Mondpreise und die weitverbreiteten lokalen Adminrechte machen es selbst engagierten IT-Abteilungen schwer, ihr Netz "sauber" zu halten. Aber von den vier Problemen liegen eigentlich 3,5 im Verantwortungsbereich der Softwarehersteller und sind entweder gewollt oder lassen sich nicht mehr einfach abschaffen.

Die Situation ist offenbar unbefriedigend: Der Einsatz von Raubkopien ist ein Risiko (bezeichnenderweise sind die gefundenen Produkte von Adobe und Autodesk, Quasi-Monopolisten in ihren Segmenten und nicht gerade Preisbrecher). Ich vermute ja, daß früher oder später SaaS zu bezahlbaren Preisen sich den Markt mit massenhafter Niedrigpreissoftware teilt, Hochpreissoftware wird's nur noch in Segmenten geben, die für Raubkopierer zu klein sind.

P.S.: Preis sagt nichts über Qualität, und Qualität nichts über Akzeptanz.

Lieferumfang

2011-09-28T13:22:00.000+02:00

Wenn es darum geht, eine entwickelte Software auszuliefern, gibt es zwei Extreme: Eine Lieferung der kompletten (virtuellen) Appliance, am besten versiegelt, und eine Lieferung von nackten Komponenten mit Handbuch. Die Realität ist irgendwo dazwischen: Die Appliance ist sicherlich ein für Hersteller und Support attraktiv, verbietet sich aber oft durch Probleme bei der Integration in bestehende Infrastruktur, und nackte Komponenten sind nicht unbedingt das, was Kunden kaufen wollen.

Hierzu eine Anmerkung: Der Lieferumfang eines Produktes sollte immer so strikt wie möglich definiert sein, also nur die absolut notwendigen Bestandteile umfassen. Beispiel: Wenn ich eine Web-Applikation liefere, dann enthält mein Lieferpaket im Idealfall nur die unvermeidlichen Bestandteile meine-webapp.war und Handbuch-für-meine-webapp.pdf, in dem steht, auf welcher Plattform meine-webapp.war deployed werden kann.

Warum? Weil man für alles, was man liefert, verantwortlich ist. Im schlimmsten Falle also für jeden Programmfehler im verwendeten Tomcat, sofern man sich erweichen ließ und einen Tomcat ins Lieferarchiv gepackt hat. In diesem Falle muß man also regelmäßig Updates der ursprünglichen Lieferung schicken, die alle getestet werden müssen -- und obwohl die eigene Kreation sich möglicherweise schon lange nicht mehr geändert hat, entsteht hier ein regelmäßiger Aufwand. Ist man mit den Verträgen ungeschickt, sind womöglich Probleme mit der Gewährleistung nicht ausgeschlossen. Schön, das ist ein Schreckensszenario, welches so schnell nicht eintreten sollte, aber es bleibt ein potentielles Problem.

Das hat auch eine Auswirkung auf die Softwareentwicklung: Der Verzicht auf das "Anpassen" (aka "customizing") der Plattform vereinfachen Deployment und Betrieb und erlaubt, die Plattform "out-of-the-box" zu verwenden. Damit entfällt ein wichtiger Grund, die Plattform mitzuliefern, den Lieferumfang deutlich strafft.

Über Keyword Substitution

2011-09-20T22:30:00.000+02:00

Mal wieder Git, aber diesmal ein Thema, was Git nicht kann: Keyword Substitution. Wer RSC, CVS oder SVN kennt, ist früher oder später über die praktischen kleinen Helferchen gestolpert, die in jede Datei die Versionsnummer fest einbrennen, und auch ältere SCM-Fossile verfügen über diese Fähigkeit. Ich selbst habe in meiner Zeit als CVS-Anwender in jeden Dateiheader sklavisch ein $Id$ gehackt und das gleich zur persönlichen Best Practice erklärt, denn schließlich ist es ja wichtig, jederzeit zu wissen, in welcher Dateiversion man unterwegs ist. Daher hat es mich etwas verstört, daß Git nicht nur keine Keyword Substitution kennt, sondern die Git-Entwickler sich auch noch strikt weigern, eine solche einzubauen. Was denken die sich dabei?

Wie sich herausstellt, haben sie gute Gründe -- am einfachsten von Linus Torvalds in einer ausreichend undiplomatischen eMail zusammengefaßt. Die Argumente im einzelnen:

Zunächst einmal ist klar, daß externe Tools von $Id$-Strings verwirrt werden, schließlich haben die keine Möglichkeit, die zu vergleichenden Texte ohne die Substitution zu vergleichen. Aber das ist vielleicht nicht so schlimm, denn erstens kann man ja alle zu vergleichenden Texte vorher durch einen Filter schicken, der die Strings entfernt -- genau so wie es CVS und SVN beim Einchecken tun.

Der zweite Punkt leuchtet auch sofort ein: Ein SCM, welches eine Keyword Substitution vornimmt, muß genau wissen, was man gerade eincheckt. Warum ist das ein Problem? Wir wissen ja schließlich auch, daß man Binärdateien nicht mergen kann, und schrecken trotzdem nicht vor dem Mergen zurück! Der Grund liegt in der Art, wie ein SCM Dateien mit Keywords speichern muss: Nämlich erstaunlicherweise ohne Keywords! Die Keywords werden tatsächlich während des Auscheckens ersetzt, da ansonsten zwei Versionen eines Textes garantiert unterschiedlich wären, selbst wenn sich inhaltlich nichts geändert hat. Irrt sich jetzt das SCM beim Einchecken, so zerstört es die zu sichernde Datei und speichert einen großen Haufen Müll, was im schlimmsten Falle erstmal niemanden auffällt (unbedingt mal ausprobieren: Ein PDF in VSS einchecken -- wird als 7-Bit-EBCDIC-Text erkannt und rettungslos verstümmelt). Dem Nutzer wird das erst bewußt, wenn er mal Dateien aus dem SCM abrufen will. Aber dann sind seine vorherigen Bemühungen bereits zerstört.

Der dritte Punkt klingt erstmal etwas altklug: Natürlich weiß das SCM viel besser, welche Version ich gerade ausgecheckt habe, aber ich will das doch auch sehen! Nun, tatsächlich kann ich das ja auch sehen, aber die Frage ist: Wann muß ich es wissen? Nicht beim Schreiben von Code, denn da arbeitet man ohnehin auf dem HEAD. Interessant wird die Version einer Datei bei der Analyse von Code, und hier spielt die Version einer einzelnen Datei eine verblüffend geringe Rolle. Wichtiger ist hier der Kontext: Welche Dateien gehören zusammen, welche Änderungen bilden einen inhaltlich zusammengehörigen Change Set? An dieser Stelle klickt wieder ein Puzzleteil an die richtige Stelle: Git hat ohnehin keine handlichen Versionsnummern, nur SHA1-Identifier für Change Sets, und die vermißt wirklich niemand im Quelltextheader.

Nun, vielleicht nicht im Quelltextheader, aber wie ist es mit der "About this Application"-Box? Ah, richtig, die ausgelieferten Versionen müssen natürlich irgendwie kenntlich gemacht werden. Aber hier kommt ein anderes Prinzip zum Tragen: Die Produktversion hat nichts mit der technischen Version des SCM zu tun. Wirklich nicht. Und wenn die Produktversion nicht von der SCM-Version abhängt, muß die SCM-Version auch nicht im Produkt stehen. Hier bieten sich Build-Nummern an, die ihrerseits Tags im SCM steuern (das SCM ist also nicht das führende System).

Zuletzt aber noch ein Argument, für das ich im Moment kein Zitat finde (auch das ist von Torvalds, nur beweisen kann ich's nicht): Ein SCM muß Dateien immer unverändert speichern, und wenn sich zwei Versionen einer Datei nur in der Versionsnummer unterscheiden, hat das SCM einen fundamentalen Fehler. Warum? Weil ein SCM schließlich Inhalte speichern muß und nicht einfach nur Nummern hochzählt (das können Taschenrechner besser). Folglich muß ein funktionierendes SCM zwei Dateien, die sich nicht unterscheiden, immer die selbe Versionsnummer zuweisen.

An dieser Stelle muß man erstmal kurz anhalten und ausführlich nachdenken. Es stimmt, natürlich, und es hat Konsequenzen: Demnach sind nicht nur die Keyword Substitutions schlecht, sondern auch alle automatischen Umkodierungen (Unix/DOS, ASCII/UTF-8, ...). Und wer schon ein Weilchen mit verschiedenen Plattformen und SCMs zu tun hatte, weiß, wie viele Probleme sich mit dieser Regel in Luft auflösen.

P.S.: Ich bin sehr froh, recht schnell eingesehen zu haben, daß Torvalds Recht hat. Ich wäre nicht gerne Anhänger einer furchtbaren Idee, noch dazu idiotisch, welche seit Dekaden fundamental fehlgeleitete SCM-Designs bestimmte. Denn ich habe das Licht gesehen. Leider muß ich jetzt zurück in den Keller zu SVN.

Git auf CentOS 5.x

2011-05-19T12:59:00.000+02:00

Warum ist Git eigentlich kein Bestandteil von RedHat Enterprise Linux? Wäre es Bestandteil von RedHat, dann wäre es auch Bestandteil von CentOS, und dieser Eintrag wäre überflüssig. So aber ist es leider immer noch etwas anstrengend, git auf RHEL und Derivate zu bekommen.

Auf superuser.com gibt es eine Kurzanleitung, die ein Vorgehen beschreibt. Allerdings habe ich noch einen fertigen gist, den ich, wie ich stolz anmerken möchte, schon lange vor besagter Kurzanleitung aus Informationen von Howto-Linux zusammengestellt habe (damals noch für CentOS 5.2). Das Script kann mit

wget https://gist.github.com/raw/146206/bb90b1bff3abb9ac6843aba2b9cce89f36aebeff/install_git_on_centos.sh

heruntergeladen werden und sieht dann so aus:

Zuerst sollte die Proxy-Einstellung und die gewünschte Git-Version geprüft und ggf. angepaßt werden, dann wird das Script noch mit chmod +x install_git_on_centos.sh ausführtbar gemacht, und kann dann gestartet werden. Wenige Minuten später ist ein Git in der gewünschten Version installiert.

Noch ein Nachwort zur veralteten Version: Der gist wird von mir gelegentlich aktualisiert. In der Vergangenheit hat es bei mir keine Probleme beim Zusammenspiel der verschiedenen Git-Versionen, also aktualisiere ich das nur recht selten.

Nachricht an mich selbst: Pro Git lesen

2010-03-10T23:07:00.000+01:00

Heute flatterte mal wieder ein Update vom Github Blog herein, in dem auf Neuigkeiten im Pro Git Blog aufmerksam gemacht wurde. Die Liste liest sich recht eindrucksvoll:

Merges rückgängig machen
Smart HTTP Transport
Rerere
git bundle

Um all die coolen Features benutzen zu können, braucht man, wie immer, ein halbwegs modernes git: zumindest der Smart HTTP Transport ist neu in Version 1.6.6. Ach ja, aktuell ist im Moment (10.3.2010) Version 1.7.0.2. Ist also nicht zuviel verlangt.

Jedenfalls empfiehlt sich Pro Git wieder mal allen Git-Nutzern.

Emacs und Git

2010-01-22T11:00:00.002+01:00

Nach langer Abstinenz mal wieder ein kurzer Blog-Eintrag. Diesmal zu ... Git! Unter dem Titel Working with Git from Emacs hat Alex Ott eine Übersicht über verschiedene Git-Integrationen in Emacs aufgelistet.

Also, Freunde des Emacs, es gibt keinen Grund, den Vim zu fürchten!

Täglich stempeln gehen

2009-11-03T11:54:00.002+01:00

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.

2009-09-12T13:29:00.004+02:00

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...

2009-08-25T11:12:00.002+02:00

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

2009-07-21T11:59:00.004+02:00

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

2009-07-17T08:15:00.005+02:00

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:

Auch gute Ideen brauchen Werbung.
Nutzerbasis ist wichtiger als Marge.
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

2009-07-09T09:11:00.006+02:00

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

2009-07-07T09:03:00.003+02:00

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

2009-06-25T12:44:00.003+02:00

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

2009-06-22T10:53:00.003+02:00

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

2009-06-17T10:53:00.002+02:00

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

2009-05-29T10:54:00.004+02:00

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

2009-05-25T10:14:00.003+02:00

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...

2009-05-08T11:08:00.002+02:00

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

2009-04-29T09:47:00.003+02:00

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

2009-03-26T10:30:00.002+01:00

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

2009-03-03T13:09:00.008+01:00

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

2009-02-26T12:32:00.002+01:00

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\$ '

Aus dem Nebel der Vergangenheit

2009-02-06T23:20:00.002+01:00

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!

2009-01-29T01:01:00.002+01:00

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?

2009-01-21T00:28:00.006+01:00

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!

2009-01-20T08:39:00.003+01:00

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...

2009-01-18T17:22:00.007+01:00

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?

2009-01-16T22:27:00.006+01:00

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)

2009-01-16T00:57:00.002+01:00

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?

2009-01-12T14:40:00.005+01:00

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

2009-01-12T08:18:00.003+01:00

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.

Eine Lanze für HAML

2008-12-18T09:50:00.007+01:00

Was ist denn nun so besonders an Ruby? Ist das nicht nur eine weitere Scriptsprache? Was soll der ganze Hype, und wann ist er wieder vorbei? Diese Frage stellen zum Beispiel Java-Entwickler gerne, und wärmen anschließend gleich mal wieder die Vorurteile der C/C++ Entwickler gegenüber Java Ende der 1990er Jahre auf. Ohne es zu wissen, nehme ich an.

Nun, Ruby ist tatsächlich nur eine Scriptsprache; sogar Python (als zweite ernstzunehmende moderne Scriptsprache in der Unix-Welt) macht mehr Zugeständnisse an Performance-Vorbehalte der Entwickler und Entscheider aus dem Compiler-Lager. Aber wer Ruby sagt, meint heute größtenteils Ruby on Rails (auch wenn im Schatten von RoR ein ganzer Garten anderer Ruby-basierter Frameworks gewachsen ist: ich weiß erstmal von Ramaze, Camping, Merb und Hobo, ohne sie wirklich ausprobiert zu haben). Und das Markenzeichen von RoR ist die extrem kurze Entwicklungszeit für Applikationen. (Jaja, neben DRY, Convention over Configuration und anderen Schlagworten.)

Aber RoR-Applikationen haben trotzdem einen Pferdefuß: Irgendwann schlägt die Stunde der Views, und die bauen aus HTML-Templates und -Schnippseln Seiten und Seitenfragmente für den Browser zusammen. Das Werkzeug der Wahl ist normalerweise ERb, was, ganz in der Tradition der JSPs, Code in HTML einbettet. Das Resultat ist oftmals unübersichtlich, und die generierten HTML-Seiten sind nur so gut wie die Templates. Darstellungsprobleme im Browser? Ein Tag verschluckt? Schachtelung der XHTML-Elemente falsch?

Wer kennt das nicht? Nun, wer HAML verwendet.

HAML ist (wieder mal) eine neue Template-Sprache. Ähnlich Python, welches Entwickler zwingt, nicht nur sauberen, sondern schönen Code zu schreiben (in dem Sinne in dem die äußere Form des Quelltextes seine logische Struktur widerspiegelt), zwingt HAML den Designer, nicht nur saubere, sondern schöne Views zu bauen. Das Beispiel von der HAML-Frontseite läßt leider nur erahnen, was möglich ist:

Aus

<table>

<tr>

<th>Name</th>

<th>eMail</th>

</tr>

<% @adressen.each do |addr| %>

<tr>

<td><%= h(addr.name) %></td>

<td><%= h(addr.email) %></td>

</tr>

<% end %>

</table>

wird in HAML

%table

  %tr

    %th Name

    %th eMail

      - @adressen.each do |addr|

  %tr

    %td= h(addr.name)

    %td= h(addr.email)

Ist ja dann schon ein Stück kürzer. Aber das Beispiel ist ja auch recht kurz. Was passiert jetzt, wenn die Zeilen abwechselnde Stile verwenden sollen?

<table>

<% style="odd" %>

<% 10.range.each do |num| >

<tr class="<%=style%>">

<td>line <%=num%</td>

</tr>

<% style = (style == "odd" ? "even" : "odd") %>

<% end >

</table>

wird hier einfach zu

%table

  - 10.range.each do |num|

    %tr{:class=>"#{cycle('odd','even'}"}

      %td

        line

        = num

[Update](Danke an neuholger für die Vereinfachung!)[/Update]

Ist doch irgendwie... einfach zu lesen, oder? Die Ersparnis in Zeilen ist bei diesem einfachen Beispiel noch nicht so beeindruckend (6 Zeilen zu 9 Zeilen), kann bei umfangreicheren Views aber schnell wachsen. Und vor allem geht eben nie die Zuordnung einer Zeile zu einem logischen Block verloren.

Zudem generiert HAML immer sauber formatiertes HTML: Auch Partials, die ja ihrerseits "ganz links" anfangen, bringen das System nicht aus dem Tritt. Und zuletzt gibt's als Zugabe zu HAML noch dessen CSS-Seite, SASS. Aber das ist wieder eine eigene Geschichte...

[Update](Apropos CSS: Damit das Beispiel von oben auch wirklich funktioniert, braucht man natürlich das passende CSS dafür -- wie jenes aus neuholgers Kommentar.)[/Update]

~~Zum Schluß: Wer jetzt unsicher ist, muß die Katze nicht im Sack kaufen. Hamton Catlin hat netterweise The Lab gebaut, in dem man HAML und SASS online ausprobieren kann.~~ Viel Spaß!

[Update] Updates vom 9.8.2011: Vereinfachung von neuholger eingebaut (Danke!). Zudem scheint es das HAML/SASS Lab nicht mehr zu geben, und die offiziellen Seiten von HAML und SASS sind umgezogen. [/Update]

Subversion-Repositories nach Git migrieren

2008-12-06T06:46:00.004+01:00

Nachdem man sich entschlossen hat, mit Git zu arbeiten, steht man vor einem weiteren Problem: Was macht man jetzt mit den alten Subversion-Repositories? Natürlich kann man weiter Subversion verwenden, es ist schließlich kein schlechtes System. Aber warum sich mit zwei parallel zu pflegenden Systemen herumschlagen?

Auf Simplistic Complexity gibt's eine sehr schöne Kurzanleitung, die im Wesentlichen aus drei Schritten besteht:

Anlegen einer Textdatei für das User-Mapping
Importieren des SVN-Repositories in Git
Exportieren des importierten Repositories auf den Git-Server

Das sieht dann auf der Shell so aus (die Datei usermapping.txt enthält die Zuordnung von SVN-Namen zu git-eMail-Adressen in der Form "svnid = Git User <gituser@email.com>", eine Zuordnung pro Zeile):

mkdir myproject

cd myproject

git svn init http://myserver/svn/myproject/trunk/ --no-metadata

git config svn.authorsfile usermapping.txt

git svn fetch

git clone --bare .git ../myproject.git

Das in myproject ausgecheckte Subversion-Git-Gemenge kann man jetzt bedenkenlos löschen; das blitzblanke myproject.git wird auf den Git-Server expediert und kann von da aus verwendet werden.

Im Blog wird noch der eine oder andere Haken diskutiert, hauptsächlich, weil Git jedes Commit einem User zuordnet, einige Subversion-Repositories aber keinen User haben, dem der erste Commit zugeordnet ist. Nun, das war bei mir glücklicherweise nicht der Fall, und der Transfer meiner Source-Repositories von Subversion zu Git war bisher schmerzlos und schnell.

Letzter Hinweis, bevor jetzt jeder losstürzt und sein Subversion pensioniert: Es gibt auf der Windows-Plattform immer noch keinen Git-Client, vielmehr muß Cygwin mit dem Paket git-core (und möglichst noch git-gui) verwendet werden.

Switch! Mac für Windows-Nutzer

2008-12-01T10:05:00.009+01:00

Gelegentlich wird man als Mac-Benutzer ja gefragt, warum mal kein Windows verwendet. Das ist für mich eine schwierige Frage, denn es gibt eigentlich keinen rationalen Grund, weshalb ich einen Mac haben wollte. Ich wollte ihn, weil ich die Nase voll hatte vom allgemeinen am-Computer-rumschrauben, den ganzen kleinen Ärgerlichkeiten, denen man sich aussetzt, wenn man einen PC benutzt. Das gibt's natürlich auch beim Mac (nur eben anders), und so driften diese Diskussionen sehr schnell in Glaubensfragen ab. Fakt ist: Wer einen Mac hat (und mag), will kein Windows mehr; mehr kann man dazu nicht sagen.

Und manchmal wird man gefragt, worauf man sich einstellen muß, wenn man denn tatsächlich seinen Windows-PC gegen einen Mac tauscht. Hier kann man dann ernsthafte Antworten geben.

Zuerst gilt: Wenn man mit seinem System zufrieden ist, sei es Windows, Linux oder Mac, sollte man dabei bleiben. Ein anderes System bedeuted immer Umstellung und Zusatzkosten, angefangen bei neuer Hardware bis hin zu neuer Software.

Noch dabei? Gut. Dann ist der nächste Schritt, sich zu überlegen, was man mit dem Computer eigentlich machen will. Ist die Antwort "Computerspiele", sollte man überlegen, ob man nicht mit einem Windows-PC oder einer modernen Spielkonsole besser dran ist.

Weiter geht's: Welche Applikationen werden im Moment unter Windows verwendet? Die Klassiker sind Microsoft Office, Outlook und der Explorer, jeweils mit den offenen Alternativen OpenOffice, Thunderbird und Firefox. Diese Applikationen bereiten keine Probleme: Entweder gibt es sie direkt für MacOS X, oder man nimmt die Alternativen von Apple: iWork, Mail.app, Adressbuch und Safari. (Bei Apple gibt's unter dem Titel "Ja zum Mac" eine Liste der wichtigsten Fragen.) Dann gibt's noch Adium als Messenger (falls einem iChat nicht zusagt), und mit dem Mac-Skype-Client ist die letzte Kommunikationslücke geschlossen.

Damit sind die Allgemeinplätze abgedeckt. Bei der Suche nach den Applikationen, um die man sich bei einer Windows-Installation ständig kümmert, stößt man auch auf Windows-Spezialisten wie Antivirus-Programme, Firewalls, Skinning- und Tweaking-Tools oder ähnliches. Analoge Programme für den Mac sind rar und selten nützlich, also verzichtet man besser darauf. Aber was ist mit der Photo-Tool X oder dem Audio-Programm Y? Hier empfiehlt sich die Suche nach inhaltlich analogen Programmen auf Versiontracker.

Den größten Teil der alltäglich benötigten Applikationen sollte man jetzt bereits abgedeckt haben. Für die unter uns, die ihren Mac als Alternative zu einem Linux-System zur Softwareentwicklung einsetzen wollen, suchen jetzt vielleicht noch ein PHP, ein Ruby, ein Tomcat oder einen Apache. Die gute Nachricht: Es gibt eine ganze Menge der Unix-Tools bereits an Bord von MacOS X, und auch Java 6 gibt's endlich für den Mac. Die schlechte Nachricht: Apple ist nicht gerade ständig am Aktualisieren dieser Pakete. Doch Hilfe ist nicht fern: MacPorts bietet ein an die BSD Ports angelehntes System zur Installation von Software. Dazu muß auf dem Mac allerdings ein MacOS X Entwicklungssystem installiert sein. Kein Problem, liegt ja jedem Rechner bei.

Und, noch eine lebenswichtige Applikation, die es leider nur für Windows gibt? Mit Parallels Desktop oder VMWare Fusion bekommt man die letzten Renitenten auf den Mac-Desktop, auch, wenn man früher oder später feststellt, daß man darauf verzichten kann. Auf diese Weise muß man nicht einmal auf Applikationen wie Microsofts Visual Studio oder IBMs Telelogic Synergy verzichten, die man ansonsten nicht auf den Mac bekommt. Und für das Windows-Spiel zwischendurch gibt's Bootcamp - allerdings braucht man dafür eine Windows-Lizenz.

Hat man seinen Mac einmal konfiguriert, kann er locker mit Windows und Linux mithalten - auf einer Maschine. Nur sollte man sich mit dem Gedanken vertraut machen, bei Problemen nicht zum Nachbarn gehen zu können. Neben einem ständigen Backup per mitgelieferten Time Machine hat es sich bewährt, auf eine bootfähige Platte eine bootfähige Kopie des eigenen Systems vorzuhalten. Dazu braucht man eine Firewire-Platte (davon können alle Macs booten), sowie entweder Carbon Copy Cloner oder Superduper!. Wofür man sich entscheidet, ist letztlich Geschmackssache (und natürlich eine Frage, was für einen selbst besser funktioniert).

So. Den Mac bekommt man dann im Apple Store, oder beim Apple-Händler um die Ecke. Viel Spaß!

Git auf dem Mac

2008-11-25T17:46:00.005+01:00

Mac-Nutzer haben es schwerer, mit dem out-of-the-box-Git warm zu werden, als Windows- oder Linux-Nutzer: Git bringt zwar eine eigene GUI mit (eben git gui), aber die hat, zumindest auf meinem Leopard, Probleme mit dem Tcl/TK: Angefangen bei der Schriftgröße, über nicht Mac-konforme Texteingaben, bis hin zu fehlenden Funktionen (die auf anderen Systemen auf der rechten Maustaste liegen, bei der Mac-Implementierung aber nicht einmal auf Ctrl-Maustaste hören). Alles keine Katastrophen, aber nicht sehr schön.

Aber schließlich hat man einen Mac, weil man sich bei der Arbeit auch ein wenig freuen möchte. Genau deshalb gibt es GitX und Gitnub. Dabei ist GitX der "Ersatz" für viele Funktionen des originalen Git GUI, während Gitnub eher der Visualisierung dient und eine Erleichterung für alle Github-User darstellt.

Aber Vorsicht: Ganz ohne Git GUI (bzw. die Kommandozeile) geht's leider immer noch nicht, denn pull und push werden von den beiden Tools noch nicht unterstützt.

Unter'm Strich macht die Arbeit mit GitX und Gitnub einfach mehr Spaß.

Immer wieder Maven: mvn site

2008-11-21T11:22:00.004+01:00

Ach ja, Maven, mein Lieblingstool bei der Softwareentwicklung. Immer wieder gibt's damit Probleme, angefangen bei der sehr fragwürdigen "always online" Philosophie, über reichlich unübersichtliche Builds (na schön, das könnte man sich sparen, wenn man seine Builds richtig aufsetzt), bis hin zu Plugins, die bei jedem nichttrivialen Projekt abstürzen. In schwachen Minuten frage ich mich schon mal, wozu sich ernsthafte Entwickler diese Monstrosität antun.

Aber das war erstmal nur, um in die richtige Stimmung zu kommen. Ein immer wieder auftretendes Problem beim Einsatz von Maven ist mvn site. Das Plugin soll eigentlich die tollen Dokumentationen des Projektes erstellen, tendiert aber dazu, mit OutOfMemoryExceptions abzubrechen. Kein sehr spezielles Problem (Google sagte mir gerade, es hätte knapp 36000 Hits für die Schlüsselworte "maven site outofmemory"), und trotzdem vergesse ich immer wieder, wie ich den häßlichen Vogel in die Luft bekomme. Nun, hier ein Link zu The Wrath of Krang.

Kurzfassung: Mit der Environment-Variable MAVEN_OPTS="-Xmx1024m -Xms128m" sollte es eigentlich funktionieren.

(Und, wie es sich gehört, funktioniert es hier bei meinem Projekt nicht. Aber das ist eine andere Geschichte.)

Multi-User-Git

2008-11-20T14:30:00.003+01:00

In meinen letzten Artikeln zu Git ist immer nur am Rande auf das Aufsetzen eines zentralen Git-Repositories beschrieben. Früher oder später braucht man das aber, zusammen mit einem headless Repository. Im Grunde ist das ganz einfach (wie so vieles bei Git) -- hier die Anleitung vom Git-Tutorial von online-tutorials.net:

~ # mkdir git
~ # cd myproject
~/myproject # git clone --bare .git ~/git/myproject.git

Fertig ist das headless Repository. Für die Berechtigung auf User-Ebene gibt's ein Beispiel-Script, welches im obigen Beispiel nach ~/git/myproject.git/hooks/update kopiert und angepaßt wird. Dann sollte nur noch die Server-Infrastruktur aufgesetzt werden (git-user anlegen, Login-Shell auf /usr/bin/git-shell setzen), und fertig ist der zentrale Server. Zum Aufhübschen kann da vielleicht noch ein gitweb gestartet werden, aber das ist dann schon Luxus.

Erinnerung: Singletons vermeiden

2008-10-14T11:17:00.006+02:00

Heute mal ein Gedanke, der im Grunde keine Erläuterung braucht: Singletons werden fast nie gebraucht und sollten vermieden werden.

Auf den Google-Seiten zur Test-Coverage der Google Update Engine bin ich gerade nochmal auf einen interessanten Link gestoßen, warum Singletons eine schlechte Idee sind: The Singleton Smell, immerhin von Juli 2006, von Greg Miller auf im Unixjunky Blog.

Zusammengefaßt läßt sich sagen: Singletons sind eine Übertragung des Konzeptes globaler Variablen auf OO-Design, was allein schon verdächtig ist, und erschweren bzw. verhindern Unit Tests, da sie die Verwendung von Mock-Objekten erschweren bzw. verhindern.

Im Grunde sollte es immer möglich sein, Singletons zu vermeiden, da ja jedes Programm einen definierten Startpunkt hat, von dem aus Objekte instantiiert und Methoden aufgerufen werden. Problematisch sind wohl nur "magische" Bibliotheken, die zwar technisch initialisiert werden müssen, diese Tatsache in ihrem Interface aber verheimlichen. Mal ein ausgedachtes Beispiel: Eine Bibliothek zur Verschlüsselung benötigt einen Zufallsgenerator, der wiederum mit einem Initialisierungsvektor instantiiert wird. Im Interface der Bibliothek taucht der aber nie auf, sondern wird von der Bibliothek im Hintergrund verwendet. Wenn die Funktionen der Bibliothek jetzt keine Referenz auf eine Bibliotheksinstanz bekommen, müssen sie über ein Singleton den Zufallsgenerator finden.

Warum sollte man jetzt den Zufallsgenerator auslagern? Nun, einerseits kann mit dem versteckten Generator nicht überprüft werden, ob Verschlüsselungsroutinen auch wirklich immer funktionieren, z.B. für besondere Zufallszahlen. Man kann andererseits auch nicht prüfen, ob der Zufallsgenerator hinreichend zufällig arbeitet.

Man kann also nur noch akzeptieren, daß die Bibliothek als Ganzes funktioniert, oder eben sehr lange testen und hoffen, zufällig auf Fehler zu stoßen -- die dann aber nicht mehr reproduzierbar sind. Insgesamt unschön, und nur durch Redesign der Bibliothek korrigierbar, was wieder ein Refactoring aller Applikationen nach sich zieht, die auf der Bibliothek aufbauen. Noch unschöner, und der ausschlaggebende Grund, warum einige Bibliotheken bzw. Frameworks voraussichtlich nie "verbessert" werden.

Schlußfolgerung: Vermeiden, wo es geht, und wo es nicht geht, überlegen, ob es nicht doch geht.

Über Tests, Git und Macs

2008-10-10T21:55:00.004+02:00

Gerade stöbere ich so herum, um ein nettes Git-Plugin für mein Xcode zu finden, da stoße ich einen wirklich interessanten Artikel über's Testen, unter dem provokanten Titel Testing is overrated. Na klar, denke ich mir, die Rails-Typen haben sowieso einen Hang dazu, Dinge als overrated abzutun -- oft genug stellt sich hinterher heraus, daß sie Recht hatten (ich erinnere mich an die Aussage "Flexibility is overrated"). Aber ich schweife ab, Fakt ist, der Artikel ist sehr informativ.

Ach ja, ein Git-Plugin habe ich nicht gefunden, aber eine andere Seite zum Thema Git auf dem Mac: Unter Git, iDisk und so schreibt Thomas Dohmke auf mllog eine kleine Einführung zu Git auf dem Mac, inklusive einer cleveren Anwendung für die iDisk, die wir Mac-User ja zum Glück alle haben. Na ja, einige jedenfalls.

Bleibt nur: Wie komme ich im Büro an meine iDisk? Muß ich noch nachdenken.

Apropos Datensicherheit: Meldedaten

2008-10-08T12:41:00.003+02:00

Und noch ein Artikel auf heise.de: Sächsischer Städte- und Gemeindetag: Verkauf von Meldedaten ist zulässig. Wir brauchen also keine schmierigen Gangster mit großen Hüten unter einsamen Laternen, die nächtlich DVDs mit massenweisen persönlichen Daten für jede Menge gutes Geld verscherbeln, denn die Städte und Gemeinden tun das ganz einfach per Internet.

Was für eine interessante Entwicklung. Bei der Gelegenheit könnte man doch gleich ein Monopol auf den Verkauf von personenbezogenen Daten einrichten, damit den Städten und Gemeinden dieses Geld nicht mehr entgehen kann. Andererseits: Warum sollte man für einen mittleren fünfstelligen Betrag dubiose Daten aus dubiosen Quellen kaufen, wenn man sie legal für den berühmten Apfel und das Ei bekommt? Vielleicht ist ja auch das die Peinlichkeit: Dresden hat im Jahr 2007 nur knapp 316000 Euro per Adreßhandel erwirtschaftet, für dieses Jahr sind nur 375000 Euro geplant.

Wer bei den Preisen noch klaut ist bescheuert.

Heile Welt und Datenklau

2008-10-07T10:29:00.006+02:00

Im Artikel "Jede zweite Rufnummer in den falschen Händen" auf heise.de finde ich gerade einen lustigen Abschnitt:

Gesetzliche Bestimmungen, die den Einsatz etwa von digitalen Markern für die Rückverfolgbarkeit von Daten vorsehen, gebe es schon längst. Wer sich an die Vorschriften halte, könne inzwischen auch bemerken, wenn ein Mitarbeiter sich Zugriff zu größeren Datensätzen verschaffe. Die Defizite lägen eher in der Umsetzung, kritisierte [Thilo] Weichert [Datenschutzbeauftragter von Schleswig-Holstein -- Anm. ketchup].

Nun, das ist ja amüsant. Dazu muß ich sagen, daß ich ein großer Freund von Datenschutz (in beiden möglichen Interpretationen) bin. Allein: Gesetzliche Bestimmungen zu digitalen Markern etc. können nur der Beruhigung des Gewissens dienen, in der Realität taugen die Regelungen nichts: Spätestens im Data Warehouse werden alle Daten aus den ach so sicheren Datenbanken gesaugt und in bunte Bildchen gemanscht. Aber auch sichere Datenbanken sind nicht sicher, weil sie heute nur noch mehr oder weniger dumme Speicher für die Application Server darstellen und nicht mehr feststellen können, wer nun warum auf welche Daten zugegriffen hat.

Der einzig gangbare Ausweg aus der Misere ist tatsächlich Datensparsamkeit: Daten, die ich nicht brauche, werden nicht gespeichert.

Was man nicht hat, kann einem nicht geklaut werden. Alles andere ist Gerede.

Shape of Things to Come?

2008-10-06T16:23:00.006+02:00

Rein zufällig stolpere ich heute bei Golem über einen interessanten Artikel: Forscher: Tom-Skype überwacht seine Nutzer. Nun, vielleicht ist ja "interessant" nicht das richtige Wort, vielleicht sollte man eher "beunruhigend" sagen. Und hoffen, daß die ganze China-Begeisterung bestimmte Leute nicht dazu bringt, sich unter das "Von China lernen heißt siegen lernen"-Banner zu stellen.

Git Nachtrag zur Version 1.6.x

2008-10-06T12:29:00.004+02:00

Mir fällt gerade noch ein, daß es zur aktuellen Version 1.6.x von Git noch einen Nachtrag für meine Blogeintrag gibt. Also: Scripte umschreiben!

Gutes Essen auf schmalen Straßen?

2008-10-04T14:22:00.003+02:00

Um mal einen ebenso einleuchtenden wie nutzlosen Kommentar zum Universum abzugeben und somit der kritischen Masser der Information einen Schritt näher zu kommen (wenn mich meine Erinnerung nicht trügt, hat Stanislav Lem dazu mal eine Kurzgeschichte geschrieben, aber ich finde beim besten Willen nicht heraus, welche es war: Irgendwer hat in einem Supercomputer in Afrika (?) solange irgendwelchen Datenmüll abgeladen, bis die "kritische Masse" von Information überschritten wurde und alle in Computern weltweit gespeicherten Daten verloren gingen, was die Menschheit gehörig zurückwarf...), hier mal zwei Aussagen, über dessen Beziehung untereinander ich gelegentlich eine Studie anzufertigen wäre:

In Italien gibt es gutes Essen. Das Autofahren in Italien ist die Hölle.

Java vs Ruby on Rails... wieder mal

2008-10-02T18:54:00.005+02:00

Ist ja eigentlich schon fast langweilig, denn zu dem Thema wurde schon unendlich viel geschrieben. Was ist jetzt besser? Java oder Ruby?

Stratisch typisiert oder dynamisch typisiert? Interpreter oder Compiler? Perl oder Python? C/C++ oder ASP.NET? Linux oder Windows? Das Internet hat eine lange Geschichte erhitzter Debatten, die ebenso vehement geführt wurden, wie sie sinnlos waren und sind, weil eben jede Seite gute Argumente hat (die in diesen Diskussionen allerdings selten vorgebracht werden). Mehr gefällig? Atari oder Amiga? Emacs oder vi? VMS oder Unix?

Aber Pardon the Information's Robert J. Miller hat mit Java vs. Ruby on Rails - Its a Dead Heat einen interessanten Artikel geschrieben, der im ungewöhnlichen, aber vernünftigen (oder gar erwarteten) Fazit gipfelt, daß beide Lösungsansätze Vor- und Nachteile haben, und beide Ansätze schief gehen können. Interessant vor allem die "entrepeneurial report card". Lesenswert.

Hilfe für Maven

2008-09-29T11:37:00.006+02:00

Nur damit ich es nicht vergesse: Ein nützliches Tool für Java-Entwickler, die sich mit Maven rumschlagen müssen, ist Artifactory: Ein einfach aufzusetzendes Enterprise Repository mit einigen Konfigurationsmöglichkeiten. Im Moment verwende ich es, um auf meinem Laptop auch ohne Netzanbindung Maven-Builds bauen zu können (ohne großartige Offline-Modus-Einstellungen).

Ein etwas angestaubter Artikel, der das Einrichten eines Maven-Repositories beschreibt, ist übrigens bei TheServerSide.com zu finden. Wenn ich mich recht erinnere, bin ich hier auch zum ersten Mal auf Artifactory gestoßen.

Nebenbei: Die ständig benötigte Netzanbindung ist sicherlich eines der größten Ärgernisse in Maven. Muß nochmal in Ruhe zusammenschreiben, was in Folge alles an Problemen auftreten kann.

LHC Tag, wir leben noch!

2008-09-10T11:02:00.006+02:00

Na sowas! Vor Wochen beunruhigten uns Nachrichten, der Large Hydron Collider, eine Teufelsmaschine in den Tiefen der Nacht unter dem zumindest suspekten, wenn nicht gar kryptodiabolischen Genf, werde das jüngste Gericht über uns bringen, Gerichte werden bemüht (nicht nur in Hawaii), um den Untergang des Universums abzuwenden. Mein Gedächtnis flüstert etwas von Physiknobelpreisträgern als Bedenkenträger, aber ich habe zu wenig Zeit, dafür Links zu jagen.

Erinnerungen werden wach: Event Horizon (dazu gibt's sogar einen Wikipedia-Eintrag), oder, wer es nicht ganz so bierernst meint (und keine Angst vor schlechten Filmen hat), Spawn.

Seit heute läuft LHC. Sieh mal an. Die Nachrichten erwähnen es nur am Rande. Vielleicht sollte ich mich mal durch die Blogs zum LHC wühlen?

Sieht aus, als wenn LHC das Schicksal der ersten Kernspaltung erleiden würde: Viel angstgeschürte Aufmerksamkeit vorher, dann gibt's wieder was Wichtigeres. Zum Beispiel, ob es dem Typen von Tokyo Hotel wieder gut geht. Na schön, um moralischen Implikationen vorzubeugen: LHC hat nicht viel mit Atombomben gemeinsam. Abgesehen vielleicht von Physik.

Aber das trifft ja auch auf Tokyo Hotel zu, das mit der Physik.

Also wieder mal nichts Neues unter der Sonne. Nur die Sache mit den juristischen Klagen ist eine jüngere Entwicklung.

Git als Server

2008-09-04T14:49:00.005+02:00

So verlockend der dezentrale Ansatz von git auch ist, früher oder später braucht man doch eine "zentrale Instanz". Und wenn es nur für die Organisation der Releases ist. Git kommt mit einem ganz brauchbaren git-server an Bord, aber es gibt sicher Situationen, in denen man ... mehr will.

Auf scie.nti.st gibt es nun eine sehr ausführliche Anleitung, wie ein solcher "Git-Server" auf Basis von gitosis aufgesetzt wird. Das Ganze verlangt nach einem ordentlich aufgesetzten Python, was ja auf modernen Unix-artigen Systemen gegeben sein sollte. Eventuell nötige Anpassungen sind in der Anleitung beschrieben; die Kommentare sind auch hilfreich.

Git Cheat Sheet

2008-09-04T13:13:00.003+02:00

Ich grübele gerade, wie ich ein Problem mit git lösen kann, und siehe, zwischendurch stoße ich auf das hervorragene Git Cheat Sheet von Jan Krüger. Sehr empfehlenswert.

Noch ein Link zu Google: Heise berichtet

2008-09-03T12:11:00.002+02:00

Die netten Leute von Heise haben der Gelegenheit angemessen einen "mehrseitigen" Artikel zu Chrome zusammengestellt: Googles Browser Chrome wühlt das Web auf.

Evil Google?

2008-09-03T08:21:00.004+02:00

Im Grunde war die Reaktion ja vorhersehbar: Google veröffentlicht einen neuen Browser, und die Welt schreit "Hilfe! Böses Imperium!". Gerade erfreute mich der nicht gerade auf technische Schlagzeilen spezialisierte MDR Figaro mit einem Interview mit einem Medienwissenschafter aus Halle zum Thema Chrome. Schlußlinie: Google muß viel demokratischer werden, sich wieder dem Netz öffnen.

Das sind so diese Tage, an denen ich überlege, ob es sich lohnt, Ohren zu haben. Oder, was das angeht, Augen. Ich bin weit davon entfernt, Google verteidigen zu wollen, aber vergessen die belehrstuhlten Bedenkenträger nicht eine Kleinigkeit? Zum Beispiel daß Google ein komerzielles Unternehmen ist, welches als erste Bürgerpflicht Geld für die Anteilseigner erwirtschaften muß? Und es trotzdem geschafft hat, eine breite Palette von Dienstleistungen kostenlos anzubieten?

Ganz klar, was "umsonst" ist, muß reguliert werden, ist Gemeingut. Und was erfolgreich ist, muß sowieso reguliert werden. Ich kann mich erinnern, daß in den Tagen von AltaVista die Idee einer Suchmaschine, die automatisch das Internet abgrast, als komplett hirnrissig angesehen wurde. Und zwar von ausnahmslos allen, die irgendwas vom Internet verstanden haben. Nachdem AltaVista an vorhersehbaren technischen und finanziellen Problemen scheiterte (Yahoo war von Anfang an als handeditierte Liste von URLs an den Start gegangen), hat Google erneut den automatischen Ansatz versucht. Bekanntes Risiko, eigene Kosten. Ein Experiment, das funktioniert hat, Erfolg gegen jede Vernunft. War da jemand dabei, der warnend den Zeigefinger erhob? (Abgesehen von den üblichen Verschwörungstheoretikern...)

Wohl nicht. Aber Google ist eben privat, nicht staatlich (sonst wäre das andere Verschwörungslager hinter ihnen her). Das schmeckt wohl nicht allen: Die einen sind sowieso gegen alles, was irgendwie nach Kapitalismus riecht, andere finden es bedenklich, daß Google permanent Dinge "verschenkt" und damit den Markt für Dienstleistungen gegen Bargeld austrocknet, dritte können es einfach nicht ertragen, daß es eine einflußreiche Größe gibt, die nicht von einem internationalen Gremium mit Komitee und gesonderten Komissionen für Menschenrechte, Transparenz und technische Spezifikationen "gelenkt" wird. Und zuletzt gibt es noch die professionellen Bedenkenträger, denen das Thema egal ist, solange man nur für den Vortrag Aufmerksamkeit erheischen kann.

Möge Google standhaft bleiben. Sie haben keinen Grund, sich dem Druck der Neider zu beugen, und wenn sie es täten, würde tatsächlich entstehen, wovor die Unkenrufer warnen: Ein omnipotenter, intransparenter Technologie-Moloch, bei dem nie klar ist, wessen Interessen er vertritt. Und wer es wirklich ernst meint mit seiner Ablehnung von Google als Evil Empire, sei eingeladen, seine eigene Applikation zu bauen, ob Suchmaschine, eMail-Dienst oder Browser. Aber bitteschön mit seinem Geld, nicht mit meinen Steuern.

Chrome ist da

2008-09-02T22:30:00.005+02:00

Na sowas: Gerade erst erfahre ich, daß es Google Chrome gibt, und schon ist es fertig: Auf der Download-Seite von Chrome steht ein überschaubar kleiner Installer bereit, der die Applikation auf die Platte bügelt.

Auf den ersten Blick ist Chrome unspektakulär: Einfach ein Browser, ohne viele Knöpfe zum dran drehen, der sofort funktioniert und sich irgendwie... googlig anfühlt: Nicht sehr schick, nicht sehr stylish, aber funktional. Understatement. Wo nehmen die Googler eigentlich immer ihre Designer her? Ich bin fasziniert.

Ansonsten ist der eBlätterwald ja heute voller Meldungen zum Thema "Google baut sein Imperium aus" (am peinlichsten sind irgendwie immer die FOCUS-Artikel, auf die ich lieber nicht verlinke, weil ich die aufgeregten, schicksalsschwangeren ... Artikel dort einfach nicht ertragen kann). Ich kann nur sagen: Entwarnung, Chrome erscheint handlich und ist nett, aber nicht das Ende von Firefox, Opera und Exploder.

Größter Minuspunkt übrigens: Zumindest Firefox und Opera gibt es auch für Nicht-Windows-Plattformen; Chrome gibt's offenbar erstmal nur für Windows.

Burning Chrome

2008-09-02T14:14:00.006+02:00

Chrome ist offensichtlich ein sehr beliebtes Material. Keine Ahnung, warum. Auf jeden Fall faszinierte es schon William Gibson genug, um eine Kurzgeschichte "Burning Chrome" zu nennen (zu meiner Schande muß ich gestehen, daß mir im Moment nicht einfällt, warum es dort ging). Später verbarg sich unter der Oberfläche von Mozilla (und seinen Nachfolgern, wie Firefox) ein System namens Chrome. Vielleicht in Anlehnung an Gibsons Geschichte? Müßte recherchiert werden.

Neueste Referenz ist Google Chrome. Ein Mythos? Wer weiß, Philipp Lenssens Blog berichtet schon mal über ein Comic zum neuen Superbrowser (offiziell bei Google Books zu finden). Der Comic wurde von Scott McCloud gezeichnet (genau, der mit den Comics zum Comic) und ist unabhängig von der Realitätsnähe des Google Chrome Browers lesenswert.

P.S.: "Burning Chrome" wurde nicht als "Laß die Giraffe brennen" übersetzt. Falsche Assoziation...

Auf der Suche nach dem Verzeichnis

2008-09-01T08:39:00.004+02:00

LDAP ist ein interessantes Phänomen: Alle reden darüber, alle wollen es nutzen, aber niemand schreibt, wie es genutzt werden soll. Jüngstes Beispiel: Ich will einen LDAP-Server in Glassfish einbinden. Alles ganz einfach: Glassfish installieren, ApacheDS installieren, Domain im LDAP anlegen, und ... ähm, was jetzt? Klar, ein LDAP-Realm im Glassfish anlegen, aber mit welchen Parametern?

Die Lösung sollte jetzt ganz einfach sein: Google hilft. Also kurz "glassfish ldap" einhacken und gucken, was passiert. Es passiert, was man befürchtet hat: Seiten über Seiten, die sagen, man kann doch LDAP mit Glassfish benutzen (wissen wir schon!), und anschließend Seiten über Seiten, die erklären, wie OpenLDAP installiert wird (interessiert mich nicht).

Auf den Seiten von number 9 verliere ich dann ganz den Faden. (Na ja, daß PostgreSQL die leistungsfähigste frei verfügbare Datenbank ist, wußte ich vorher schon.)

Also, Punktsieg für den Rest der Welt im ewigen ketchup vs. Rest der Welt. Ich werde wohl doch noch in meine JEE-Büchern graben müssen.

Als Deutsch getestet

2008-08-26T09:26:00.004+02:00

Unser schönes Deutschland wird Einwanderungsland, also brauchen wir ... was? Genau, einen Einbürgerungstest. Den hat ja nun jeder.

Aber unser Einbürgerungstest wäre nicht deutsch, wenn er nicht ein paar Besonderheiten hätte. Zunächst einmal werden dem zukünftigen Deutschen aus einem Fundus von ca. 300 Fragen gut einhundert gestellt. Es gilt, wenigstens die Hälfte der Fragen korrekt zu beantworten. Damit es aber nicht zu schwer ist, sind die Fragen als (Multiple?) Choice Fragen angelegt: Einfach das Richtige ankreuzen.

Klingt einfach. Klingt vernünftig. Schließlich wollen wir ja in Deutschland Einwanderer begrüßen, die sich mit Land, Leuten und Kultur identifizieren. Und natürlich Deutsch sprechen. Aber es gibt, wie so oft bei bürokratischen Vorgängen, einen Haken: Die Fragen sind offenbar auch von Deutschen nicht immer einfach zu beantworten. "Wenn Sie Ihrem Kind einen Hund schenken, müssen Sie:" -- ja, natürlich, das Tier anmelden und Hundesteuer zahlen. (Ich halte das ja für eine einfache Frage, aber in Konkurrenz zur Antwort "den Hund impfen lassen" ist es schon eine Fangfrage). Dafür kann man den Test so oft wiederholen, wie man will. Vielleicht will man irgendwann einfach nicht mehr.

Grundsätzlich frage ich mich, ob solche Tests nicht Augenwischerei sind. Schön, sie stellen sicher, daß Einwanderer die Sprache hinreichend gut lesen können. Aber wissen wir anschließend, ob sie uns Eingeborene auch verstehen? Wichtiger noch: Motiviert so ein Test dazu, Deutschland zu verstehen? Kann ein Test das überhaupt? Wenn die Antwort "Nein" lautet (und das ist meine Meinung), dann ist der Test nur bürokratische Schikane. Mit Integration hat das nicht viel zu tun.

Immerhin, wer sich für den deutschen Paß testen läßt, demonstriert wenigstens eine gewisse Leidensfähigkeit und den Willen, sich absurden Anordnungen der Obrigkeit zu beugen. Also vielleicht doch eine gute Vorbereitung auf das Leben als Deutscher?

Im Brunnen

2008-08-25T18:21:00.004+02:00

Irgendwie scheinen wir uns nur für Dinge zu interessieren, die schon vorbei sind. Jüngstes Beispiel: Die Bestrebungen einer Klage gegen die bundeseinheitliche Steuer-ID. Klar ist, daß eine eindeutige Personenkennzahl schnell weitere Begehrlichkeiten wecken wird, schließlich wollen wir alle etwas gegen organisierte Kriminalität, Kinderpornographie und letztlich gegen Terrorismus unternehmen. Und wer nichts zu verbergen hat, hat ja auch nichts zu verheimlichen, am wenigsten seine Steuer-ID! Also, Tätowierstudios schon mal die Tinte anwärmen, wir braven Brüger ohne Furcht und Tadel kommen bald vorbei, und lassen unsere PKZ auf Stirn und Unterarm pieksen.

Was ich nicht verstehe: Warum ist das Thema jetzt aktuell? Ich kann mich erinnern, daß der Vergleich Steuer-ID = Personenkennzahl schon vor Monaten, wenn nicht Jahren, gezogen wurde. Damals hat es niemanden interessiert. Warum heute?

Ach ja, den gleichen Aufschrei gab es auch, als es hieß, im nächsten Monat wird GEZ-Gebühr auf Internet-PCs fällig. Die jahrelange Debatte im Vorfeld war ja offenbar nur was für Geeks.

Kopfschütteln.

Computer, wie sie sein sollten

2008-08-19T11:33:00.008+02:00

Vor ein paar Tagen bin ich auf einen Artikel gestoßen, in dem ein Produkt namens "Delicious Library 2" kurz vorgestellt wurde. Das Ding ist im Grunde eine simple Dinge-Datenbank, recht hübsch in Szene gesetzt, berücksichtigt aber zwei Anwendungen einer solchen "Datenbank aller Dinge", die andere Programme und Systeme vernachlässigen:

Man kann Dinge (Bücher, Filme, CDs) an Bekannte verleihen (und sich merken, wem man was geliehen hat)
Man kann seine gesamte Bibliothek in ein, zwei Tagen komplett einlesen

Letzteres ist das wirkliche Alleinstellungsmerkmal von Delicious Library: Einfach den EAN-Barcode des zu archivierenden Artikels vor die iSight-Kamera seines Mac halten, Pieps abwarten, und fertig. In der Realität funktioniert das erstaunlich gut, und wenn der Barcode mal nicht gelesen werden kann (was hin und wieder passiert), hilft die direkte Eingabe der EAN fast immer weiter. Und wo auch das scheitert zeigt sich Delicious Library flexibel: Stichworte werden direkt an Amazon gesendet, und die Trefferliste läßt dort in den Details stöbern.

Na schön, genörgelt werden darf auch. Delicious Library ist ein sehr, sehr einfaches Programm. Wie viele gute Mac-Programme verzichtet es auf überbordende Features, und beschränkt sich auf das Wesentliche: Artikel erfassen und in verschiedenen Listen halten. Einige Zeitgenossen mögen sich mehr wünschen. Gute Nachricht: Mit AppleScript ist alles möglich. Schlechte Nachricht: Man muß zumindest versuchen, AppleScript zu benutzen.

Und ganz offensichtlich gibt es da noch ein Problem: Delicious Library ist ein Mac-Programm. Wer also keinen Mac hat, steht im Regen (steht er sowieso -- oder läßt sich von einem Freund die Bibliothek scannen und als XML 'rüberreichen - Exportoptionen gibt es reichlich). Aber im Grunde hilft es nur, sich einen Mac zu kaufen. Was sowieso eine gute Idee ist.

Zum Abschluß klaue ich nochmal den Anfang der Delicious Monster Site, weil er mir einfach so gut gefällt:

"Wait, I just hold a CD or DVD or video game or book or whatever up to my webcam, and it magically reads the UPC and downloads that item’s cover and all pertinent information about it, and displays all my stuff on photorealistic shelves? I’ll take it! Right now! This is why I bought a computer in the first place!"

Ja, genau so ist es. Nur fotorealistisch erschien mir damals noch etwas zu utopisch.

Schöngetrunken

2008-07-29T12:41:00.004+02:00

Ach ja, Erfolg macht sexy. Kein Wunder, daß alle erfolgreich sein wollen. Beispielsweise will Microsoft mit seinem Windows Vista ganz dringend Erfolg haben, koste es, was es wolle. Na schön, "koste es, was es wolle" hat MS ja schon ein paar Mal erfolgreich durchgezogen, zuletzt meines Wissens nach mit dem Internet Explorer, der mit brachialer Gewalt an die Spitze der verwendeten Browser im Internet geprügelt wurde.

Schon damals war eine spannende Frage, wie der Erfolg gemessen wird. Die verschiedenen Statistiken, die zum Thema Markaufteilung bei Browsern im Umlauf sind, haben ja eine lange Geschichte. Und wenn alle Stricke reißen, muß eben kreativ mit Zahlen umgegangen werden. MS konnte so in knapp zwei Monaten sein Ergebnis verkaufter Vista-Lizenzen um knapp 22% verbessern (von 140 Millionen auf 180 Millionen), indem einfach alle Windows-Lizenzen, die Hersteller wie HP in letzter Zeit verkauft haben, als Vista-Lizenz abgerechnet werden.

Wie schon beim Internet Explorer stellt sich auch hier die Frage nach dem Warum: Weshalb ist Microsoft so erpicht darauf, erfolgreicher dazustehen als sie ohnehin schon sind? (Denn daß sie erfolgreich sind steht völlig außer Frage.) Warum muß Vista möglichst noch erfolgreicher sein, sogar auf Kosten des hauseigenen XP? Ist es nicht offensichtlich, daß Vista eben nicht so erfolgreich ist?

Es kann natürlich sein, daß die neue Spitze bei MS demonstrieren will, daß sie auch ohne Bill ganz gut zurecht kommt. Oder daß man sich keine Schlappe leisten will: Wenn Vista noch teurer war als XP, und noch massiver beworben wurde als XP, muß Vista auch noch besser verkauft werden als XP. (Erinnert mich irgendwie an Civilization: Wenn ich den Wissenschaftsetat erhöhe, bekomme ich automatisch schneller Forschungsergebnisse.)

Aber im Grunde weiß das nur Microsoft.

Mass Effect Is Evil!

2008-07-20T18:00:00.001+02:00

Ein neues Schreckliches Spiel sucht uns heim und verschlingt Zeit wie es auch ein schwarzes Loch nicht kann: Biowares Mass Effect haut in die gleiche Kerbe wie vormals Knights of the Old Republic. Nur hat Bioware an der Präsentation massiv gefeilt: Während KotOR noch steril und stellenweise hölzern wirkte, macht Mass Effect den Eindruck eines interaktiven Films. Zwar müssen wir bei Mass Effect auf Lichtschwerter verzichten, dafür sind die Kampfsequenzen irgendwie taktischer geraten -- oder wirken zumindest so. Die Dialoge sind insgesamt sehenswerter, die Atmosphäre stimmt, kurz, allein der äußere Eindruck legt den Erwerb nahe.

Was die Story angeht: Wieder einmal muß das ganze Universum gerettet werden. Dabei ist der Spieler selbst kein Superheld nach Lucas oder Marvel, sondern nur ein ganz normaler Superspion, der seine Handfeuerwaffen an Bord seines eigenen Schiffes beim Waffenmeister kaufen muß. (Abgesehen davon ist er natürlich Kapitän des Schiffes. Das muß schon sein.) Wie bei bisherigen Bioware-Titeln kann man sich in zahllosen Nebenquests verwickeln; ob die Story reich an Verwicklungen ist, wird sich erst noch zeigen.

Ansonsten gilt: Wenn gerade genug Kleingeld zur Hand ist, und ein paar Tage Zeit sind, sollte man unbedingt mal draufsehen. (Vermutlich wird es dann sowieso gleich gekauft.)

Mal was Anderes: Git

2008-07-20T10:25:00.001+02:00

Das alte RCS hatte gegenüber allen hypermodernen Client-Server-SCMs einen großen Vorteil: Wenn man mal eben eine Datei versionieren will, sagt man einfach co dateiname. Besser noch, man versioniert die Datei im Emacs, und hat keine Sorgen mehr. Das ist zwar nicht praktikabel für Multimillionendateienprojekte, wie sie heute die Regel sind, aber perfekt für Konfigurationsdateien oder "Microprojekte", also Tools, die man nebenbei mal so schreibt.

Allerdings gibt es gute Gründe, RCS nicht zu verwenden. Zusammengefaßt: Aus heutiger Sicht kann RCS nicht mehr als SourceSafe. Na schön, laut der aktuellen Dokumentation von VSS kann VSS mittlerweile mehr als RCS (nämlich Verzweigen und Zusammenführen, bekannt als Branchen und Mergen). Wie dem auch sei, RCS lebt, solange es keine Alternative für solche Microprojekte gibt.

Und hier ist sie: Git, das Fast Version Control System. Git ist anders als Subversion, anders als RCS; es ist zusammen mit Mercurial eine neue Kategorie von SCM: verteiltes SCM. Im Gegensatz zu einem Client-Server-SCM, bei dem das Repository mit allen versionierten Dateien auf einem zentralen Server liegt, hat bei einem verteilten SCM jeder Client ein vollwertiges Repository lokal vorliegen. Damit hat man jederzeit offline Zugriff auf die komplette verzweigte History des Projektes, was ein großer Vorteil ist, wenn man aus irgendwelchen Gründen tatsächlich offline arbeiten muß.

Ein Git-Repository ist schnell aufgesetzt: alles, was man braucht, ist ein Wurzelverzeichnis. Dann reicht ein git-init, und schon kann man Dateien versionieren. In der Vergangenheit waren verschiedene Aufsätze zu Git populär (z.B. Cogito), um die Arbeit mit Git zu vereinfachen. Aktuell wird Git aber als nutzerfreundlich genug angesehen, sodaß diese Aufsätze als "deprecated" gelten.

Gilt es nun, eine lokale Arbeitskopie zu erstellen, wird bei einem verteilten SCM ein beliebiges vorhandenes Repository geklont. Bei Git klont man in der Regel das Repository, in das man seine Änderungen wieder einspielen möchte. Auch das ist sehr einfach: Ein git-clone erstellt ein Verzeichnis mit dem Namen des Repositories und packt dort den Inhalt des Repositories aus. Wechselt man nun in das neue Verzeichnis, kann man sofort einen Versionsbaum des Repositories begutachten, indem man gitk sagt. Gitk ist ein Tcl/Tk Frontend zum kommandozeilenbetriebenen Git; erwähnenswert ist noch git-gui, ein weiteres Frontend, welches alle praktischen Arbeiten in Git in einer GUI zusammenfaßt.

Der Rest ist schnell erzählt: Neue Dateien werden per git-add hinzugefügt, alte werden mit git-rm gelöscht oder per git-mv umbenannt/verschoben, ein Changeset wird per git-commit ins (lokale) Repository geschrieben. Updates vom Upstream-Repository besorgt man sich per git-pull, seine eigenen Änderungen schiebt man per git-push wieder zurück (hierfür wird i.d.R. ein SSH-Zugang benötigt). Branches werden per git-branch angelegt (oder einfacher per git-checkout -b ), zwischen den Branches kann per git-merge gemerged werden. Zuletzt kann ein erreichter Zustand per git-tag gelabelt werden (Bonbon: per git-tag -s kann der Stand PGP/GPG-signiert werden). Zu einem beliebigen Stand im Repository gelangt man wieder per git-checkout, was damit zu einem der wichtigsten Befehle mutiert.

Damit ist die Grundfunktionalität eines SCM abgedeckt. Git kann noch eine ganze Menge mehr, aber das kann man sich ansehen, wenn man wirklich mal ein größeres Projekt unter Git verwaltet. Was noch fehlt ist eine vernünftige Integration in Eclipse (das Java GIT/Eclipse GIT Plugin habe ich nicht zur Zusammenarbeit bewegen können).

Das ist alles viel zu umständlich und generell nicht praktikabel? Nun, obwohl ich als bekennender Apple-User natürlich (!) BSD vorziehe, wird der Linux-Kernel unter Verwendung von Git weiterentwickelt. Das scheint ja erstmal zu funktionieren.

[Update 2009-01-14]

Die offizielle Homepage von git ist umgezogen. Git firmiert nun unter http://git-scm.com.

[/Update 2009-01-14]

Ein wenig über Synergy

2008-07-19T10:47:00.000+02:00

Mit Synergy (vormals Continuus) besitzt IBM ein weiteres gefühltes Fossil unter den Versionskontrollsystemen. Zur Erinnerung: Vor ein paar Jahren kaufte IBM mit der Firma Rational auch gleich deren ClearCase SCM mit ein. Beide Systeme können ihre Wurzeln zumindest bis in die 1990er Jahre zurückverfolgen (was ich hier nicht tue, da beide Systeme eine bewegte Vergangenheit haben). Im Moment bin ich gezwungen, mit Synergy zu arbeiten, was mein Leben nicht eben leichter macht; ich vergleiche es hier mit ClearCase, obwohl ich mit letzterem wesentlich mehr Erfahrungen habe.

Wie bei allen anderen serverbasierten SCMs, zu denen ich auch das vielgelobte Subversion zähle, ist auch by Synergy eine wesentliche Schwäche des Systems der Aufwand, der im Vorfeld betrieben werden muß: Bevor ein Projekt aufgesetzt werden kann, muß die Projektstruktur geplant werden. Wer schon einmal die Freude hatte, ein neues Projekt in Subversion oder ClearCase aufzusetzen, weiß, daß hier viele Befindlichkeiten berücksichtigt werden wollen, inklusive der Planung der späteren Nutzung.

Synergy verwirrt hier zusätzlich, da es ein eingebautes Modell für den Lebenszyklus von Software hat. Es gibt hier Projekte und Unterprojekte (die brav mit den IDE-Projekten der Entwickler abgeglichen, aber nicht verwechselt werden wollen), Versionen, Folder, Tasks und Releases. Ein buntes Sammelsorium an Abhängigkeiten erleichtern die Arbeit, sofern man sich an die Vorstellungen eines Lebenszyklus von Synergy hält. Gewarnt seien alle, die sich damit nicht im Vorfeld beschäftigen wollen: Es kann sehr eklig werden, wenn man an diesen Vorstellungen vorbei operieren will oder muß.

Bis zu diesem Punkt ist Synergy ein gewöhnliches SCM mit einem eigenwilligen, man könnte sagen ungewöhnlich unintuitiven Interface. An dieser Stelle empfehle ich allen, die es benutzen wollen, sich mit der abweichenden Semantik von "Update" vertraut zu machen, bevor sie die Arbeit von Tagen verlieren.

Warum also sollte jemand Synergy einsetzen wollen?

Die Antwort liegt im (neuen) Namen "Synergy": Das SCM ist eng mit dem zusätzlichen Produkt "Change" (und anderen Produkten aus dem Haus Telelogic) verwoben. Change requests in diesem Tool sind bis ins SCM transparent, Tasks werden direkt CRs zugeordnet, und jede noch so kleine Quelltextänderung direkt an einen Task. Damit haben die Entscheider theoretisch jederzeit Überblick über den Stand der Arbeiten, ohne den Entwickler fragen zu müssen.

Generell spielt Synergy seine Stärken erst richtig aus, wenn die Software "fertig" ist: CRs können z.B. vom Test entdeckte Fehler sein, aber auch Anforderungen des Kunden. Im Gegensatz zu anderen Systemen lassen sich die dadurch nötigen Aufwände einfacher erfassen, und die Arbeiten bis hinunter zu den einzelnen Entwicklern zuweisen. Die Gefahr, daß hier noch etwas bei der Transition zwischen verschiedenen Systemen verloren geht, ist hier durch die Integration des SCM mit dem Change Management Tool deutlich geringer.

Ein wirklich sehr schönes Feature ist das Zusammenstellen eines Releases auf der Basis von Tasks: Man entscheidet, welche Tasks mitgenommen werden sollen, und kann so einfach problematische Änderungen ausschließen.

Warum würde ich es trotzdem lieber meiden?

Die Illusion totaler Kontrolle ist möglicherweise irreführend. Wie ein Kollege vor kurzem zitierte: Die Wahrheit liegt im Sourcecode. Und die zu extrahieren bedarf es mehr als einer Aufstellung von geänderten Dateien.

Zudem ist das unintuitive Interface (beide Interfaces sind unintuitiv: sowohl das "klassische" Interface, als auch der "Developer Client"; zudem weichen Bezeichnungen für Arbeitsschritte voneinander ab, und einige Arbeiten lassen sich im Developer Client nicht durchführen) Ursache für Frustration und verlorene Arbeit. Eine Einweisung in Synergy ist also unbedingt nötig, besonders wenn Entwickler vorher mit anderen SCMs gearbeitet haben.

Und letztlich kann auch Synergy keine Wunder vollbringen: Abhängigkeiten zwischen Quelltextänderungen in verschiedenen Tasks schlagen sich nicht automatisch in Abhängigkeiten zwischen das Tasks nieder. Damit kann das Zusammenstellen von Tasks für eine Build- oder Lieferversion keine integere Lieferung garantieren, was dieses ansonsten schöne Feature wieder etwas in Frage stellt.

Im Vergleich zwischen ClearCase und Synergy würde ich mich ob der klareren und intuitiveren Versionsverwaltung für ClearCase entscheiden. Die Lizenzkosten für beide Systeme sind mir nicht bekannt; möglicherweise entscheidet in der Praxis dieses Argument. Sobald es aber um Support per Internet-Forum und Bekanntheit bei den Entwicklern geht, verlieren sowohl ClearCase als auch Synergy klar gegen Subversion; kleine Projekte mit einem kurzen Entwicklungszyklus sollten sich eher in diese Richtung orientieren, zumal sowohl bei ClearCase als auch bei Synergy dedizierte Administratoren für die Pflege des SCM notwendig (und dann auch beschäftigt) sind.

Nachtrag Push-Funktionalität bei mobileMe

2008-07-17T15:02:00.000+02:00

Nachdem ich mich gestern so über Apples mobileMe geärgert habe, will ich doch noch kurz nachschieben, daß Apple heute morgen per Rund-eMail Stellung genommen hat. (Nein, natürlich nicht wegen meinem Blog, sondern vermutlich weil das Problem größere Kreise zieht.) Offiziell wird jetzt darauf hingewiesen, daß die Push-Funktionalität momentan eingeschränkt ist.

Also, alles wird gut.

Übrigens sollte ich dazu sagen, daß mein nächster Rechner trotzdem ein Mac wird.

Kein Push mehr

2008-07-16T11:21:00.000+02:00

Ich hab's ja immer gesagt: Man kann Apple einfach nicht trauen. Jüngstes Beispiel: Das rätselhafte Verschwinden der Push-Funktion aus dem niegelnagelneuen mobileMe (siehe auch die Golem-Meldung dazu). Aber ist das wirklich so schlimm? Vermutlich rüsten sie die Funktion ja noch nach (in den ersten Tagen zumindest hatte ich ohnehin Probleme mit dem verbauten JavaScript, welches sich mal eben einen meiner zwei Porzessoren gönnte).

Ja, ich denke, es ist symptomatisch. Apple (oder Herr Jobs, wer weiß das schon) ist ausgesprochen geschickt, wenn es darum geht, den Leuten zu verkaufen, was sie wollen. Du willst einen total einfachen und zugleich schicken Rechner? Klar, kein Problem, aber ein paar Prozent mehr als die in China montierten Dinger kostet der dann schon. Ist ja schließlich "Designed by Apple in California". Du willst auf Dein Adreßbuch auch in der Firma zugreifen? Kein Problem, schlappe achtig Dollar oder Euro (wo ist der Unterschied?), und los kann's gehen.

Dabei ist die Sache mit dem iPhone, was in seiner dritten (!) Generation endlich auch mal UMTS benutzen kann, dafür aber schon immer primär von Anwendungen im Netz gelebt hat (!!), noch überhaupt nicht mitgerechnet.

Und dann wäre da noch mein alter Groll ob des eingestampften Newton. Den ich so geliebt habe, und den Apple einfach aus Prinzip gekillt hat. Na ja, alte Wunden. Mein Newton funktioniert immer noch: Habe ihn vor einem halben Jahr nochmal ausgegraben, neue Batterien rein, und er lief sofort. Mehr als ich von meinem ersten Palm sagen kann.

Das Lustige an der Sache ist, daß man selten jemanden trifft, der ein Apple-Produkt gekauft hat und davon nicht überzeugt ist. Mal ehrlich, mein MacBook ist einfach mal cooler als jeder Laptop-PC. Ich liebe meinen Mac!

Nur Apple traue ich nicht über'n Weg. Wenn das ein Ansporn sein kann: Seid doch einfach mal eine Nummer ... solider.

Warum kann Maven Dateien filtern?

2008-07-14T08:13:00.000+02:00

Weil es mir gerade auffällt? Kennt irgendjemand einen legitimen Grund, warum Maven Resourcen für seine zu erstellenden Artefakte filtern kann? Ich betrachte mal zielspezifische Builds nicht als legitimen Grund...

Was dabei nämlich rauskommt, sind Artefakte, die für eine Zielumgebung konfiguriert sind. Und das ist ja ganz klar ein großes NoNo. Na, ganz so klar ist das wohl nicht jedem, sonst wäre es nicht getan worden, daher ein Hinweis: Der gleiche Build sollte auf den Umgebungen von Entwicklern, Testern und auf der Produktionsumgebung laufen...

Nur so als Gedanke.

Anfangen.

2008-07-03T13:36:00.000+02:00

Eigentlich brauche ich ja kein Blog, weil ich erstens sowieso nicht regelmäßig reinschreibe, und ich zweitens nicht so viele spannende Dinge zu schreiben habe. Aber zum Glück gibt es ja unendlich viele Blogs, von denen wieder unendlich viele praktisch nur von ihren Authoren gelesen werden (wenn überhaupt), und und außerdem gibt es noch ganz, ganz viele Blogs, in denen nicht viel steht. Sagt man.

Also kann ich diesen Blog hier genausogut nehmen, um alles, was mir so in die Hände fällt, reinzuwerfen. Was ich hiermit tue.

Soviel zum Anfang.