Puh, ich muss mir mal den Frust von der Seele schreiben den dieses Werkzeug mir bereitet hat.

Zuerst das Setup: Ich will zu einem Open Source Projekt beitragen dass leider GIT und GITHUB verrwendet.

Zuerst mal was mich wirklich frustriert hat. ich habe an ein DVCS (und speziell eines dass so sehr hyped wird wie GIT) ein paar ganz spezifische Requirements:

1. Ich will dass ich meine Patches sauber getrennt voneinander entwickeln kann, damit man jeweils den ganzen Patch einfach sehen kann.
2. Ich will die History dieser Entwicklung erhalten, damit die Code-Reviews die stattgefunden haben und die Gründe für Änderungen sichtbar bleiben
3. Ich will einen stabilen Link auf den Head nur dieser Patches, damit der Maintainer es einfach hat diese bei sich zu integrieren und ich den in BugReports angeben kann
4. Ich will die Patches als Layer über mein repository legen, damit ich von den Bugfixes die ich bereitstelle schon etwas habe solange sie noch nicht in dem Projekt akzeptiert wurden. Dieses Overlay-Repo stelle ich möglicherweise auch anderen Leuten zur Verfügung - optimalerweise können sie da auch Commiten.
5. Ich will wenig Arbeit damit haben, damit ich mich auf die eigentliche Entwicklung konzentrieren kann und nicht ständig mit dem DVCS kämpfen muss.

Das letzte Requirement ist für mich dabei das wichtigste. Ich will Software und Patches entwickeln - und das DVCS das mich dabei unterstützt MUSS in den Hintergrund treten - sonst ist es schlicht und ergreifend ein schlechtes Tool. Und das ist auch schon der Todesstoß für GIT. So viel kann ich schon mal verraten - eigentlich kann GIT diese Requirements (die ja wohl für ein DVCS selbstverständlich sind) nämlich gar nicht erfüllen.

Dazu kommt dann natürlich noch [wiki:2009/01/17/22.07 der Ärger den man mit dem Index hat].

Aber mal zu den Details.

Getrennte Patch-Entwicklung: Prinzipiell gibt es wohl zwei (oder drei) möglichkeiten. Die erste und die die sowohl im Manual als auch im IRC-Channel empfohlen wird ist das man doch einfach für jeden Patch einen branch macht. Die zweite und dritte Möglichkeit ist ein tool wie StGit oder TopGit zu verwenden. Beides sind externe Tools, die sich überhaupt nicht in GIT integrieren - und das bereitet eine Menge Probleme. StGit hab ich intensiver getestet - und von TopGit dass sogar in GIT-Kreisen als "kompliziert" gilt werde ich daher tunlichst die Finger lassen. Das Problem ist, dass man die Verwendung der Tools nicht mischen darf. Dazu ein Beispiel: Wenn man mit Mercurial PatchQueues arbeitet (das war letztlich mein Workaround, der wenigstens funktioniert!) dann sind die patchqueue Kommandos einfach weiter Subkommandos von hg - das bedeutet auch dass sie den vollen Repository-Status kennen und ihn in die Fehlermeldungen einbeziehen können. In der Praxis bedeutet dass, das wenn ich ein hg patchqueue Kommando absende und das Repository gerade in einem status ist der dazu nicht passt - dann kriegt man eine Fehlermeldung die einem nicht nur sagt das ein Problem aufgetreten ist, sondern auch was man tun kann um es zu lösen. (Leider sind die nicht immer perfekt, aber das ist wenigstens ein Start). Häuffig passiert das wenn man nach einem update von upstream die patches wieder anwenden will aber vergessen hat vorher den aktuellen status in hg zu commiten. Oder wenn man einen Patch verändert hat und zum nächsten wechseln will ohne das vorher aufzuzeichnen etc. Bei StGit ist das anders. Wenn da der Repository-Status nicht zu dem passt was StGit denkt das er wäre, dann wird das Repository einfach zerstört.

Yeah!

Bis man das dann gecheckt hat ist das Repository in einem Zustand, dass es weniger Arbeit ist mit diff und patch die patches wieder herauszufummeln als sich durch die diversen history-rewriting operatoren zu fummeln um doch etwas hinzubekommen was hoffentlich vielleicht doch das ist was man eigentlich hätte gewollt haben sollen. Oder so ähnlich.

Dazu kommt dass StGit die Patches schlicht als normale GIT-Revisionen speichert und die history-rewriting Möglichkeiten nutzt um das PatchQueue feeling aufkommen zu lassen. Und das ist dann auch der Grund wieso man StGit und Git Kommandos NIE, NIE, NIE mischen darf.

Bleibt also nur der erste Ansatz: Für jeden Patch einen Branch anlegen. Das wirkt eigentlich auch ganz Vernünftig, denn man kriegt dadurch eine Menge: Die History wird erhalten, man hat stabile Links in jeden Patch (ist ja nur ein Branch) und natürlich getrennte Entwicklung. Leider hört es da aber auf. Man kriegt nämlich keine Hilfe dabei die Patches als Layer übereinander zu legen - und besonders wichtig - wenig Arbeit damit zu haben.

Wenn von z.B. von upstream den aktuellen stand haben möchte, muss man das einmal für jeden Branch machen - und dann dort die Konflikte lösen. Hat man Abhängigkeiten zwischen den Patches (Bugfixes die aufeinander beruhen z.B.) wird es noch abenteuerlicher. Richtig toll wird es dann wenn man die ganzen Patches als Layer über sein eigenes Repository gelegt betrachten möchte. Unter GIT wird dazu empfohlen sog. "Integration" Branches zu verwenden - also Branches die man periodisch neu anlegt (mit sog. squash-commits) die aus einem anderen Branch nur noch einen einzigen Commit auf dem "integration" Branch machen. Das ist übrigens auch der Weg wie man aus den branches schöne patches macht - im integration branch. Das geile daran: Man muss das immer wieder machen - denn jedes mal wenn man die Patches weiterentwickelt muss man auch den integration branch komplett neu anlegen.

Ach ja, oder man schreibt natürlich in der History herum - aber dass hat letztlich den gleichen effekt - man hat eine Menge Arbeit und die URLS zu diesen Commits bleiben erst nicht die gleichen.

Ach genau, und es gibt natürlich noch Leute die Sagen History Rewriting geht und ist cool also mach es doch die ganze Zeit, dann bleiben auch deine Patches sauber. (Also im Prinzip das was StGit tut nur von Hand). Damit bin ich aber wieder meine Stabilen URLs los - und dass ist für mich nicht akzeptabel, weil ich dann wieder nix habe was ich in Bugreports verlinken kann)

Große Klasse.

Jetzt nachdem ich den ganzen Ärger durch hatte bin ich dann dabei angekommen dass ich schlicht keine Möglichkeit habe dem Upstream möglichst viel Arbeit abzunehmen und gleichzeitig Commit-URLs zu haben die sich nicht verändern (ach ja, dazu kommt noch das Upstream keine Branches in GITHUB mag - ich vermute mal dass ihnen das auch zu viel Arbeit ist). Na gut, wenn sie schon GIT verwenden müssen, dann dürfen sie auch die Extra-Arbeit machen.

Darum verzichte ich jetzt darauf saubere Patches bereit zu stellen, sondern Commite einfach in mein Repository und schiebe den 'master' nach GITHUB. Damit ist der Onus eben bei Upstream das sie möglichst häufig Mergen um die Übersicht nicht zu verlieren. Super ist das natürlich nicht - und mit jedem Code-Review von einem Patch den ich bereitstelle wird das dann halt unübersichtlicher.

Was ich daran nicht verstehe: Es kann nicht sein dass ich der einzige bin der diese Probleme hat. Jeder der Open Source Entwicklung mit GIT macht muss früher oder später darauf stoßen. Also was ist los?

Rein logisch betrachtet ergeben sich daraus eigentlich nur zwei mögliche Schlüsse:

• Entweder GIT-User sind einfach so geil auf ihr Tool, dass sie gar nicht merken wie viel Extra-Arbeit das Tool ihnen aufzwingt und sie sehen diese Komplexität einfach als notwendig statt als zufällig an.
• Oder aber sie haben, wie ich, einfach aufgegeben saubere History, einfaches merging für Upstream und getrennte Entwicklung von getrennten Patches zu betreiben.

Ich persönlich vermute letzteres - schon alleine um nicht alle Open Source Entwickler für blöde erklären zu müssen. Damit verstehe ich dann aber die Popularität von GIT gerade in OpenSource Projekten überhaupt nicht. Hier sind doch eigentlich gerade die Leute denen eine saubere und transparente Entwicklung wichtig ist?

Hier noch ein paar Pointer für diejenigen die aus der Git-Hölle entkommen wollen:

• Mercurial bietet mit den PatchQueues ein mächtiges Werkzeug an um diese Patch-Entwicklung und verfeinerung sauber gretrennt vom Repository vorzunehmen. Das schicke daran: diese Patchqueues sind Versioniert - aber vom Repository getrennt gespeichert. Dadurch lässt sich das auch ganz hervorragend über ein GIT/HG/SVN Repository drüberlegen - und man kann den ganzen Ärger mit GIT vermeiden. Dazu lassen sich diese Queues auch relativ einfach über BitBucket teilen, so dass man auch zu mehreren direkt an patches arbeiten kann.
• Bazaar hat Looms die in etwa wie hg patchqueues zu benutzen sind, aber dafür den Vorteil haben dass sie ganz regulär mit einem push an ein remote andere Repository übergeben werden können - damit ist Zusammenarbeit auch um ein Vielfaches einfacher. Und natürlich wird auch dort die Historie der Patches erhalten. (Für die Geschwindigkeits-Proleten noch ein Hinweis: Bazaar ist heute so schnell wie Git war als es erschien - wenn Git also damals für Kernel-Size-Trees geeignet war...)

Mit dieser These ist Robert Martin auf der RailsConf 09 aufgetreten - und hat ganz ohne Powerpoint in einer hoch spannenden Stunde diese These erklärt und hervorragend vertreten.

Ganz nebenbei liefert er dabei noch die beste Motivation für Test Driven Development die ich bisher gesehen habe.

unbedingt anschauen!

Und er erzählt dabei ein paar Geschichten. Ohne einen Punkt.

Das ist ein ganz interessanter Rückblick auf seine Vergangenheit, seine Meinung und Art wie er spricht.

Das Beste ist aber die Fragerunde am Schluss - in der wird es nämlich auf einmal richtig Politisch:

How is it, that the thing that I could do could contribute the most possible. I'ts gonna take getting involved with the people whose lives are affected by the programs that I write. Whether they're dockworkers, or policemen or whoever. They have to gain power in that process.

One of the Principloes that I've used always, always, is the principle of mutual benefit

I try to finde a way where everybody can do better out of the activities that I'm involved in. I fall short of that at times, but I'm always looking for that.

And I think software as an industry falls short of that. There are winners and losers in software development. And I think thats really too bad, because I think it's mostly a choice.

And I'd love to find a way to get past that.

Schaut euch den Kontext um dieses Statement an - es lohnt sich!

Hier gibt's den Vortrag

Ich hab schon eine Weile nach einem Ersatz für Textmate gesucht, da ich unbedingt beim Coden ein Outline view sehen möchte, in dem ich die Struktur einer Code-Datei wiederspiegelt. (Nicht nur ein Function Popup - das kann ja jeder, aber das ist eben nicht das gleiche.)

Well und heute hab ich einfach noch mal im TextMate Channel gefragt weil ich gerade auf der Suche war ob vielleicht in der nächsten Version von TextMate dieses Feature enthalten ist.

Und sie da: Command-Shift-T und man kriegt das Feature!

YES!

Neulich über Umwege bei Fefe gesehen:

Der Nistkasten Wolfgang S..

Ein Absolutes muss für den freiheitsliebenden Bürger. :)

Aus der Beschreibung: Gefühlte Sicherheit und Privatsphäre für unsere Singvögel!

Wer könnte da wiederstehen?

Bäh! = Ich hab mir heute mal mit einigen bekannten die doch etwas besser PHP können angeschaut wie man in die Wikipedia ein plugin einbaut.

Und boah, das ist echt superecklig.

Das geht schon damit los dass man an einen Array nicht vernünftig etwas anhängen kann. Denn, das muss man sich mal auf der Zunge zergehen lassen, arrays sind natürlich keine Objekte - dafür aber auch noch gleich dictionaries.

Und etwas anhängen an einen Array ist daher eine total schwierig. Es gibt zwar eine (globale!) Funktion - so in der art von array_push_value() oder so, aber das will niemand schrieben, desshalb gibt es dafür eine extra Syntax (!!!):

$someArray[] = "fnord";

Geil oder?

Und natürlich ist Wikipedia auch ein total gewachsenes Projekt, daher gibt es tausende von globalen Variablen die man manchmal überschreiben, manchmal anhängen und manchmal irgendwas machen muss.

Auf meine Frage wieso man so etwas so macht, fiel auch meinen Bekannten auch nur ein "das ist halt vermutlich so schneller" ein. Denn, der ganze Code muss ja für jeden Seitenabruf neu geparst werden.

Wie krass!

Und es ist nicht so das es dann für das Plugin registrieren eine Funktion gibt, in der man vielleicht noch ein Verzeichnis übergibt, wo dann nach einem standard-layout die ganzen Files drin sind. Nein! man muss x verschiedene globale variablen von hand anfassen.

kotz

Wers nicht glaubt, schaut selber nach!

Der Petitionsserver des deutschen Bundestags hat mal wieder eine vernünftige Petition - gegen die Internetsperren.

Hier ein Excerpt:

Wir fordern, daß der Deutsche Bundestag die Änderung des Telemediengesetzes nach dem Gesetzentwurf des Bundeskabinetts vom 22.4.09 ablehnt. Wir halten das geplante Vorgehen, Internetseiten vom BKA indizieren & von den Providern sperren zu lassen, für undurchsichtig & unkontrollierbar, da die "Sperrlisten" weder einsehbar sind noch genau festgelegt ist, nach welchen Kriterien Webseiten auf die Liste gesetzt werden. Wir sehen darin eine Gefährdung des Grundrechtes auf Informationsfreiheit.

Ist doch ein Start. Also zeichnen. :)

jeder will es sein, und fast niemand ist es wirklich. Zumindest ist das meine Beobachtung.

Um so besser dass es einige Firmen gibt die versuchen ihre Prozesse transparent zu machen und herzeigen wie sie Arbeiten.

Hashrocket hat z.B. einen Vimeo Channel auf dem sie immer wieder Videos veröffentlichen.

Besonders spannend finde ich das Video über ihren Daily Standup. Details wie der "Speakers-Ball" find ich einfach klasse. Sehenswert!

Ich beschäftige mich ja seit einiger Zeit intensiver mit Web-Entwicklung - und da im besondern mit Cappuccino um damit GUIs in WebBrowsern zu bauen.

Cappuccino ist zwei Sachen - eine dünne Schicht JavaScript die einen Translator implementiert der aus Objective-J (Quasi Objective-C für JavaScript) normales JavaScript macht und eine Bibliothek an Objekten die der [Cocoa Bibliothek] von Apple aus dem Gesicht geschnitten ist.

Und Cocoa ist immer noch die schönste und knackigste Bibliothek die ich kenne - allerdings kenne ich auch noch nicht so viele.

Um so spannender fand ich es daher eines der Beispiele des Cappucino Projektes noch einmal in jQuery implementiert zu sehen (Blog dazu)

jQuery ist nämlich eine Bibliothek die die Möglichkeiten von JavaScript (Closures!) mal wirklich vollständig ausreizt und soweit ich das beurteilen kann ein Musterbeispiel von richtig gutem JavaScript Code ist.

Auf der anderen Seite ist Cappuccino - eine Sprache die von C portiert wurde, und die daher eben keine Closures einsetzt - weder in der Sprache, noch in der Bibliothek.

Und das rennen fängt gut für jQuery an - jQuery braucht für das gleiche Beispiel nur 45 Zeilen Code, während Cappuccino mit 400 Zeilen dabei ist - und enthält an manchen Stellen sogar noch mehr Bling! (Die Bilder faden schön ein statt einfach nur zu erscheinen)

Schaut man sich die Beispiele genauer an, stellt man fest, dass bei jQuery zu den 45 Zeilen Javascript noch mal 200 Zeilen CSS kommen und dass der JavaScript Code völlig ohne Leerzeilen auskommt, während bei Cappuccino besonders auf übersichtlichkeit geachtet wurde.

Korrigiert man das und vergleicht erneut, dann sieht das Ergebnis etwas anders aus: jQuery + CSS ~= 200 Zeilen vs. Cappuccino ~= 200 Zeilen.

Whoa.

Also muss der Vergleich inhaltlich stattfinden: Cappuccino isoliert den Applikationsentwickler komplett vom DOM und seinen Schwierigkeiten, während jQuery natürlich komplett damit Arbeitet - und man sich auch selber um die Komplikationen kümmern muss die man mit der Browserkompatibilität hat.

Dafür ist der Code von jQuery inhaltlich wirklich sehr schön kurz - ich finde man sieht ganz hervorragend was man erreichen kann wenn man benannte Parameter (hier durch JavaScript Objekt-Literale Vertreten) und konsequenten Einsatz von Closures kombiniert.

Das hier zum Beispiel:

$.each(data.items, function(i,item){
   img = new Image();
   img.src = item.media.m;
   img.onload = function() {
        $(this).animate({opacity: 1}, "normal");
   }
   $(img).css({opacity: 0}).appendTo("#content").wrap("<div></div>");
   if ( i == 20 ) return false;
   });

ist einfach sehr ausdrukstark. Ich freue mich schon darauf wenn Apple Snow-Leopard herausbringt und damit Closures auch in Objective-C einzug halten - weil dann wird auch Cappuccino diese Möglichkeiten endlich nutzen ohne die Kompatibilität mit Cocoa zu verlieren.

Auf der anderen Seite finde ich den Objective-J Code wie bei Cocoa auch sehr ausdrucksstark - und vielleicht etwas verbose. Dafür dokumentiert sich der Code aber auch ganz excellent.

Und da er nicht länger ist als der andere, sehe ich da überhaupt kein Problem.

Alles in allem also ein guter Grund jQuery zu lernen um die Möglichkeiten von JavaScript wirklich mal zu verstehen.

Spannend wars, gestern das Interview mit De:bug natürlich gings um die ganzen Piraten-Sachen - wie wir vermitteln dass wir es ernst meinen, warum man uns wählen sollte, etc.

Für mich spannender war danach das Gegeninterview wo wir den Chefredakteur mal ein bisschen zu dem Magazin fragen konnten. Erst mal das Übliche, sie beziehen ca. 80% ihrer Einnahmen aus Anzeigen und nur ca. 20% aus Magazinverkäufen. Auch spannend, das Magazin lebt letztlich seit seiner Gründung von einem Monat auf den nächsten - etwas das ich inzwischen bei vielen Magazinen vermute - auch wenn man das auf den ersten Blick gar nicht sieht.

Aber: Seit die "Wirtschaftskriese" losgebrochen ist hat das Anzeigenvollumen nicht wirklich zurückgegangen (!) - allerdings hat sich das Verhalten der Kunden verändert. Jetzt wird nicht mehr ein Jahr im Voraus geplant und gebucht, sondern nur noch von Monat zu Monat. Und das macht natürlich schlechte Planungsmöglichkeiten.

Auch fand ich sehr spannend aus meiner Sicht als Agiler Softwareentwickler auf die Zeitungsproduktion zu schauen - Jeden Monat ein Produkt von hoher Qualität auf den Punkt produzieren. Und das ganze mit gigantischem Kommunikationsoverhead - schließlich geht es ja beim Magazinproduzieren um nichts anderes.

Spannend. :)