public enum SocialMediaNetwork {
    
    TWITTER("tw", "twitter"), 
    GOOGLE_PLUS("gp","googleplus"),
    UNKNOWN("","");
    
    // network short name
    private final String shortName;
    
    // network long name
    private final String longName;

    private SocialMediaNetwork(String shortName, String longName) {
        this.shortName = shortName;
        this.longName = longName;
    }

    public String getShortName() {
        return shortName;
    }

   public String getLongName() {
        return longName;
    }
    
    public static SocialMediaNetwork getEnumFromShortName(String shortName) {
        for(SocialMediaNetwork network: SocialMediaNetwork.values()) {
            if (network.getShortName().equals(shortName)) {
                return network;
            }
        }
        
        return UNKNOWN;
    }
}

Der Enumerator stellt fasst verschiedene SocialMedia-Netzwerke zusammen und stellt Strings bereit, die im weiteren Code benutzt werden. Hat man nun einen shortName kann man auch das passende Enum erzeugen.

Nehmen wir nun an, dass wir folgendes Json-Fragment haben:

{
    "id": "26565946",
    "network": "tw"
}

Dieses Objekt hat eine id, die wir durch einen String repräsentieren können und ein network, dass normalerweise ebenfalls ein String ist. Wir wandeln aber das network-Attribut in ein SocialMediaNetwork Enum um. Zuerst werfen wir noch einen kurzen Blick auf das Java-Objekt:

public class Identifier {
   private String id;
   private SocialMediaNetwork network;

   public String getId() {
      return this.id;
   }

   public SocialMediaNetwork getNetwork() {
      return this.network;
   }
}

Nach dieser Vorarbeit kommen wir zum eigentlichen Deserializer. Dieser wandelt den network-String in unser Enum um. In weiser Voraussicht gibt es im Enum eine statische Methode, die man im Deserializer gleich nutzen kann und somit sieht der Code folgendermaßen aus:

class SocialMediaNetworkDeserializer implements JsonDeserializer<SocialMediaNetwork>{

    public SocialMediaNetwork deserialize(JsonElement json, Type type, JsonDeserializationContext jdc) throws JsonParseException {
        return SocialMediaNetwork.getEnumFromShortName(json.getAsString());
    }
    
}

Der Deserializer implementiert immer den JsonDeserializer. Dieser bekommt als Generic noch den Typ des Objekts mitgegeben, in welchen das vorliegende Json deserialisiert werden soll. Das entspricht dann eben dem Rückgabewert der deserialize-Methode. In dieser Methode müssen wir die Logik implementieren, die dazu notwendig ist das Json-Artefakt in ein Java-Objekt zu deserialisieren. Wir nehmen dazu das JsonElement und stecken dieses als String in die statische Methode des Enums. Und erhalten schon unser Enum, oder wenn etwas schief geht den Fallback-Wert UNKNOWN.

Gson gson = new Gson();

Besser ist es jedoch den vorhandenen Builder zu benutzen, da man so das Gson-Objekt im Vorfeld etwas konfigurieren kann. Dadurch kann man die Ausgabe oder auch die Serialisierung/Deserialisierung beeinflussen.

Gson gson = new GsonBuilder().create();
// gson-object with pretty print output
Gson gsonPretty = new GsonBuilder().setPrettyPrinting().create();

Um die Umwandlung durchzuführen benötigt man natürlich entsprechende Java-Klassen. Als Beispiel nehme man folgenden JSON-String:

{
  "id": "file",
  "value": "File",
  "popup": {
    "menuitem": [
      {"value": "New", "onclick": "CreateNewDoc()"},
      {"value": "Open", "onclick": "OpenDoc()"},
      {"value": "Close", "onclick": "CloseDoc()"}
    ]
  }
}

Dazu kann man nun entsprechende Klassen implementieren. Der Einfachheit halber sind Getter und Setter nicht aufgelistet. Zum Beispiel:

class Menu {
   private String id;
   private String value;
   private Popup popup;
}

class Popup {
   private List<MenuItem> menuitem;
}

class MenuItem {
   private String value;
   private String onclick;
}

Sobald der JSON-String und die Java-Klassen vorhanden sind, kann man mit dem zuvor erzeugten Gson-Objekt die Transformation durchführen.

String jsonString = "<jsonString>";
Menu menu = gson.fromJson(jsonString, Menu.class);

Jetzt kann das menu-Objekt verwendet werden. Möchte man hingegen ein vorhandenes Model in einen JSON String serialisieren so geht dies ganz einfach mit:

Menu menu;
String json = gson.toJson(menu);

Die Samsung Treiber sind seit Mountain Lion nicht mehr unterstützt und bei dem Versuch zu Drucken war nur eine Fehlermeldung zu lesen, dass die Treiber aktualisiert werden müssen und man sich an den Hersteller wenden soll. Dies hatte ich auch gemacht und laut Samsung sind diese Treiber in der Entwicklung. Meine ganz persönliche Meinung ist aber eher, dass dieser Drucker nicht mehr unterstützt wird. Neuere Drucker sind nämlich bereits mit Treibern versorgt.

Die Lösung für das Problem ist das SpliX Paket für Cups. Diese Treiber muss man nur installieren und dann bei der Drucker-Installation einfach auswählen. Und schon funktioniert der Drucker wieder mit Mountain Lion.

Für 2013 habe ich als guten Vorsatz u.a. vorgenommen wieder regelmäßiger zu schreiben, und dafür auch mehr Ideen zu sammeln und mit Zeit zu schaffen. Hoffentlich funktioniert das auch wie geplant

Ein Kochbuch mit Rezepten

Das Buch beinhaltet 80 Rezepte. Jedes Rezept besteht aus einer Einleitung, einem Quellcode-Abschnitt und aus einer Erklärung des Codes. In der Einleitung wird kurz umrissen, worum es in dem Rezept geht. Hier findet man neben dem einführenden Text auch Screenshots und zum Teil Klassendiagramme, die den kommenden Aufbau verdeutlichen. Der Quellcode beschränkt sich auf das notwendigste. Es werden keine Methoden programmiert die vom wesentlichen ablenken. In der Erklärung wird dann ausführlich auf die Zusammenhänge im Code eingegangen. Sollte man mit dem Quellcode nicht auf Anhieb klar kommen, ist der letzte Abschnitt (“How it works“) unumgänglich.

Themenbereiche

Die Rezepte sind thematisch sortiert und zu logischen Blöcken zusammengefasst. Somit kann man – wenn man das Buch nicht nur als Nachschlagewerk nutzt – sich einen Themenkomplex genauer anschauen. Da ExtGWT schon sehr oberflächenlastig ist, sind viele der Themen in diesem Bereich angesiedelt. Was unter der Haube passiert wird bei den komplexeren UI-Elementen natürlich auch erklärt. Als Einstieg dient ein Kapitel über Panels und Windows. Im Themenbereich Tabs wird der Umgang mit der Tab-Steuerung erklärt, wie man diese programmatisch manipuliert und auch wie eine einfache Benachrichtigungsfunktion eingebaut werden kann, die den Benutzer auf Tab hinweist, welches sich nicht im seinem Fokus befindet, aber dennoch von seinem Interesse sein kann. Beispielsweise durch eine Änderung der Daten oder ähnliches.
Im Themenkomplex Buttons, Toolbars und Menüs sieht man neben der einfachen Benutzung von Buttons auch, wie man mit Actions arbeiten kann. Insbesondere in größeren Anwendungen ist dies von Vorteil und spart sehr viel Code. Dieses Vorgehensweise ist vor allem aus der Swing Welt bekannt, wird aber – nach meiner Erfahrung – in jedem größeren GWT-Projekt neu erfunden und reimplementiert. Warum also nicht gleich die Boardmittel von GXT nutzen.
Weitere UI-Kapitel beschäftigen sich mit den Formularen, der Tree-Komponente und ihrer Benutzung und der sehr genialen Grid Komponente von GXT. Die Benutzung von Templates wird vorgestellt und es wird eine Datenvisualisierung vorgstellt.
Dabei wird eine Komponente vorgestellt die nicht Bestandteil von GXT ist. Es handelt sich dabei um ein Plugin, das diese Funktionalität zur Verfügung stellt.
Abschließend findet sich noch ein Kapitel zum Thema Drag and Drop, was bei einer modernen Weboberfläche heute nicht mehr fehlen darf und ein Kapitel mit Advanced Tips, wowie eins über Themeing.

Die Advanced Tips sind richtig spannend. Hier wird Persistenz und das MVP Pattern vorgestellt. Daneben gibt es noch einen Abschnitt zu einem Server Push Mechanismus, was bspw bei Chat oder Anwendungen mit Realtime Daten interessant ist. Das Kapitel setzt vor allem auf Fremdbibliotheken wie Hibernate oder eben dem Server Push.

… und es gibt noch mehr

Die Appendices vom ExtGWT Rich Internet Application Cookbook haben es auch in sich. Das Event Handling wird noch kurz vorgestellt, der Umgang mit Exceptions, der unter GWT vor allem in Hinblick auf die Servlet Schicht nicht unbedingt ganz offensichtlich ist. Die Erstellung eigener Icons darf nicht fehlen und das GWT-RPC Konzept wird auf der Ebene vorgestellt, wie es für den Entwickler interessant ist. Und als Abschluß des gesamten Buches gibt es noch den Appendix zu File Uploads. Dort wird auch erklärt wie man den Fortschritt nachverfolgen kann und den Benutzer visuell informiert.

Fazit

Für mich wirkt das Buch durchdacht und ist ein Muss für alle ExtGWT Entwickler, die das Framework nicht schon bis ins kleinste Detail kennen. Leider ist noch die “alte” Version 2.2.5 von GXT behandelt, aber wie bereits erwähnt ist dies im Enterprise Umfeld nicht unbedingt ein Nachteil. Interessant ist das Angebot von Packt Publishing: Neben der Printausgabe bekommt man auch noch die eBook Version. Und das zu einem recht guten Preis.

Möchte man zu einem späteren Zeitpunkt den früheren Zustand wieder herstellen und weiterarbeiten kann man mit git stash pop oder git stash apply die gespeicherten Änderungen wieder einspielen. Wobei pop das Änderungs-Set auch aus dem Stash entfernt und apply die Änderung einfach nur anwendet.

Eine Übersicht der vorhandenen Stash-Objekte erhält man mit git stash list. Ist alles im Stash nicht mehr relevant, so kann man mit git stash clear alle Objekte verwerfen. Einzelne entfernt man einfach mit git stash drop.

Mein persönlicher Workflow bei einem Git Checkin ist:

• git status // was hat sich bisher geändert
• git stash // Änderungen weglegen
• git pull –rebase // Remote Änderungen abholen
• git stash pop // lokale Änderungen aus dem Stash anwenden
• git add (-u) // Änderungen in ein Commitset hinzufügen (-u: nur geänderte Dateien)
• git commit // lokale Änderungen commiten
• git push // ausstehende Commits zum Remote Repo pushen

Nun noch eine kurze Ankündigung in eigener Sache:
Demnächst gibt es hier eine Rezension vom “ExtGWT Rich Internet Application Cookbook“. Dabei handelt es sich um ein Buch zum Thema ExtGWT/GXT von Sencha. Da die Literatur in diesem Bereich sehr überschaubar ist, wird das Buch sicher sehr interessant werden. Vor allem da – um nicht schon zuviel zu verraten – hier neben den typischen Anfängerthemen auch noch einiges für die Forgeschrittenen GXT-Entwickler erklärt und vorgestellt wird.

Hierfür gibt es einen kurzen Befehl:

git log @{u}..

Weitere interessante Befehle für die SVN-Umsteiger folgen …

Im Laufe der Entwicklung muss man seine Software sehr häufigen ausrollen. Da gibt es das CI System, ein Demonstrationssystem, vielleicht noch Präsentations- und Testsysteme und am Schluss auch noch das Live-System.
Ein CI System erfordert schon, dass es eine Automatisierung gibt, damit man sein Produkt im aktuellen Zustand ansehen kann. Diese Skripte lassen sich zumeist auch gleich für die internen System adaptieren und somit bleibt eigentlich nur das Staging und das Live-System etwas außen vor, wenn diese nicht intern betrieben werden.
Ich habe schon einige Male die Situation gesehen, dass diese Deployment-Skripte Shell-Skripte sind, deren Aufruf nur eine beschränkte Personengruppe ausführt. Sei es Unwissenheit, wo die Skripte eigentlich genau liegen und wie diese funktionieren, oder einfach nur Ungewissheit, was das Skript tut, das einmal der Shell-Guru entwickelt hat. Dieser Zustand ist nicht optimal und es gilt eine Verbesserung zu finden.
Hier kommt der Hudson/Jenkins ins Spiel. Das Deployment zu dem CI-Server wird ja (hoffentlich) von diesem System durchgeführt, also kann man auch gleich weitere Deployments über spezielle Jobs triggern. In einem konkreten Fall wurden hierfür einfach Tasks angelegt, die zeitlich getriggert sind (bspw. für die Demonstration im Scrum-Prozess) oder die nur manuell angestoßen werden.
Da wir Shell-Skripte vorliegen haben nutzen wir einfach die Möglichkeit Shellskripte vom Hudson/Jenkins aufrufen zu lassen. Diese lassen sich übrigens mittels ssh auch remote anstoßen.

Was gewinnt man dadurch?
Dem Entwickler werden Bedenken genommen, da man nun eigentlich nur auf einen Startknopf drücken muss. Somit kann das Deployment eigentlich von jedem angestoßen werden. Und das heißt die Deployment Aufgabe kann im Team verteilt werden.

Wie verhindert man Doppeldeployments (etwa 2 verschiedene Builds deployen auf den gleichen Server)?
Um das Ausführen von Jobs zu verhindern, die nicht parallel ausgeführt werden dürfen, aber ansonsten unabhängig voneinander sind, kann man “Locks and Latches” benutzen. Dieses Plugin stellt ein Lock zur Verfügung, an das man die zu verknüpfenden Jobs bindet. So kann genau einer ausgeführt werden.

Gibt es weitere Vorteile?
Die Zeit für das Deployment kann man mitschneiden und basierend darauf die voraussichtliche Dauer für das nächste Deployment angeben. Auch kann man dann die einzelnen Schritte des Deployment-Shell-Skripts auf den Hudson/Jenkins auslagern. Bspw Emailversand, wenn das Deployment erfolgreich war oder fehlschlug.
Durch die crontab-Funktion des Hudson kann man auch die Skripte an Daten und Uhrzeiten koppeln. Und auch die gesamte Benachrichtigungs-und Trigger-Infrastruktur des Hudson/Jenkins verwenden.

Insgesamt sind alle Kapitel mit Comics versehen, die das jeweilige Thema mit Humor untermalen. Daneben gibt es immer wieder Kurzfassungen des Prinzips – kann man auch Merksätze nennen – und am Ende jedes Kapitels eine Zusammenfassung der besprochenen Themen, sodass man sich schnell einen Überblick verschaffen kann. Codebeispiele dürfen in einem Buch über Code natürlich nicht fehlen und diese sind in verschiedenen Sprachen verfasst, sodass die typische Ausrede “das ist ja nicht in meiner Sprache geschrieben, damit kann ich gar nix anfangen” nicht gilt. Interessant ist der dadurch gewonnene sehr kleine Einblick in andere Welten.

Die Themen im Überblick sind Coding Conventions, Code vereinfachen, Refactoring, Testing und ein Beispielprojekt.

Persönlich habe ich folgenden 3 Aspekte ausgewählt, die ich bei der Entwicklung verstärkt beachten will:

• Code muss leicht lesbar sein, nicht hochoptimiert (außer in Ausnahmen)
• Benutze nicht mehr als 4 Variablen pro Scope; mehr kann man nur schwerlich überblicken
• Kommentiere nur sparsam, der Code selbst sollte schon lesbar und verständlich sein

Bei Google Books kann man sich selbst einen kleinen Überblick verschaffen – sehr praktisch!

Den Port kennen wir schon also müssen wir nur noch den folgenden Befehl absetzen:

pwdx `lsof -i | grep 12345 | awk '{ print $2}'`

Das heißt wir suchen uns alle Prozesse, die einen Port geöffnet haben, dann filtern wir nach dem Port 12345 und suchen uns die Spalte mit der Prozess ID. Den Vorgang packen wir zusammen und übergeben das Ergebnis dem pwdx Tool und dieses ermittelt zu der gefundenen PID das Working Directory. Als Ergebnis erhält man soetwas:

22613: /home/phpmonkeys/glassfish-v3-01/glassfish/domains/monkeys/config

Jetzt sieht man, dass der Prozess genau der richtige ist und kann mit kill weiterarbeiten wie gewohnt.