git

Für git gibt es ein Script das man einfach nur in seine Konfiguration einbinden muss. Erst dann macht das arbeiten mit vielen Branches (die am besten noch lange, sprechende Namen haben) erst richtig Spaß.

Um die git-completion zu nutzen muss man sich zuerst das git-completion.sh-Script aus der git Distribution besorgen, zum Beispiel via github.

Danach muss man noch folgende Zeile zur seinem .bash_profile oder .bashrc hinzufügen (vorausgesetzt man speichert das git-completion.sh unter ~ als .git-completion.sh, sonst muss man den Pfad den eigenen Vorlieben entsprechend anpassen:

source ~/.git-completion.sh

Anschließend kann man zum Beispiel seine Branchnamen per Tabulator auto-vervollständigen lassen.

ssh

Ich verbinde mich per ssh auf viele verschiedene Hosts mit teilweise doch recht langen Namen. Da ich den Username und key je nach Domain bereits in meiner ssh Konfiguration hinterlegt habe, benötige ich keinen Username mehr. Ein einfaches ssh $servername ist also für meine Zwecke vollkommen ausreichend. Um hier nun Autocompletion für die Servernamen zu aktivieren, kann man folgende Zeile in seine .bash_profile Datei eintragen:

Da hier die known_hosts Datei als Quelle für Servernamen verwendet wird, dürfen diese darin natürlich nicht gehasht sein, sondern müssen im Klartext vorhanden sein. Ansonsten gibt es noch Alternativen, die zum Beispiel die history auswerten. Unter Mac OS 10.6 funktioniert es jedenfalls wie oben beschrieben problemlos.

Maven

Auch für Maven gibt es bereits ein fertiges Script, dass man nur noch wie bei git einbinden muss. Leider wird es nicht mit Maven mitgeliefert, aber man kann sich die maven-bash-completion bei github ziehen. Eingebunden wird sie wie bei git mit einem

source ~/.maven-bash-completion

Vor einiger Zeit bin ich endlich auf den auf den Begriff Koan gestoßen, der für ähnliche Projekte benutzt wird und viel gebräuchlicher ist. Vor allem findet man unter dem Begriff Koan auch viele Projekte für andere Sprachen, zum Beispiel Python-Koans oder JavaScript-Koans.

Erster Tag

Unsere Entscheidung war jedenfalls goldrichtig. Der Freitag startet mit einem ausführlichen Frühstück bei dem alle auf ihre Kosten kamen. Gleich der erste Vortrag von Dr. Johannes Mainusch (Xing) zum Thema Abstract Monitoring war ausgesprochen gut! Das von Johannes gepredigte MacGyver Monitoring, also mal schnell was mit einfachen Mitteln (Munin + Logfiles + awk) zu monitoren, versuche ich öfter mal in die Praxis umzusetzen. Dabei impliziert der Name MacGyver schon, dass es sich nicht um einen kruden Hack handeln soll, sondern um eine einfache Lösung die auch funktioniert.

Der anschließende Vortrag zum Thema Projekt-Entwicklung in der Cloud kam dagegen nicht an. Mir persönlich ging der Vortrag viel zu wenig in die Tiefe, aber für komplette Neueinsteiger war die kurze Einführung in AWS & Co. sicher gut.

Nach dem sehr reichhaltigen Mittagessen ging es wieder sehr gut mit Many-Cores & Functional Programming von Prof. Dr. Friedrich Esser weiter. Der Vortrag war eine Einführung in die Vorteile funktionaler Programmierung mit vielen Seitenhieben auf die aktuellen OO Sprachen. Mit Get functional or get out! hat Prof. Esser seinen Vortrag passend zusammengefasst. Für die devcon war dieser Vortrag erfrischend theoretisch.

Der Titel Agile Entwicklung mit PHP des nächsten Vortrags hatte mich erst etwas abgeschreckt, letztlich hatte PHP aber gar keinen Anteil an dem sehr gelungenem Vortrag über extreme Programming. Lars Jankowfsky hat viele Zwischenfragen zugelassen und es war doch sehr interessant zu hören mit welchen Problem andere Teams zu kämpfen haben. Letztlich kochen alle doch nur mit Wasser und viele scheinen die gleichen Gäste zum Essen eingeladen zu haben.

Den Tag beendet hat Jens Fischer mit seinem Vortrag zum Website Performance Boosting für einen der Otto Shop-Systeme. Ein interessanter Einblick in die In-House Entwicklung bei Otto. Die Toolchain kam uns allerdings sehr bekannt vor, so dass es weniger etwas neues zu lernen gab, als viel mehr die Bestätigung dass es andere ähnlich machen wie wir.

Ausklingen konnte der Abend im 13. Stock nach einer kleinen Stadtrundfahrt in den bekannten Doppeldeckerbussen. Die Orga wirkte, als würde die Konferenz zum 10. Mal stattfinden… dabei war es ja die Premiere. Auf der Party habe ich mal wieder gemerkt, dass die Hamburger IT irgendwie ein Dorf ist: Jeder kennt jeden – irgendwie.

Zweiter Tag

Der zweite Tag begann mit leichter Verspätung. Die Baustelle am Hauptbahnhof und die vielen Getränke-Gutscheine von Xing waren wohl die schuld. Der erste Vortrag war Zero Bug Policy. Durchaus nah an der Praxis und mit einigen guten Hinweisen für den Alltag.

Beim Workshop Frontend Performance Tuning fühlte ich mich hingegen eher unwohl. Zum einen waren viele der Tipps aus meiner Sicht eher “snake oil” zum anderen wurden Backendentwickler einige Male gebasht…

Das Mittagessen hat die Stimmung aber wieder sehr gehoben und der Doppel-Workshop von Prof. Esser zum Thema Scala war ebenfalls sehr gut. Allerdings war es aufgrund der großen Teilnehmerzahl eher kein Workshop sondern eine Vorlesung, was dem ganzen aber nicht schlecht getan hat. Letztlich konnte ich für mich nicht viel neues mitnehmen, aber gelerntes noch einmal aus einem anderen Blickwinkel betrachten. Es war einfach ein guter Vortrag und die meisten Teilnehmer wollten sich später einmal näher mit Scala beschäftigen.

Als abschließenden Vortrag habe ich mir Testing untestable code angehört. Eigentlich ein tolles Thema, hat man es doch öfter mal mit legacy code zu tun. Leider war der Vortrag sehr stark auf PHP gemünzt (was leider aus dem Titel und der Beschreibung nicht klar hervor ging). Die Wege um untestbaren code zu testen verursachten dann auch manchmal eine Gänsehaut.

TL;DR

Die #dchh war absolut super! Die verschiedenen Themen und Schwerpunkte haben der Konferenz sehr gut getan. Die Organisation und die Verpflegung sowie der Veranstaltungsort bei Otto waren hervorragend.

Nur die Workshops waren etwas zu groß um wirkliche Workshops zu sein. Aber ob Vortrag oder Workshops war letztlich auch egal. Hoffentlich machen die Veranstalter ihr Versprechen wahr, so dass es auch 2012 wieder eine Developer Conference in Hamburg geben wird.

Das ist nur ein Ausschnitt, da will man nicht alles von Hand ändern

Beruflich nutze ich unter anderem Jenkins als Continous Integration Server. Wir haben recht viele Maven Projekte die damit regelmässig gebaut werden.

Bislang haben alle diese Projekte im Prinzip ein mvn clean install aufgerufen. Dadurch lagen immer die aktuellsten SNAPSHOTS im lokalen Maven Repository des Jenkins, jedoch nicht in unserem zentralen Maven Repository Manager. Es sollte also statt dem mvn clean install ein mvn clean deploy aufgerufen werden.

Um nun alle Projekte möglichst schnell und ohne viel Maus-Geschubse zu konfigurieren, habe ich die Jenkins Script Console verwendet. Mit der Scrip Console ist es möglich, Groovy Scripts auf dem Jenkins auszuführen, die zum Beispiel alle Projekte umkonfigurieren. Einige Beispiele für solche Scripts finden sich im Jenkins-Wiki. Um in allen Maven Projekten aus dem install ein deploy zu machen, habe ich das folgende Script gehackt (das sicher keinen Schönheitspreis gewinnt, aber als Vorlage dienen kann):

Das gute an iPhoto ist, dass es sich selber normalerweise alleine um die Ablage der Fotos kümmert. Man muss sich also keine eigene Ordnerstruktur ausdenken, denn diese Arbeit kann einem iPhoto (ähnlich wie auch iTunes bei Musik) abnehmen. Das ist bei einer Migration allerdings ein Nachteil, denn die Information zu welchem Album ein Bild gehört, steckt eben nicht in einer Ordnerstruktur sondern in den Dateien die iPhoto als Datenbank benutzt. Zum Glück bin ich auf das Tool Phoshare gestoßen, dass einen Export der iPhoto Datenbank in eine neue Ordnerstruktur macht die sauber von z.B. Picasa importiert werden kann. Die Versionen 1.4.4. und 1.4.5 kamen allerdings mit der AlbumData.xml die mein iPhoto angelegt hatte nicht klar:

Error: float() argument must be a string or a number

Offensichtlich fehlen in der Version 6.0.6 von iPhoto noch einige Zeitstempel im XML. Ein Patch kam allerdings innerhalb von wenigen Stunden, nachdem ich die Usermailingliste kontaktiert hatte. Damit hat Phoshare prima funktioniert, genau wie in der Anleitung beschrieben!

Seit gestern wissen das nun wahrscheinlich ziemlich viele Leute und es ist erstaunlich einfach. Im Scala-Interpreter reicht die Eingabe von 2.2250738585072012e-308 – mit einer passenden JVM jedenfalls. Die landet dann in einer Endlosschleife, das kann man als Personaler ja sicher als Absturz durchgehen lassen.

Oracle hat den Bug noch nicht anerkannt, geschweige denn gefixt.

Die Invalidation ist die Holzhammermethode, falls die minimal einstellbare Cache Zeit von 60 Minuten noch zu lang ist oder man nicht daran gedacht hat die Header in S3 entsprechend zu setzen. Dafür lässt Amazon sich jedes invalidierte File bezahlen (wobei die ersten Invalidations kostenlos sind).

Um Files zu invalideren muss man einen Batch-Invalidation-Request schicken. Leider ist hierfür die Tool Unterstützung noch nicht besonders gut. Files lassen sich weder über die AWS Management Console noch über die üblichen Kommandozeilen oder sonstigen Tools wie S3 Fox oder Cyberduck invalidieren – zumindest nicht unter Mac OS X. Außerdem ist es immer gut, solche Dinge auch von der Konsole aus erledigen zu können.

Die Lösung kommt in Form von cfcurl, einem Perl Skript, das curl wrappt um die Authentication Headers von Amazon zu setzen. cfcurl erklärt seine Einrichtung beim ersten Aufruf von selbst. Alternativ sollte man schnell mal den Quellcode überfliegen um eine Datei mit den eigenen AWS Credentials im passenden Format anzulegen.

Anschließend kann man cfcurl wie folgt aufrufen:

./cfcurl.pl --keyname=[friendly key name] -- [curl-options]

Damit hat man schon alles um die AWS Cloudfront API anzusprechen.

Für einen Invalidation Request legt man sich am besten ein XML File zurecht, das den InvalidationBatch Complex Type enthält:

<InvalidationBatch>
   <Path>/foo.txt</Path>
   <Path>/bar.jpg</Path>
   <CallerReference>my-batch</CallerReference>
</InvalidationBatch>

Als nächstes braucht man noch die Id seiner Cloudfront Distribution. Diese kann man sich ebenfalls über die API holen oder in der AWS Console nachschauen. Nun kann man zum Beispiel die beiden Dateien foo.txt und bar.jpg der Cloudfront Distribution wie folgt invalideren:

cfcurl.pl --keyname [my_key] -- -X POST -H "Content-Type: text/xml; charset=UTF-8" --upload-file [invalidate_request filename] https://cloudfront.amazonaws.com/2010-08-01/distribution/[distribution_id]/invalidation

Amazon braucht für die Ausführung eines solches Requests 10 bis 15 Minuten. Den Status der Requests kann man sich ebenfalls über die API anschauen:

cfcurl.pl --keyname [my_key] -- -X GET  https://cloudfront.amazonaws.com/2010-08-01/distribution/[distribution_id]/invalidation

“Leider” kannte ich den Vortrag von Matt schon, zumindest hatte ich bereits die Folien gesehen und auch das Paper gelesen. Trotzdem war es nach den Vorträgen von Werner Vogels der beste Vortrag des Tages.

Die Vorträge der AWS-User waren leider etwas zu kurz und von der Qualität durchmischt. Es ging jeweils zuviel Zeit für die Vorstellung der Firma drauf. Dadurch blieb für den technischen Teil zu wenig Zeit übrig. Den Vortrag von schneevonmorgen.com gibt es übrigens online. Interessant war zum Beispiel die Aussage von Plinga, dass sie sich auf die kleinen VZ Netzwerke spezialisiert haben, weil die Konkurrenz bei Facebook zu groß ist. Die anschließende Fragerunde hat die Kurzvorträge dann noch aufgewertet und letztlich lohnenswert gemacht.

Insgesamt gab es keine Überraschungen oder wirklich etwas Neues auf dem Event. Wer sich vorher schon mit AWS auseinandergesetzt hatte dürfte nicht allzu viel neues erfahren haben, aber dass war bei einem kostenlosen Event auch nicht zu erwarten. Es hat sich aber trotzdem sehr gelohnt: Werner Vogels wirkt sehr beeindruckend und Amazon hat es geschafft durch den Event meine Motivation zu steigern mich noch mehr mit der Cloud auseinanderzusetzen.

Deshalb finde ich die Idee von scala-labs echt gut. Man bekommt mehrere Unit-Tests vorgesetzt. Anfangs schlagen alle Tests fehl – es gilt die getesteten Scala Klassen, Traits und Objects zu reparieren und nebenbei das theoretische Scala Wissen praktisch anzuwenden.

Die scala-labs ersetzen sicher kein Buch, aber ich finde sie sind eine gute Ergänzung dazu. TDL (Test Driven Learning) eben.

[Update]
Nachdem ich inzwischen auch wirklich viele der Aufgaben bearbeitet habe, bin ich über ein paar Fallstricke gestolpert. Zum Beispiel sind die Dependencies eher veraltet. Außerdem wurde noch ein Release Candidate von Scala 2.8 verwendet. Diese Punkte habe ich einem Fork behoben.

[Update 2]
Inzwischen ist das original Projekt wieder besser gepflegt als mein fork. Am besten schaut man sich kurz beides an, bevor man loslegt.