Sonntag, 22. Mai 2011

Developer Conference Hamburg Day 1 Wrap Up

Die 1. Developer Conference in Hamburg begrüßte ab Freitag ihre Gäste im OTTO Forum. Schon im Vorfeld möchte ich mich herzlich bei den Organisatoren bedanken: eine super Veranstaltung! Und das zu einem extrem faieren Preis.

Los ging es erst einmal mit einem leckeren Frühstück bei dem meine Kollegen besonders die Mettbrötchen lobten. Nach der Begrüßung entschied ich mich dafür, an den beiden Facebook Workshops teilzunehmen. Für einen wirklichen Workshop war die Session leider zu voll. Matthias Lau zeigte die Basics einer Page die sich mit Facebook verbinden soll. Also den Einbau eines Login, Logout und Likebutton, sowie das Handling entsprechender Events mit dem Javascript SDK. Außerdem das Abfragen von Daten verschiedener Freunde mit der Graph API. Für mich war es erst mal nicht viel Neues. Interessanter fand ich die 2. Session in der Matthias Lau Anwendungsbeispiele und Learnings aus seinen Erfahrungen präsentierte. Auf jeden Fall spannend ist die Smatch Community, ein Produkt-Recommender, der Empfehlungen anhand der Facebook - Likes eines Users berechnet.
Meine Lieblings-Empfehlungen:

Mir gefällt Bonita,
weil mir Bonita Project auf FACEBOOK gefällt.

Mir gefällt Laserdrucker,
weil mir Adobe MAX auf FACEBOOK gefällt.

Ansonsten aber eine sehr gute Idee, mal schauen wie sich das weiter entwickelt. Außerdem nehme ich mit, dass reine Facebook Entwicklung (z.B. Canvas App) nicht immer sinnvoll ist. Nicht jeder hat Facebook, es gibt auch entschiedene Gegner, daher sollte man immer mehrgleisig fahren und sich nicht auf Facebook verlassen.

Vollgefuttert nach dem Mittagessen ging es weiter mit CouchDB, wenn die Entscheidung auch schwer fiel. Die CouchDB speichert JSON basierte Dokumente, auf die über REST zugegriffen wird. Jan Lehnardt ist ein sehr schneller Redner, dem man aber gut folgen kann. Für mich sind die interessantesten Learnings aus dem Vortrag die mobilen CouchDB Implementierungen mit denen man automatisch lokale CouchDBs auf dem mobilen Device mit einer DB auf einem Webserver synchronisieren kann, wenn das mobile Gerät gerade eine stabile Netzwerkverbindung hat. Ein super Feature, dass ein typisches Problem vereinfachen kann. Leider ist die mobile Couch immer noch ein fetter Download (ca. 10MB).  Das finde ich zu groß um sie in kleine Apps einzubetten. Sobald sich das ändert, werde ich mal ein bisschen herumprobieren.

Anschließend ging es weiter zu Many-Cores & Functional Programming von Prof. Esser. Language Bashing kombiniert mit in Code gegossener Mathematik vorgetragen von einem großartigen Redner. In dem Vortrag ging es vor Allem um parallele Programmierung und Prof. Esser zeigte mehrere Concurrency/Threading Probleme in Java (als Beispiel für OOP Sprachen). Natürlich um schon mal auf den Scala Workshop am Samstag zu verweisen. Daneben gab es Perlen wie: "Ich habe nichts gegen Ruby. Mein Hund heißt seit 8 Jahren Ruby" oder dem Untertitel des Vortrags "Get functional or get out".  Nach dieser Session war ich nicht mehr aufnahmenfähig, dabei ging es noch 2 Sessions weiter, bevor der Doppeldecker zur Party an die Schanze startete.

So sollte jeder Freitag sein!

Montag, 16. Mai 2011

Flex Sonar Plugin 0.4

Tolle Neuigkeiten vom Flex Sonar Plugin: Version 0.4 ist released. In der Vergangenheit hatte das Flex Sonar Plugin ein Problem mit Projekten mit modular aufgebauten Poms, was mit dieser Version behoben ist. Nehmen wir also an ihr habt eine Parent pom, ein App Modul/Artifakt mit der App, einen Core mit der Logik, welcher als SWC gebaut wird und eine WebApp zum Packagen. Euer Projekt sollte mit Maven und FlexMojos gebaut werden. Mit dem neuen Plugin reicht es aus in der Parent pom

<sonar.language>flex</sonar.language>
    <sonar.dynamicanalysis<false</sonar.dynamicanalysis>

in den Properties einzutragen.

In den settings.xml sollte auf das FlexPMD Repo verwiesen werden. Ein Beispiel Projekt findet ihr auf meinem Github Account. In euren settings.xml muss auf ein Adobe repo mit dem Flex Framework und auf ein Repo mit den FlexMojos verwiesen werden, damit ihr das Projekt mit Maven bauen könnt. Ansonsten könnt ihr auch nur einen Blick auf die poms werfen.

Die Installation von Sonar ist denkbar einfach. Man lädt Sonar herunter und das Plugin. Sonar wird entpackt und das Plugin wird ins plugin Verzeichnis geschoben. Dann findet man im Sonar Ordner unter bin eine ausführbare Datei, die man aufruft. Sonar läuft dann unter http://localhost:9000. Nun stellt man in seinem Jenkins genau diese URL für Sonar ein und klickt bei seinem Projekt den Haken "Sonar" an. Fertig. Baut man das Projekt, bekommt man nun einen Report wie hier von meinem Example Projekt.


Samstag, 14. Mai 2011

Versionskontrolle mit Git Teil 1

Versionskontrolle mit Git Teil 1

Einen lokalen Integrationserver zu haben und seinen Build mit Maven oder Ant wie in den Posts ab Continuous Integration Teil 1 beschrieben zu automatisieren ist eine tolle Sache. Richtig sinnvoll wird beides dann, wenn man in einem Team an einem Projekt arbeitet und sicherstellen möchte, dass dieses Projekt immer funktioniert (oder zumindest kompiliert).
Ein Versionskontrollsystem, bzw. Versionsverwaltung (auch mit SCM - source code manager - abgekürzt) hilft dem Einzelnen Versionen des Source Codes zu verwalten, besonders aber einem Team an gleichen Dateien zu arbeiten und die Änderungen zusammen zu bringen.

Es gibt eine ganze Reihe von verschiedenen System, die man als Entwickler-Team nutzen kann:
  1. Git
  2. Mercurial
  3. SVN
  4. CVS
sind wohl die am Moment populärsten. Ein großer Unterschied zwischen Git und Mercurial zu SVN und CVS ist, dass die Ersteren verteilte Systeme sind. Jeder User hat das gesamte Repository bei sich auf dem Rechner. Bei SVN und CVS gibt es hingegen ein zentrales Repository normalerweise auf einem (Web)Server.
Git hat den großen Vorteil, dass man selbst ohne Webserver, z.B. auf einem gemeinsamen Laufwerk, ein Repository zum Synchronisieren mit dem Team nutzen kann. Damit kann man ohne großen Aufwand in einem kleinen Projekt (z.B. zu zweit) eine vernünftige Versionskontrolle machen und auch ein CI System an Git anbinden.
Starten mit Git
Zuerst muss man Git installieren. Github ist nicht nur ein Gitserver, der umsonst für Open Source Projekte ist, sie haben auch eine sehr gute Hilfe.
Für das Installieren von Git unter Windows kann man sich an dem Github Tutorial orientieren. Die Schritte mit dem SSH Key kann man weglassen, wenn man nicht Github oder einen anderen Server bei dem man sich authentifizieren muss nutzen möchte. Der Installer/Gui für Git unter Windows msysgit ist aber auch sehr einfach ohne Tutorial zu installieren. Einfach herunterladen und starten.
Nach der Installation von Git unter Windows könnt ihr einfach im Explorer zu einem neuen Ordner browsen, mit der rechten Maustaste auf den Projektordner klicken und "Git GUI Here" wählen. Im Menü kann man dann "Create New Repository wählen" und den Pfad zum Projektordner angeben. Nachdem Anlegen des Repositories gebt ihr am besten über "Edit" und "Settings" Namen und Email an damit ihr das nicht bei jedem "push" machen müsst.
Ich benutze bei Git eher eine Shell als ein grafisches Tool. Mit msysgit könnt ihr einfach auf "Git Bash here" klicken und ihr bekommt eine Shell im richtigen Verzeichnis.
Nun legt einfach mal eine Datei namens readme.txt an. Dort kann man sein Projekt beschreiben. Git weiß nun noch nicht, dass es diese Datei verwalten soll. Gebt in eure Shell
git status
Dann sollte ihr eine Rückmeldung bekommen, dass readme.txt noch nicht getrackt wird. Mit
git add readme.txt
stellt ihr die Datei unter Versionskontrolle. Mit
git commit readme.txt -m "add readme"
macht ihr einen Commit, ihr stellt einen bestimmten Stand in euer Repository ein. Nun ändert einfach mal die readme.txt und schreibt "Erste Versuch mit Git" hinein und speichert das Ganze. Wenn ihr nun auf der Shell
git diff
eingebt, seht ihr den Unterschied von dem aktuellen Stand zum letzten Commit. Nun commited die Änderungen. Mit
git log
könnt ihr euch die letzten Commits angucken.