Donnerstag, 18. Dezember 2008

Eine Lanze für HAML

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, CampingMerb 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]

Samstag, 6. Dezember 2008

Subversion-Repositories nach Git migrieren

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:
  1. Anlegen einer Textdatei für das User-Mapping
  2. Importieren des SVN-Repositories in Git
  3. 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.

Montag, 1. Dezember 2008

Switch! Mac für Windows-Nutzer

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ß!

Dienstag, 25. November 2008

Git auf dem Mac

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

Freitag, 21. November 2008

Immer wieder Maven: mvn site

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

Donnerstag, 20. November 2008

Multi-User-Git

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.

Dienstag, 14. Oktober 2008

Erinnerung: Singletons vermeiden

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.

Freitag, 10. Oktober 2008

Über Tests, Git und Macs

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.

Mittwoch, 8. Oktober 2008

Apropos Datensicherheit: Meldedaten

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.

Dienstag, 7. Oktober 2008

Heile Welt und Datenklau

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.

Montag, 6. Oktober 2008

Shape of Things to Come?

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

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!

Samstag, 4. Oktober 2008

Gutes Essen auf schmalen Straßen?

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.

Donnerstag, 2. Oktober 2008

Java vs Ruby on Rails... wieder mal

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.

Montag, 29. September 2008

Hilfe für Maven

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.

Mittwoch, 10. September 2008

LHC Tag, wir leben noch!

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.

Donnerstag, 4. September 2008

Git als Server

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

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.

Mittwoch, 3. September 2008

Noch ein Link zu Google: Heise berichtet

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?

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.

Dienstag, 2. September 2008

Chrome ist da

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

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

Montag, 1. September 2008

Auf der Suche nach dem Verzeichnis

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.

Dienstag, 26. August 2008

Als Deutsch getestet

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?

Montag, 25. August 2008

Im Brunnen

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.

Dienstag, 19. August 2008

Computer, wie sie sein sollten

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:
  1. Man kann Dinge (Bücher, Filme, CDs) an Bekannte verleihen (und sich merken, wem man was geliehen hat)
  2. 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.

Dienstag, 29. Juli 2008

Schöngetrunken

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.

Sonntag, 20. Juli 2008

Mass Effect Is Evil!

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

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]

Samstag, 19. Juli 2008

Ein wenig über Synergy

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.

Donnerstag, 17. Juli 2008

Nachtrag Push-Funktionalität bei mobileMe

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.

Mittwoch, 16. Juli 2008

Kein Push mehr

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.

Montag, 14. Juli 2008

Warum kann Maven Dateien filtern?

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.

Donnerstag, 3. Juli 2008

Anfangen.

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.