Für jede Auflösung gibt es ein speziell angepasste Version:

• 1920×1200
• 1920×1080
• 1680×1050
• 1600×900
• 1440×900
• 1366×768
• 1280×1024
• 1280×800
• 1024×768
• 1024×768 (iPad)

Für jede Auflösung gibt es ein speziell angepasste Version:

• 1920×1200
• 1920×1080
• 1680×1050
• 1600×900
• 1440×900
• 1366×768
• 1280×1024
• 1280×800
• 1024×768
• 1024×768 (iPad)

Für jede Auflösung gibt es ein speziell angepasste Version:

• 1920×1200
• 1920×1080
• 1680×1050
• 1600×900
• 1440×900
• 1366×768
• 1280×1024
• 1280×800
• 1024×768
• 1024×768 (iPad)

Die Softwerkskammer ist eine UserGroup, die sich mit dem Thema Software Craftsmanship befasst — zu deutsch also dem Handwerk der Software-Entwicklung. Es geht dabei um den Austausch zwischen Software-Professionals, die ihren Arbeitsalltag damit verbringen, komplexe Software-Systeme zu entwerfen, zu entwickeln und zu warten. Dabei steht vor allem der Erfahrungsaustausch über Prozesse und Methoden im Vordergrund, die unabhängig von speziellen Programmiersprachen zum Einsatz kommen.

Die Softwerkskammer RheinMain trifft sich seit Januar 2012 einmal im Monat, das Februar-Treffen in den Räumen von Namics war für mich das erste — und von meinen Eindrücken möchte ich an dieser Stelle berichten.

2. Treffen der Softwerkskammer RheinMain bei Namics. Foto von Jürg Stuker.

Die anwesenden 20 Mann bilden einen tollen Querschnitt aus der Software-Branche, von technischen Projektleitern, über Rails-Web-Entwickler und ein nennenswerte Anzahl von Java- und .NET-Entwicklern bis hin zu den obligatorischen iOS-Freelancern. Nach der Vorstellungsrunde standen die lightning talks auf dem Programm. Hier ging es unter anderem um 10-Finger-Schreiben, Diagramm-Editoren und Tipps zu VidCasts, die von allen Anwesenden schnell zu einer großen Liste erweitert wurden. Der zweite Programmpunkt war die Besprechung einer Codezeile, die einige mitgebracht hatten und die jeden in einer Art persönlich repräsentieren sollte. Hierbei ergaben sich dann auch sehr interessante Diskussionen um Sprach-Konzepte, zu denen jeder Anwesende so seine eigenen Erfahrungen und Abneigungen mitbringt. Ich selbst habe eine Zeile vorgestellt, die ich in meinem Studiums-Blog beschrieben habe — mir ging es darum, zu zeigen, wie aus einfachsten (Linux-)Kommandos mithilfe von Verkettung sehr schnell und flexible komplizierte Aufgaben lösen kann. Den Abschluss bildeten dann die Auswahl des Buches für den Buchclub, hierbei wird innerhalb der nächsten Monate Working Effectively Legacy Code von Michael Feathers gelesen und besprochen. Ein knappes Protokoll des Meetings findet sich im Wiki der Softwerkskammer RheinMain.

Zu guter Letzt wurde sich des, ebenfalls von freundlicherweise von Namics zur Verfügung gestellten, Kasten Biers angenommen.

Mir hat das Treffen sehr gut gefallen, da hier in kurzer Zeit viele Themen kompetent angeschnitten werden, aber nicht zu sehr in die Tiefe gegangen wird, schließlich kann nicht jeder mit allem etwas anfangen. So hat man aber eine tolle Liste mit Themen, in die man sich nach eigenem Geschmack etwas aussuchen kann und hat aber auch direkt den passenden Ansprechpartner für weitere Details in der Gruppe. Den Besuch bei einem Treffen einer der vielen Softwerkskammern in Deutschland kann ich wirklich jedem, der mit Softwareprojekten zu tun hat, ans Herz legen.

Trotzdem ist sind diese Vergleiche immer wieder faszinierend. Gestern bin ich über The Great Web Framework Shootout gestolpert. Bei diesem Test werden mit Frameworks drei einfache „Hello World!“-Seiten umgesetzt: einmal als statische Antwort, einmal mithilfe einer Template-Engine und einmal mit Daten aus einer kleinen SQLite-Datenbank. Gemessen wird die jeweilige Antwortzeit der Frameworks bei diesen drei Seiten.

Was mich bei den dort gezeigten Zahlen extrem stutzig gemacht hat, war das miserable Abschneiden der PHP-Frameworks und besonders von Symfony2, obwohl der Tester darauf geachtet hat, APC zu aktivieren. Um diese Zahlen zu verifizieren habe ich einen eigenen Test mit Silex (dem kleinen Bruder von Symfony2) aufgesetzt. Den Quellcode dazu findet sich in diesem Pull-Request. Da ich inzwischen auch ein großer Fan von Python bin und sich zudem noch die Philosophie von Bottle und Silex sehr ähneln, habe ich dieses Framework zum Vergleich genommen. Beide Frameworks sind als Virtual Host konfiguriert, und werden mit Apache Bench ab -n 10000 -c 10 aufgerufen. Die Ergebnisse sprechen für sich. Mit Templating-Engine und Datenbank-Zugriff liefert Bottle 16.632 Anfragen pro Sekunde aus, Silex lediglich 378.

Micro bedeutet also nicht immer hohe Geschwindigkeit.

Der Kalender auf dem Hintergrund ist diesmal zusätzlich mit den Kalenderwochen versehen.

Für jede Auflösung gibt es ein speziell angepasste Version:

• 1920×1200
• 1920×1080
• 1680×1050
• 1600×900
• 1440×900
• 1366×768
• 1280×1024
• 1280×800
• 1024×768

Das Kommando

adb shell am start -a android.intent.action.VIEW -d 'http://www.google.de'

öffnet z.B. den Browser.

Even if Linked Data has been around for a while a solid standard for a JSON driven environment is yet to surface. JSON-LD has set its course to becoming this standard and goes great length in explaining their take on linked data in JSON.

In JSON-LD JSON data is enriched with information about its context enabling the client to explicitly know how to interpret this data. A simple example of JSON-Data with embedded linking information looks like this.:

{
"@context": "http://purl.org/jsonld/Person",
"@subject": "http://dbpedia.org/resource/John_Lennon",
"name": "John Lennon",
"birthday": "10-09",
"member": "http://dbpedia.org/resource/The_Beatles"
}

This example describes a person named „John Lennon“. By adding a namespace via the @context attribute the data becomes self-describing. The @subject enables the client to identify an this specific entry.

It is also possible to describe subsidiary entries of this object which could be given e.g. in a list.

This is good but not sufficient for my use case.

Defining relations

By following this design I have to include all related objects in the JSON messages. But I want to let the client decide which subsidiary objects he needs. What I really need is the possibility to define relations. In his blog entry „Linking in JSON“ Mark Nottingham shows that this need is not addressed properly or at all. JSON Reference and HAL do provide solutions but they are both lacking a way to define the context of the related objects. Only by knowing the context of a relation the client can decide which relation to follow and which to discard.

In my applictaion I’ve decided to stick with the JSON-LD syntax and add another property: @relations. This property is a list of relations for the object. Every relations describes the context of the related object in relatedcontext and states under which URL (href) this object can be fetched. The role attribute defines the kind of relation. Optionally the attribute list states, if the relation is actually a list of objects.

Example: Again, John.

In this example we use John again and define a relation to his wife Yoko Ono and to the singles he has written.

{
"@context": "http://purl.org/jsonld/Person",
"@subject": "http://dbpedia.org/resource/John_Lennon",
"@relations": [
  {
    "@context": "http://coderbyheart.de/jsonld/Relation",
    "relatedcontext": "http://purl.org/jsonld/Person",
    "role": "http://gmpg.org/xfn/11#spouse",
    "href": "http://dbpedia.org/page/Yoko_Ono"
  },
  {
    "@context": "http://coderbyheart.de/jsonld/Relation",
    "relatedcontext": "http://dbpedia.org/ontology/Single",
    "role": "http://dbpedia.org/ontology/writer",
    "href": "http://dbpedia.org/resource/John_Lennon/singles/",
    "list": True,
  }
],
"name": "John Lennon",
"birthday": "10-09",
"member": "http://dbpedia.org/resource/The_Beatles"
}

In this way the client can be told that if he follows the (fictive) link http://dbpedia.org/resource/John_Lennon/singles/ he’ll receive a list of Singles written by John. It’s up to the client to decide a person object exists in his application with a relation to singles.

Conclusion

The solution presented above enables us to transfer just the minimum amount of required data but still gives the client the possibility to discover and fetch related objects.

Das Thema Linked Data geistert ja nun schon eine Weile durch die Branche, noch hat sich besonders im JSON-Umfeld noch kein wirklicher Standard etabliert. JSON-LD versucht dieser Standard zu werden und hat auch schon sehr ausführlich dessen Syntax beschrieben.

In JSON-LD werden JSON-Daten mit Informationen zum Kontext angereichert, so dass der Verwender der Daten erkennen kann, wie diese zu interpretieren sind. Ein einfaches Beispiel eines JSON-Datensatzes mit Linked Data-Zusatzinformationen sieht so aus:

{
"@context": "http://purl.org/jsonld/Person",
"@subject": "http://dbpedia.org/resource/John_Lennon",
"name": "John Lennon",
"birthday": "10-09",
"member": "http://dbpedia.org/resource/The_Beatles"
}

Diese Beispiel beschreibt einer Person, deren Name „John Lennon“ ist. Der Unterschied zu normalem JSON und JSON-LD ist der, dass dieses Objekt sich eindeutig selbst beschreibt und so ohne Mehrdeutigkeit in jeder Anwendung verwendet werden kann, die mit @context ein eindeutiger „Namesraum“ angegeben wird, der die Bedeutung der Daten beschreibt. Mit @subject ist es dann möglich den konkreten Datensatz eindeutig zu identifizieren.

Die Informationsanreicherung für untergeordnete Elemente, die z.B. als Liste vorliegen ist mit JSON-LD ebenfalls möglich.

Soweit, so gut — aber eben für meinen Anwendungsfall nicht ausreichend: Ich möchte nicht bei jeder Nachricht alle zugehörigen Objekte mitliefern, sondern den Client selber entscheiden lassen, was er benötigt.

Verweise definieren

Die Spezifiktion geht davon aus, dass eine JSON-Nachricht immer die zu einem Objekt gehörenden Kind-Elemente enthält. Sie sieht aber nicht die Möglichkeit vor, Verweise zu weiteren Datensätzen zu definieren. Mark Nottingham zeigt in seinem Blog-Eintrag „Linking in JSON“, dass dieses Problem auch in anderen Linked-Data-Ansätzen nicht zufriedenstellend gelöst wird, auch wenn es mit JSON Reference und HAL mindestens zwei Ansätze gibt, fehlt beiden jedoch die Möglichkeit den Kontext der verknüpften Daten zu definieren, denn Anhand des Kontexts einer Relation kann der Verwendern erkennen und entscheiden, ob es für ihn Sinn macht, eine Relation weiter zu verfolgen.

In meiner Anwendung habe ich mich entschieden in der Syntax von JSON-LD zu bleiben und ein weiteres Element ein zu führen: @relations. Dieses Element ist eine Liste von Relation die zum jeweiligen Objekt gehören. Jede Relation beschreibt dabei mit relatedcontext, welchen Kontext das andere Objekt hat und unter welcher URL (href) dieses Objekt abgerufen werden kann; mit role wird die Art der Beziehung beschrieben. Optional gibt das Attribut list an, ob es sich um eine Liste von Objekten handelt.

Beispiel: John, mal wieder

Im Beispiel verwenden wir wieder John und definieren eine Relation zu seiner Frau Yoko Ono, sowie zu den Singles, die er geschrieben hat.

{
"@context": "http://purl.org/jsonld/Person",
"@subject": "http://dbpedia.org/resource/John_Lennon",
"@relations": [
  {
    "@context": "http://coderbyheart.de/jsonld/Relation",
    "relatedcontext": "http://purl.org/jsonld/Person",
    "role": "http://gmpg.org/xfn/11#spouse",
    "href": "http://dbpedia.org/page/Yoko_Ono"
  },
  {
    "@context": "http://coderbyheart.de/jsonld/Relation",
    "relatedcontext": "http://dbpedia.org/ontology/Single",
    "role": "http://dbpedia.org/ontology/writer",
    "href": "http://dbpedia.org/resource/John_Lennon/singles/",
    "list": True,
  }
],
"name": "John Lennon",
"birthday": "10-09",
"member": "http://dbpedia.org/resource/The_Beatles"
}

Dem Verwender kann so mitgeteilt werden, dass wenn er dem (fiktiven) Link http://dbpedia.org/resource/John_Lennon/singles/ folgt, er eine Liste von Singles erhält, die John geschrieben hat. Es bleibt aber Sache des Verwenders zu entscheiden, ob er in seiner Anwendung überhaupt ein Personen-Objekt definiert hat, dass Verweise auf Singles enthält.

Fazit

Der gezeigte Lösungsansatz ermöglicht es, die Menge der übertragenen Daten in einer JSON-Nachricht gering zu halten, gleichzeitig bleibt aber die Möglichkeit bestehen, zugehörige Objekte erkennen und nachladen zu können.

Über die Feiertage habe ich Auslastung um einige Funktionen erweitert.

Die wichtigsten Änderungen im Überlick:

• Es gibt nun eine übergeordnete Spalte für Termine und Feiertage (#6 und #42)
• Aufgaben können als "im HomeOffice" markiert werden (#43).
• Namen von Personen, Units und Disziplinen müssen nicht mehr mindestens 3 Buchstaben lang sein (#38).
• Pläne mit vielen Daten laden jetzt auch (#31).

Die Liste aller Änderungen findet sich in der Timeline.

Eine vollwertige Test-Version der Anwendung findet sich unter http://auslastung.coderbyheart.de/.

Screenshots? Gerne.