Tag Archives: Softwareentwicklung

XII. Captain Casa Community Meeting


Flattr this

Motivation

Seit ich vor 8 Jahren im Java Magazin einen Artikel von Björn Müller gelesen hatte, interessiere ich mich für das Captain Casa Framework. Die Captain Casa GmbH führt seit Ihrer Gründung 2007 jährlich ein Community Meeting durch. Auf diesem treffen sich Nutzer und Lizenznehmer der Captain Casa GmbH, sowie Partner als auch generell Rich Client Interessierte. Zu Letzteren zähle ich mich und so nutze ich hin und wieder die Möglichkeit am Treffen teilzunehmen. 2016 bot sich für mich zur Teilnahme an, da bereits in der Vorankündigung große Dinge, in Worten „RISC HTML“ ihre glänzenden Strahlen vorausschickten. 

Organisation

Die Treffen an denen ich persönlich teilgenommen habe fanden bislang stets in Eppelheim statt. Dieses Jahr wurde ich durch eine Einladung nach Schwetzingen überrascht. Für mich als Besitzer einer Bahn Card ist Schwetzingen von Nürnberg her besonders günstig zu erreichen. Mein Hotel buchte ich keine 5 Gehminuten vom Bahnhof Schwetzingen entfernt. Der Veranstaltungsort (ein modernes Gemeindehaus) lag ebenfalls nur wenige Gehminuten sowohl vom Bahnhof wie auch vom Hotel entfernt. Da der Zeitpunkt des Treffens in der beginnenden Vorweihnachtszeit lag, konnte ich am Vorabend noch über den Weihnachtsmarkt schlendern und in aller Ruhe ein Souvenir für zu Hause auswählen. Für eine Schlossbesichtigung reichte die Zeit meines Aufenthalts leider nicht aus aber dieses Vorhaben wird in Zukunft nachgeholt. 

Teilnehmer

Wie auch schon in der Vergangenheit kamen vorwiegend proffessionelle Nutzer des Captain Casa Frameworks. Neu für mich war ein scheinbar gewachsener Anteil englischsprachiger Nutzer für die eine Simultanübersetzung angeboten wurde. Weiterhin hatte das Treffen auch Rich Client Interessierte Freiberufler angelockt, welche offensichtlich in Projekten in denen das Captain Casa Framework eingesetzt wird unterwegs sind. 

Stimmung

Auch an der Stimmung hat sich im Laufe der Zeit nichts geändert. Es war wieder eine sehr harmonische Stimmung unter den Teilnehmern. Viele kannten sich bereits durch vorangegangene Treffen und tauschten rege Ihre Erfahrungen über das Framework aus. Alle äußerten sich positiv zum Einsatz des Frameworks und lobten den hervorragenden Support der Captain Casa GmbH.

Inhalt der Veranstaltung

Generell lässt sich der Inhalt in folgende Bereiche einordnen:

  • Rückblick auf das letzte Treffen mit aktueller Markt- und Trendanalyse
  • Erfahrungsberichte von Unternehmen bzw. Captain Casa Nutzern.
  • Vorstellung technologischer Neuerungen durch die Captain Casa GmbH.
  • Ausblick und Roadmap über die weitere Entwicklung des Frameworks
  • Blick über den Tellerrand – ein Gastvortrag zur Architekturdokumentation

Markt- und Trendanalyse

Dass sich in der Vergangenheit bei der Entwicklung von Webanwendungen große Veränderungen ihren Weg bahnten und zu einer neuen Ära in der Sparte führten musste nicht erwähnt werden. Daher begann das Meeting auch gleich mit der Positionierung und Einordnung des Captain Casa Frameworks in den bestehenden Markt. Das wiederum ist aus meiner Sicht ein wirklich sehr wichtiger Punkt. Die Captain Casa GmbH, welche mit ihrem Framework bislang Swing, JavaFX und HTML Clients unterstützte, ist nicht ausgezogen um sich mit Giganten wie AngularJS etc. zu messen, sondern verfolgt ihren bewährten Weg weiter.

Das Captain Casa Framework ist für den Bau von Anwendungen erdacht, welche durch Power User genutzt werden. Natürlich nutzt auch ein Entwickler ein Office oder ein Mailprogramm aber sein Powerprogramm ist die IDE. Andere Anwender wie Dispatcher oder Anlagenfahrer benötigen evtl. auch Office oder Mailprogramme oder ähnliche Software aber auch sie haben ein Powerprogramm in welchem sie ihre Hauptarbeitsgänge erledigen. Möglicherweise werden Schaubilder mit Maschinen erstellt, mit Datenquellen hinterlegt und in einen Ablauf gebracht. Vielleicht müssen auch Güter verwaltet oder gelagert werden oder oder oder. Auf jeden Fall wird es etwas geben was der Nutzer zu Beginn seines Arbeitstages als Programm startet um damit möglichst viele seiner Tätigkeiten durchführen zu können. Genau für den Bau solcher Programme ist das Captain Casa Framework erdacht worden und genau hier spielt es seine Stärken aus. Wer allerdings einfach ein Portal seiner Firma ins Internet setzen möchte, dem genügen Technologien von Google und Co. Da muss nicht noch ein neues Framework geschaffen oder ein Bestehendes umgebaut werden. 

RISC HTML – die neue Technologie

Offensichtlich gab es nach dem letzten Community Meeting eine Phase welche Björn Müller inspirierte die bestehende HTML Technologie des Captain Casa Frameworks zu optimieren. Der Vorteil einer HTML GUI ist im Prinzip die Zero Installation. HTML benötigt einen Browser und der ist beim Endnutzer in der Regel verfügbar. Leider gibt es dabei aber auch einen Nachteil, es gibt nicht nur einen Browser. Was im IE läuft sieht im Chrome schon ganz anders aus und ist im Mozilla evtl. gar nicht mehr sichtbar oder anders herum. Damit sich der Entwickler letztlich nicht mit diesen Dingen rumschlagen muss gibt es genau solche Frameworks wie das Captain Casa Framework. Diese sorgen mit Magie einfach dafür, dass es in jedem Browser gleich aussieht und auch gleichartig funktioniert. Die neue Magie des Frameworks heißt nun also RISC HTML. 

Was genau aber ist nun RISC HTML? Hinsichtlich der Erfahrungen welche vor Jahren bereits im Hardwarebereich gesammelt wurden, nämlich der Umstieg von CISC auf RISC Technologie wurde auch das Framework überarbeitet. Genau wie beim Prozessor wird auch beim HTML eigentlich nur ein kleiner Satz von Elementen benötigt um eine ganze Anwendung aufzubauen. So könnten evtl. Rechtecke und Texte vollkommen ausreichen um das Layout einer Seite zu berechnen. Wir erinnern uns dabei natürlich sofort an das Prinzip des Textsatzsystems Latex zurück. Hier wird alles was darzustellen ist als Rechteck beschrieben und relativ zu einem umgebenden Rechteck positioniert. Mit einem DIV Tag und einer absoluten Positionierung im CSS Style wäre so etwas auch im HTML möglich. Der Legende nach war dies der erste Versuch im Werdegang von RISC HTML, die Darstellung von 20000 absolut positionierten DIVs im Browser. Voila es funktioniert – nun gut das hätte auch jeder erwartet dafür sind Browser ja gebaut worden. Jetzt noch die Zeit gemessen und mit einer Referenzimplementierung in Swing und JavaFX verglichen und uuuupps ist das schnell. So in etwa stelle ich mir die Geburtsstunde von RISC HTML vor. 

In weiteren Versuchen stellte sich dann wohl heraus, dass diese Methode tragfähig ist und etwa mit 4 Grundelementen auskommt. Aber wer genau setzt sich jetzt hin und schreibt die absoluten Positionierungen an die HTML Elemente? Nein natürlich nicht der Entwickler, das erledigt der Layoutmanager. Diesen kennen wir bislang nur aus der Swing und JavaFX Ecke und so fragen wir uns wie genau dieser denn jetzt ins Spiel kommt. Ganz einfach: Layoutmanager ist Logik und Logik auf HTML Seiten wird in JavaScript realisiert. 

Der Vorteil dieser Technologie liegt auf der Hand. Es gibt einen Kernel welcher für das Rendering und Verhalten der (4) definierten Grundelemente Sorge trägt. Also dafür sorgt, dass diese von jedem Browser gleichartig verarbeitet werden. Darauf aufbauend gibt es eine Schicht in welcher diese Grundelemente solange kombiniert und aggregiert werden, bis eine Vielzahl neuer Komponenten daraus entstanden ist. In dieser Schicht lassen sich dann auch eigene Komponenten erstellen. 

One Pass Rendering

Kennen Sie diesen Effekt wenn Sie auf einem leistungsschwachen Tablet eine herausfordernd überfrachtete Webseite modernster Bauart ansteuern und gerade einen schmalen Button klicken wollen, doch noch in der Bewegung ihres Fingers wird die Seite neu layoutet und der Button ist jetzt woanders und sie drücken dadurch an gleicher Stelle nun auf einen Link der eine Seite lädt die sie gar nicht sehen wollen und welche sich noch langsamer aufbaut als die vorherige? Dieser Effekt liegt am layouting Mechanismus der Browser. Größe und Position der dargestellten Elemente ist erst bekannt wenn diese auch dargestellt werden. 

Bei RISC HTML ist das anders. Hier kennt jedes der Elemente seine Größe vorher durch die absolute Positionierung und dem Layoutmanager. Ändert sich die Größe eines Elements wird ein dirty Event an das umgebende Element gesendet. Dieses meldet ebenfalls dirty und so weiter. Es entsteht ein kurzzeitiger Event Sturm nach oben bis zum äußersten Element. Dieses sammelt in aller Ruhe alle Events ein und wartet dabei bis auch die letzte dirty Meldung eingetroffen ist. Erst jetzt sendet es ein render Event zurück und alle Elemente berechnen ihre Position im umgebenen Element neu. Da die Berechnung von außen nach innen erfolgt ist die Position des äußeren Elements stets bekannt und fest. Damit kann es nicht zu dem anfangs beschriebenen Verhalten kommen.

Page Bean Components

Von vielen in der Community scheinbar unbemerkt, haben die Page Bean Components ihren Weg in das Captain Casa Framework gefunden. Page Bean Components bieten dem Entwickler die Möglichkeit das Framework um eigene Komponenten zu bereichern und als eigenständige Deliverables in Form von JARs auszuliefern/auszutauschen. Ganz klar ein Punkt Richtung Community – hier kann sich jeder zum Komponenten Provider herauf schwingen und damit nicht nur für sich selbst sondern auch für andere Entwickler hilfreiche Dinge zur Nachnutzung erstellen. Die genaue Erstellung solcher Komponenten würde den Rahmen dieses Artikels sprengen, wird aber vorgemerkt als zukünftig eigener Artikel auf meinem Blog. 

Ausblick

Zukünftig möchte die Captain Casa GmbH das Framework vorwiegend im Bereich RISC HTML weiter entwickeln. Die Swing und JavaFX Clients verbleiben im Wartungsmodus bis die Community keine weitere Unterstützung wünscht. Diese Priorisierung soll sich zukünftig auch im Lizenzkostenmodell widerspiegeln. Änderungen an den Open Source Lizenzbedingungen (Binary License) sind mir auf dem Treffen nicht bekannt geworden, dennoch sollten diese vor einer Realisierung selbstverständlich gelesen und für das jeweilige Vorhaben geprüft werden. 

Am Rande des Tellers

~ bleibt immer noch Luft für weitere Dinge. Zum Beispiel für eine schöne automatisierte Architekturdokumentation. Der Gastredner Falk Sippach nutzte im Rahmen eines aufgelockerten Vortrages die Vorteile von Dokumentation an den Teilnehmer zu bringen. Hier merkte man sofort die praktischen Erfahrungen auf dem Gebiet und es baute sich die Hoffnung auf nun doch noch endlich alles dokumentieren zu können ohne Redundanzen und ohne Wenn und Aber. Der Redner kannte sich aus mit den üblichen Fallstricken und benannte Lösungen. So geht der Trend eindeutig in Richtung plain text basierter Dokumentation. Natürlich documentation as a code also im Versionskontrollsystem hinterlegt, idealerweise gleich beim Code (genau wie bei den fachlichen Stories von BDD).  Zielgruppen gerechte Dokumente generiert im üblichen Build Prozess. Die verfügbare Palette an Werkzeugen scheint schier grenzenlos und wartet nur auf ihre Entdeckung. Allein die Kombination der Werkzeuge zur gut geölten Werkzeugkette scheint das Salz in der Suppe zu sein. Hier muss wohl jeder für sich entscheiden welche Werkzeuge er warum und in welcher Reihenfolge einsetzt. Einige mir nützlich erscheinende Buzzwords möchte ich dennoch unkommentiert fallen lassen: asciidoc, asciidoctor, markdown, yed, plantuml, ditaa, graphiz, jQAssistant. 

Schlußwort

Aus meiner Sicht war es wieder ein sehr schönes und interessantes Community Treffen. Die Captain Casa GmbH hat einmal mehr gezeigt, dass sie ein steter Quell sowohl nachhaltiger als auch revolutionärer Ideen ist. Zusammenfassend hat sich bei mir der Eindruck gefestigt, dass es sich beim Captain Casa Enterprise Client auch weiterhin um ein sehr gutes, solides und fantastisches Framework handelt.

Hinweise und Kommentare zum Artikel sind wie immer ausdrücklich erwünscht.

Fundry – Ein Nachruf


Flattr this

Fundry – der Einstieg

Es muß Anfang 2011 gewesen sein als ich das Portal fundry entdeckte. Die Aufgabe des Portals beschrieb Fundry selbst wie folgt:

Crowdfunding
Fundry is a crowdfunding platform that helps developers get paid for developing new features, and enables a community of funders to contribute to get the features they want. Win win.

Die Idee fand ich gut und da ich sowohl Open Source Projekte durchführe, wie auch andere nutze, stieg ich ein.

Viele Projekte waren bereits registriert. Einige davon interessierten mich besonders, da ich mir bei diesen neue Features wünschte. Also überwies ich per Paypal einen Betrag von ca. 50$ und stellte meine Bitten bei den einzelnen Projekten ein.

Je Feature konnte ich einen beliebigen Betrag setzen und bei Bedarf zurücknehmen oder erhöhen. Das ganze ging solange, bis das Feature von den Entwicklern fertiggestellt wurde. Dann wurde ich gefragt ob ich das Feature so akzeptiere oder nicht.

Hier setzte nun ein ausgeklügeltes System von Bedingungen ein, welches entschied ob der Entwickler das Geld für die Fertigstellung des Features erhielt oder nicht. Falls ich mit dem Feature zufrieden war und es akzeptierte wurde mein Geld auf jeden Fall an den Entwickler ausgezahlt. Falls ich nicht zufrieden war, kam es auf die Bewertung der anderen Funders an. Wenn die meisten das Feature akzeptierten bekam der Entwickler die gebotenen Einsätze, anderenfalls nicht.

Fundry – die Praxis

In der Praxis sah die Sache dann für mich letztlich wie folgt aus. Nachdem ich meine Bitten eingestellt und mit verschiedenen Beträgen versehen hatte passierte – nichts. Der Status der Bitten änderte sich nicht. Auch sah ich bei meinen Projekten nicht, das andere Features in den Status „in Arbeit“ gingen. Anfangs schaute ich häufig nach was sich tat. Dann immer seltener.

Irgendwann stellte ich mir die Frage wie sich das Portal wohl finanzieren würde. Dann war es mir plötzlich klar – warum sich da nichts am Status änderte 🙂 Da das Portal im Ausland gehostet war und ich mit meinem schlechten Englisch keinen Weg gefunden hatte das Geld wieder zurück zu ordern, beschloss ich zu warten und die Sache zu beobachten.

Fundry – das Ende

Das Ende war kurz und schmerzlos. Heute fand ich die Mail welche mich bereits vor 3 Tagen erreichte. In der heisst es:

I’m sorry to announce that we will shortly be shutting down Fundry.com.

We appreciate the effort all our developers and funders have put in over the last 18 months, but unfortunately the service is currently not financially sustainable, and we can no longer commit to supporting it. …

Und tatsächlich, es wurde eine Möglichkeit beschrieben wie das Geld zurückerstattet wird. Diese habe ich gleich genutzt und siehe da, es wurde nicht nur das Geld sondern zusätzlich auch eine Paypal Gebühr (von der ich gar nicht weiss ob ich sie je gezahlt hab) in der folgenden Stunde zurückerstattet.

Fundry – Zusammenfassung

Im Nachhinein betrachtet war die Idee richtig gut und die Leute tatsächlich ehrlich. Vorher war es mir egal ob das Portal existierte oder nicht aber jetzt habe ich das Gefühl, das wieder etwas Gutes kaputt gegangen ist 😦 Warum das Portal offiziell nicht lief weiss ich nicht. Aus meiner Sicht werden wohl alle gedacht haben, das sie ihr Geld nie wieder sehen. Aber auch das kann nicht der Hauptgrund gewesen sein.

Bleibt zu hoffen, dass jemand mit mehr Marketing Erfahrung diese Idee neu aufnimmt und zum Erfolg führt. Denn für mich stellt es immernoch ein großes Problem dar, herauszufinden was die Nutzer von meinen Projekten eigentlich erwarten. Ein Portal wie Fundry wäre aus meiner Sicht eine super Lösung gewesen um kundenorientiert freie Software entwicklen zu können.

Allen die die Hoffnung nicht aufgeben wollen sei der Fundry Blog empfohlen. Ich für meinen Teil werde demnächst FOSSFactory evaluieren.

Ansonsten R.I.P. Fundry

CC – Singleton korrekt implementieren


Flattr this

Motivation

Seit ich Clean Code [martin2009cleancode] lese, wollte ich das Gelesene auch gleich in meinem Blog posten um mir jenes erworbene Wissen für die Zukunft zu sichern. Leider geht das nicht so einfach, da diverse Punkte durchaus kontrovers diskutiert werden und sich stets auch Alternativen finden, welche nicht unbedingt schlechter sind. Zur Bewertung der Lösungen müssen erst eigene Erfahrungen gesammelt werden. Es genügt nicht zu sagen, es hies immer das wäre eine schlechte Lösung darum habe ich diese nie verwendet. Man muss auch verstehen warum die Lösung schlecht ist. Dazu muss man entweder ein paar Argumente kennen oder Erfahrungen mit der Lösung gesammelt haben oder aber vollständig die Vor- und Nachteile sowie die eigentlichen Ziele im konkreten Fall erfasst haben.

Es gibt Leute die lesen solche Bücher in ein paar Tagen und berufen dann Meetings ein um den Rest der Welt mit dem zu missionieren was sie selbst von dem Buch erfasst haben. In der Regel haben sie einige Dinge falsch verstanden und argumentieren dann vehement gegen die Anderen.

Diesen Fehler wollte ich nicht machen. Deshalb möchte ich auch ausdrücklich darauf hinweisen, dass die Artikel nur gesammeltes Wissen und Erfahrung sind. Keine Garantie, dass die Aussagen stimmen. Letztlich muss jeder selbst darüber nachdenken. In meinen Artikeln kann ich nur Hilfen und Argumente zur Verfügung stellen. Ich kann auch Empfehlungen aussprechen aber entscheiden muss letzlich jeder für sich allein.

Aus diesem Grund halte ich es für das Beste, einzelne Teilprobleme heraus zu greifen und diese von allen Seiten zu beleuchten. Vor- und Nachteile zu diskutieren und dem Leser damit eine Entscheidungshilfe an die Hand zu geben. Entscheiden muss er letztlich immer selbst am realen Kode.

Damit startet die Serie zur Clean Code Programmierung. Für den Leser stets erkennbar am dem CC – vor dem eigentlichen Titel.

Ziel des Singleton Pattern

Manchmal ist es wünschenswert, dass nur exakt eine Instanz von einer Klasse global existiert. Damit kann sich der Programmierer dann darauf verlassen, dass immer wenn Logik dieser Klasse ausgeführt wird, geschieht dies in dieser Einen Instanz. Soweit der Wunsch. In Wirklichkeit greifen im Java Umfeld noch einige Nebenbedingungen auf die wie nebenbei zu sprechen kommen. Diese Aufgabenstellung besitzt eine Lösung, das Singleton Pattern. Beschrieben ist dieses unter anderem in [Gam1994].

Wann ist das Pattern anzuwenden?

In [Gam1994] werden dazu 2 Gründe aufgeführt. Wende das Pattern an wenn:

  1. Du eine Klasse hast von der nur exakt eine Instanz existieren darf und diese soll von Clients zugreifbar sein über einen gut bekannten Zugriffspunkt.
  2. Wenn die Einzige Instanz durch Subklassen erweitert werden soll und ein Client soll in der Lage sein Instanzen von Subklassen zu nutzen ohne ihren Kode zu modifizieren.

Damit beginnt die erste Diskussion! In Java EE Umgebungen wird die Erzeugung von Objekten (Instanzen) dem Container übertragen. Er allein darf darüber entscheiden ob eine, zwei, oder mehr Instanzen einer Klasse zeitgleich existieren sollen. Die Verwendung von Singleton greift damit in die Freiheit des Containers ein. In konkreten Fällen kann damit eine Änderung der Implementierung der Containerlogik behindert werden. Der Architektur wird damit Flexibilität genommen. Der Architekt hatte möglicherweise bereits geplant zunächst einen Pico Container einzusetzen und in der zweiten Phase einen Spring Container. Er rechnet in der Regel nicht mit Entwicklern die ihm hier Steine in den Weg legen indem sie unkontrolliert in die Containerlogik eingreifen.

Sei es drum – wir haben mit unserem Architekten gesprochen und er sieht ein, dass es sein muss. Natürlich mit der Auflage das Pattern so wenig wie möglich zu nutzen. Wann nutzen wir es dann? Wenn die 1. Bedingung erfüllt ist? Wenn die 2. Bedingung erfüllt ist oder nur wenn beide Bedingungen erfüllt sind?

Aus meiner Sicht gibt es keinen Grund in einer Java EE Umgebungen ein Singleton zu verwenden, es sei denn man schreibt ein Framework und keine Anwendung. Aber diese Aussage möchte ich nicht als Lösung stehen lassen, da mir nicht klar ist ob meine Auffasung hier richtig ist. Letztlich läuft es wohl auf Einzelfallentscheidungen heraus.

Singleton – erster Versuch

package de.theserverside.designpatterns.singleton;

/**
* Klassische Implementierung des Singleton-Patterns
*/
public class ClassicSingleton {
private static ClassicSingleton instance = null;

/**
* Default-Konstruktor, der nicht außerhalb dieser Klasse
* aufgerufen werden kann
*/
private ClassicSingleton() {}

/**
* Statische Methode, liefert die einzige Instanz dieser
* Klasse zurück
*/
public static ClassicSingleton getInstance() {
if (instance == null) {
instance = new ClassicSingleton();
}
return instance;
}
}

Quelle: [Singleton]

Prinzipiell wird hier auf lange Sicht immer eine Instanz zurückgegben. Jedoch in der Anfangsphase kann es in Multithread Umgebungen zu Problemen kommen. Wenn der erste Thread in die getInstance() Methode eintritt und die if Anweisung mit dem Vergleich auf null noch passiert, dann jedoch vom System (Container, JVM, OS, …) schlafen gelegt wird. Während Thread 1 träumt, tritt ein zweiter Thread in die getInstance() Methode ein und passiert die if Abfrage welche immernoch true ergibt, erzeugt ein neues Objekt und bevor er dieses der Klassenvariablen zuweisen kann wird auch er ins Koma versetzt. Das Gleiche können jetzt noch hunderte von Threads genauso machen. Irgendwann wacht einer (evtl. der erste Thread) wieder auf und nimmt die Zuweisung auf die Klassenvariable vor. Ab da liefert die if Bedingung false. Jetzt wachen noch die anderen schlafenden Threads auf und nehmen ihrerseits die Zuweisung auf die Klassenvariablen vor. Je nachdem zu welchem Zeitpunkt dann die getInstance() Methode aufgerufen wird liefert sie ein anderes Objekt zurück. Erst ab dem Zeitpunkt ab dem sich kein Thread mehr innerhalb des Bodies der If Anweisung befindet, erst ab da wird stets die selbe Instanz zurückgegeben. Diese Implementierung führt also nicht zum Ziel.

 

Quellennachweis

[martin2009cleancode]
Martin, Robert C.: Clean code: a handbook of agile software craftsmanship. 1. Upper Saddle River, N.J. : Prentice Hall International, 2009. – ISBN 0-13-235088-2
[Gam1994]
Gamma, et al: Design Patterns: Elements of Reusable Object-Oriented Software : Addison Wesley Professional, 1994
[Singleton]
The Server Side Web Site Discussion

Entwickler sein, heißt besser werden!


Flattr this

Historie – was bleibt nennt sich Erfahrung

Wie am Blog vermutlich schon zu erkennen, bin ich Softwareentwickler 🙂 1999 schloss ich mein Studium in Richtung Informatik ab und stieg in die Entwicklung von Client-Server Anwendungen ein. Eingesetzte Technologien waren Oracle, Powerbuilder und Java. Der Softwareentwicklungsprozess in den Firmen orientierte stets am V-Modell. Dieses war in der Praxis deutlich umfangreicher als die wenigen Aspekte die wir im Studium betrachtet hatten.

In den Jahren nach 2000 waren dann Audits total angesagt. Jede Firma wollte ihre Zertifizierung nach ISO-9001. Die Firma brauchte plötzlich Geschäftsziele und jeder Mitarbeiter musste diese kennen. Hinzu kam eine nach bestimmten Kriterien angelegte Dokumentation und die Verwaltung von Quellkode in Versionskontrollsystemen. Letzteres war für mich nie ein Thema, da es im Open Source Bereich eine bewährte Praxis darstellt. Die normale Projektdokumentation die so anfiel empfand ich ebenfalls als sehr nützlich. Ich legte mir stets zu jedem Projekt eine Klemmmappe an. Da ich häufig auch zeitgleich an mehreren Projekten arbeitete, benötigte ich noch einen Plasteordner mit Register. Dieser enhielt stets die aktuellen Dokumente (in Arbeit befindlichen) je Projekt.

Gegen 2004 hatten es dann endlich die Beraterfirmen geschafft die kleinen und mittleren Unternehmen vollständig in Beschlag zu nehmen. Jede der mittelständischen Firmen die ich kannte, began damals mit Dingen wie den Folgenden.

Direktversicherungen – Die Firma schloss plötzlich Direktversicherungsverträge ab und machte diese Ihren Mitarbeitern schmackhaft. Die Nachteile waren klar: 5 Jahre Arbeitgeberbindung, da sonst die erworbenen Anrechte verloren gingen. Außerdem im Falle der Insolvenz gehört die Versicherung der Firma und geht in die Konkursmasse ein (jedenfalls im gesetzlichen Normalfall ohne abweichende Regelungen). Beim Arbeitgeberwechsel wird es schwierig, da der nächste Arbeitgeber vermutlich eine andere Direktversicherung besitzt und die des Arbeitnehmers nicht übernimmt. Ergo bis zur Rente zig verschiedene Versicherungen und in keiner lange genug eingezahlt um genügend heraus zu bekommen.

Risikomanagement – Als es in der Branche kränkelte und alle Firmen merkten, dass es kaum noch Geld für neue Projekte gab wurde Risikomanagement interessant. Wieder kamen Berater und wieder gab es Schulungen. In diesen wurden dann für teures Geld Binsenweisheiten vermittelt wie: „Der Vorstand darf nicht zusammen in den Urlaub fahren und wenn dann nicht mit dem gleichen Flug“, „Jedes Risiko ist auch immer eine Chance“, … Das ganze war gut ausgearbeitet, auf viele Module verteilt, ein schöne Geldmaschine für die Beraterfirmen. Welches Management achtet jetzt noch auf all diese dort gelernten Weisheiten?

Festpreisprojekte – Weil es kaum noch Geld gab aber die Unternehmen weiter Aufträge brauchten wurden nur noch Festpreisprojekte abgeschlossen. Gut für die Kunden – schlecht für die IT-Firmen? Nein, auch schlecht für den Kunden! Denn wie lief so ein Festpreisprojekt ab? Der Chef kam vom Kunden, im Gepäck viele lose Vorstellungen von dem was er dem Kunden demnächst gern anbieten möchte und mit einer Priorisierung wie es der Kunde gern hätte. Jetzt brauchte er noch ein bis zwei Tage um seine eigenen Prioritäten zu vergeben (Man hätte von einem priorisierten Backlog reden können – wenn das damals INN gewesen wäre). Im wöchentlichen Meeting wurde dann das Gesamtpaket den Entwicklern erklärt. Was will der Kunde haben, was braucht er dringend und wie können wir das leisten. In den Tagen danach wurden die einzelnen Projekte (aus dem Backlog) den jeweiligen Entwickler näher gebracht. Hierbei wurde der Leistungsumfang, die Zeitschiene und die grobe technologische Umsetzung besprochen. Kurz vor Beginn des Projektes vereinbarte der Entwickler einen Termin beim Kunden, sprach die Anforderungen durch, gab keine Zusicherung die der Chef nicht wollte und achtete auf die Umsetzbarkeit sowie auf den vom Chef abgesteckten Rahmen. Dann ging es zurück an den Schreibtisch und ans grobe Design. Wieviel Fenster werde ich brauchen? Wieviele DB Schemata sind betroffen? Arbeite ich auf Tabellen oder auf Views. Wie sollen die Masken im groben aussehen? Wie läuft das Deployment ab? Wo kann ich entwickeln – in der eigenen Firma oder beim Kunden? Wieviel Zeit werde ich brauchen? Wie stehen die anderen Projekte aktuell – gibt es Verzögerungen die ich noch ausgleichen muss? Das ganze dem Chef kurz vorgestellt, der Knackpunkt war immer der Zeitplan – hier war stets das Scotty-Prinzip gefragt. Chef ich kann das in 2 Monaten abliefern, vom Zeitplan her ist das für den Kunden auch ok. In den 2 Monaten kosten sie mir Gehaltsmäßig mehr als der Kunde für das Projekt ingesamt bezahlt. Ok, Chef ich versuch es in einem Monat zu schaffen.
Die Projekte wurden dann zum Termin (einen Monat) fertig oder umschreiben wir es lieber wie folgt. Es wurde so programmiert, dass man sich bei der Abnahme darauf zurückziehen konnte, dass alle geforderten Anforderungen soweit erfüllt sind. Hier und da sind halt noch ein paar Nacharbeiten zu tun. Diese Nacharbeiten und die unfertigen Teile welche erst bei tieferen Tests auffallen wurden dann noch in einem 2. Monat nachgearbeitet. Die Stimmung des Chefs war dann immer davon abhängig ob es bezahlte Nacharbeiten waren und falls nicht ob wenigstens ein Folgeprojekt dabei herausgesprungen ist. Die Krönung wäre ein echtes Projekt gewesen aber zu der Zeit gab es alles nur zum Festpreis 😉

Gegen 2006 war auch die Krise in der Branche langsam wieder überwunden und schon lag der Fokus auf ganz anderen Punkten. Viele Berater erkannten ihre Chance und gingen mal richtig ins Gericht mit den vergangenen Jahren. Was dabei herauskam nannte sich Kundenorientierung.

Kundenorientierung – Ja man redete uns ein, die Entwickler wären nicht Kundenorientiert genug und das müsse sich jetzt ändern. Dann kamen viele Schulungen mit vielen Powerpoints und schicken Bulletpoints. Bei den Entwicklern wurden zwar offene Türen eingerannt, denn sie wollten schon immer möglichst alles so umsetzen wie es der Kunde wollte. Leider gab es dabei einige Hemmnisse wie Zeit, Budget und Chefs die diese Spielereien jetzt gar nicht für sinnvoll hielten oder der Meinung waren, dass man dem Kunden nicht alles liefern darf sondern auch beratend/erzieherisch als Entwickler tätig sein muss. Letzterem stimme ich sogar zu, unter der Prämisse, dass die Benutzbarkeit der Anwendung nicht darunter leidet. Doch diese Hemmnisse erschienen nicht in den gelobten Powerpoints. Hier waren es immer die Entwickler die in an den Haaren herbeigezogenen Beispielen gegen die Kundenorientierung arbeiteten. Das ging eine Weile so – dann war wieder Ruhe. Kein Wort mehr von Kundenorientierung. Ja, genau! Es gab etwas Neues 🙂

Serviceorientierung – Jetzt war es endlich soweit. Das Management zog die Schlussfolgerung, dass die Bedürfnisse des Kunden wohl am besten durch einen besseren Service zu erfüllen seien. Nun wurde es unfreiwillig komisch. Offensichtlich war es das erste Mal passiert, dass die Beraterfirmen zugleich auf verschiedene Strategien gesetzt hatten (Sonst schienen sich die Berater weltweit immer einig gewesen zu sein :-). Serviceorientierung wurde einerseits hinsichtlich der Kundenorientierung gesehen und ging in Richtung Einführung von ITIL oder CMMI. Andererseits ging es um die Umgestaltung der Unternehmen hinsichtlich der angebotenen Services und deren Schnitt, also Richtung SOA. Das Thema war also kurze Zeit brandaktuell. Es gab richtig gute Schulungen dazu. Darin gab es richtig interessante Aussagen (aus dem Gedächnis rekonstruiert): „Ein ESB ist nebensächlich, Tools überhaupt sind nachrangig zu werten, SOA lässt sich auch ohne Tools durchführen“, „SOA ist nicht nur eine Technologie, SOA ist vielmehr eine Art und Weise ein Unternehmen zu organisieren“, „Wir wollen unsere Prozesse standardisieren um uns mit Konkurrenten vergleichen zu können“. Das Thema stand nur kurze Zeit im Fokus, verblieb aber im Hintergrund ehe es später als SOA wieder auftauchte.

Prozessorientierung – Endlich war dem Management klar, was diese Softwareentwicklung so teuer machte. Da war Kollege A mit seinem fachlichen und technischen Wissen sowie seiner spezifischen Erfahrung, welche er durch seinen spezifischen Lebensweg erworben hatte. Und da war Kollege B mit einem anderen fachlichen und technischen Wissen und einer anderen spezifischen Erfahrung. B war Vertretung von A und wenn A fehlte blieben dennoch Dinge unbearbeitet und wenn B fehlte war es genauso mit A. Woran lag das? Natürlich das Unternehmen brauchte Prozesse – Arbeitsprozesse! Was heisst die haben wir und die laufen auch, das kann ja gar nicht sein. Wo ist der Single Point of Service? Wo sind die allseits beliebten Workflow-Engines? Was heißt die gibt es nicht? Wieso haben wir eigentlich noch nicht auf ITIL oder CMMI umgestellt und unsere Prozesse standardisiert? Dann wären die Entwickler austauschbar und ein Kunde könnte von jedem zur vollsten Zufriedenheit bedient werden. Außerdem erfordern standardisierte Prozesse auch nicht den Einsatz hochqualifizierter Fachkräfte – zumindest nicht an jeder Stelle.
Das Ergebnis waren standardisierte Prozesse und die Aussage: „ITIL hat nicht versprochen die Prozesse zu beschleunigen sondern sie zu standardisieren. Das kann in speziellen Fällen auch bedeuten, dass es auch mal langsamer werden kann“. Nur gut, das dieses Vorgehen nicht mehr unter dem Begriff Kundenorientierung läuft. Aber gut, es waren ja ohnehin die Entwickler welche die Kundenorientierung nicht verstanden haben. Wenn ich als Entwickler früher einen Fehler gemeldet bekam, habe ich mich gleich daran gesetzt ihn zu analysieren um eine Aussage zu treffen woran es liegt, wie ein Workaround dazu aussieht und bis wann ich es beheben kann. Nach der ITIL Einführung schaue ich mir den Incident an, identifiziere die fehlenden Informationen, fordere diese durch Rückgabe des Tickets vom Ersteller ein und wende mich ohne schlechtes Gewissen der Bearbeitung des nächsten Tickets zu. Früher hätte sich mir dabei der Magen umgedreht. Doch wie heisst es so schön „Der Mensch ist ein Gewohnheitstier“ und „Der Mensch wird geprägt durch seine Umgebung“. Insofern ist ITIL schon etwas prägend. By the way – ITIL ist für den Betrieb erfunden wurden liebes Management – naja egal.

SOA – Endlich mal was für Entwickler. Die wollen doch ohnehin immer diese Spielereien, jetzt können sie mal Webservices bauen, das wird sie motivieren. Nachdem das Thema lange in den Hintergrund getreten war taucht es nun wieder auf. Jetzt werden die Services implementiert. Wie kam es dazu? Na zunächst sind offensichtlich umfangreiche Analysen gelaufen welchen ESB von welchem Anbieter man nehmen könne. Brauchen wir den? Wenn wir die Prozesse nach Belieben verschalten wollen ja. Wollen wir das? Nein! Achso.
Also SOA ist schon notwendig, auch aus meiner Sicht. Mit ihr bekommen wir die Chance festzulegen welche Kollegen/Abteilung/Projekte/Verfahren als Master für welche Daten fungieren. Dann ist endlich auch klar wer nur liest und wer nur schreibt genauso wie wer welche Daten zu halten hat und wer welche Daten weiter zu leiten hat. Doch die ersten Dinge haben wir uns schon verbaut. Wir haben uns auf den ESB Hersteller festgelegt und wir sprechen nur noch von Webservices obgleich eine SOA auch RMI als Service sieht. So gibt es bei den ersten Planungen Probleme mit der Performance (schon auf dem Papier). Um diese zu lösen schicken Imperator-Entscheidungen dann Workarounds ins Rennen auf die wir langfristig lieber verzichtet hätten.

Scrum – Dieser Punkt war die eigentliche Motivation für den vorliegenden Artikel und er wird jetzt nur noch kurz angerissen. Aber gut ich kann ja noch ein paar Artikel dazu schreiben 😉
Ja seit kurzem bin ich in einer Firma in der agile Arbeitsweisen vom Management eingeführt wurden. Die Entwickler sollen Spass bei der Arbeit haben, man wolle die Motivation steigern und man will effektiver und effizienter werden. In meinen Worten: Man möchte, dass sich die Entwickler mit den Arbeiten befassen die für die Erfüllung der Kundenwünsche notwendig sind und mit keinen anderen Dingen. Weiterhin will man, dass sie diese Arbeiten mit möglichst geringen Aufwänden und in hoher Qualität durchführen. Nachdem die agilen Arbeitsweisen bereits seit 10 Jahren ein Schattendasein fristeten und der Hype in Deutschland nun auch groß genug war, hat er also auch meinen Arbeitgeber erreicht. Nein ich stehe dem Ganzen nicht ablehnend gegenüber – im Gegenteil. Ich war und bin stets offen für neue Ideen. Allerdings übe ich mich anfangs immer in Zurückhaltung von Euphorie, da ich schon zu viele Allheilmittel nach einer Weile verpuffen sehen habe. Was für mich dabei besonders unbefriedigend ist, meist hinterlässt die Nachbetrachtung eines Beraters über ein am Boden liegendes Allheilmittel den Nachgeschmack – der Entwickler war Schuld, er hat’s versaut. Immer so auf der Art: „Das hätte super geklappt, wenn da nicht die Menschen wären …“. Zudem wie wir Scrum leben, welche Probleme und Nichtprobleme wir damit haben, will ich heute nichts sagen. In späteren Artikeln werde ich mich dazu gewiss äußern. Nur soviel: Ich bin dabei, ich bin am lernen und ja auch für mich gestaltet sich der Einstieg nicht einfach. Ähnliche Eindrücke scheinen andere Entwickler auch gemacht zu haben. Ich bin gespannt wohin mich die Reise führt.

 

Die Lehren, die ich zog

Nachdem ich nun im super Kurzdurchlauf meine berufliche Laufbahn auf die durchlebten Höhepunkte der Arbeitsmethoden oder Managementstrategien reduziert habe, möchte ich zusammenfassend sagen was ich daraus gelernt habe.

Persönliche Arbeitsweise – Diese vielen verschiedenen Kursänderungen im Management haben zu vielen Weiterbildungen teils in Form von Schulungen, teils in Form von Mitarbeitergesprächen geführt. Mit jedem Kurswechsel musste ich mich beschäftigen ob ich wollte oder nicht. Aus jeder gerade aktuellen Strategie habe ich versucht meine Vorteile zu ziehen. Meist gab es irgendwelche Arbeitsweisen die vorgestellt wurden oder Beispiele zu Arbeitsweisen aus denen man etwas für sich herausziehen konnte. Häufig wurden auch bekannte Arbeitsweisen zum x.ten Mal erläutert. Letzteres ist aber auch nicht schlecht. Schließlich dringt es so schneller ins Langzeitgedächtnis ein und außerdem sieht man, dass die Meinung immer noch aktuell ist – man ist also auf der sicheren Seite wenn man die Arbeitsweise beherzigt. So habe ich letztlich meine persönliche Arbeitsweise stets verbessern können. Zusätzlich zu den betrieblichen Denkansätzen kamen dann noch die Methoden „Simplify your life“ und „Getting things done“ aus denen ich viele Methoden in meine persönliche Arbeitsweise übernehmen konnte. Man muss aber auch sagen, dass erfahrungsgemäß keine Methode vollständig anwendbar ist. Meist mussten Teile weggelassen oder an das bestehende Umfeld angepasst werden. Auch für zukünftige Methoden wäre meine Erwartungshaltung nicht, dass ich diese ohne Tailoring übernehmen kann – das wäre Illusion. Gerade die agilen Methoden bringen eine große Menge an neuen Ansätzen mit. Hier kann ein großer Fundus für das private Leben abgeschöpft werden, egal ob die Projekte zum Schluß laufen oder nicht. Was allen Methoden bislang gemeinsam ist. Das Thema Ablage wird oft als Randthema gestriffen aber nicht wirklich herzhaft erfasst. Ablagesysteme spielen aber bei der Selbstorganisation aus meiner Sicht eine zentrale Rolle. Meist werden vorhandene Krücken aus dem Betrieb genutzt (in der Regel unlogisch gegliederte Dateisysteme mit magischer Berechtigungsverteilung). Das beste Ablagesystem welches ich bislang kennengelernt habe, ist dies aus „Simplify your life“ – eine Karteikartenablage im Rollcontainer. Bislang das praktischte System für mich. Leider ist meine Arbeitsumgebung inzwischen soweit standardisiert, dass auch die Rollcontainer standardisiert sind. Ein Fach mit Karteikarten gehört leider nicht zur Ausstattung und lässt sich auch nicht bestellen. Auch selber kaufen stellt keine Lösung dar, da es damit wieder andere Probleme gibt.

Die Kuh die durchs Dorf getrieben wird – Ja inzwischen bin ich der Meinung, dass Softwareentwicklung teilweise mit Mode vergleichbar ist. Manche Klamotte ist nach 10 Jahren durchaus wieder modern, obgleich dann natürlich unter einem anderen Namen. So ist es auch in der Softwareentwicklung, wobei hier die Periode von 10 auf etwa 1 Jahr zu reduzieren ist. Seit der Softwarekrise sind die grundlegenden Probleme der Softwareentwicklung bekannt (Beweisbarkeit der Terminiertheit und Korrektheit von Programmen sowie die Zusicherung von deterministischem Verhalten). Grundlegende Lösungsansätze sind auch klar. Beweisen lässt sich alles, es ist nur eine Frage des Aufwandes. Wenn ich also zu jeder Zeile Quellkode noch 3 Zeilen logischer Ausdrücke hinzupacke und bestimmte Rahmenbedingungen herstelle würde sich evtl. sogar die Terminiertheit beweisen lassen (Endlosschleife oder dauert es nur länger). Die Kunst besteht also darin bestimmte Effekte mit möglichst geringen Aufwand zu erzielen. Dazu gibt es klassische Methoden. Dann gibt es Varianten dieser klassischen Methoden. Dann gibt es Kombinationen der Vorgenannten. Zu guter Letzt entsteht jedes Jahr eine Neue, mit neuem Namen mit neuen Hoffnungen, mit neuen Versprechungen und am Ende meist mit der gleichen Enttäuschung wie bei der Letzten. Nein das ist keine pessimistische Einstellung sondern ein Naturgesetz. Entweder ich habe komplexe Programme oder ich habe komplexe Spezifikationen oder ich habe beides. Wenn ich die Korrektheit ein komplexes Programmes sicherstellen will, benötige ich komplexe Beschreibungen des Programmverhaltens. Wenn ich die Korrektheit beweisen will würde die Spezifikation der Neuprogrammierung einer Anwendung auf anderem abstrakten Niveau und mit anderen Mitteln gleichkommen. Der Aufwand muss aber der Gleiche sein, da es um das gleiche Verhalten geht. Von daher könnten diversifizierende Testverfahren tatsächlich eine preisgünstigste Methode in der Softwareentwicklung darstellen. Lass einfach 2 agile Teams unabhängig und räumlich getrennt von einander das gleiche Programm bauen und vergleiche die Ausgaben beider Programme. Unterschiedliche Ausgaben deuten auf unklare Anforderungen und fehlerhafte Umsetzung.
Was ich sagen will ist, ich habe mich daran gewöhnt das wir in unserer Branche den neuen Technologien, neuen Produktversionen und neuen Trends nur so nach hecheln. Ich kann damit leben und teilweise damit umgehen. Was ich daran nicht mag ist, dass die Evangelisten der neuen Technologie immer so tun als seien alle Anderen die ewig Gestrigen, die Dummen, die die keine Ahnung haben und sich sperren oder das ganze neue Projekt unterwandern und boykottieren wollen.

Die Erfahrung die ich hieraus gezogen habe ist ganz einfach: Spring auf jedes neue Thema auf wenn man es von Dir erwartet. Knie Dich rein, interessier Dich dafür. Eigne Dir an was sinnvoll ist und über nimm es in Deinen persönlichen Arbeitsstil. Überdenke Deine bisherige Arbeitsweisen kritisch, hinterfrage das Neue Thema kritisch aber stoppe keine Deiner langfristigen Aktivitäten um dem Neuen Thema Priorität einzuräumen.

Gute Arbeit leisten – Auf dem letzten Treffen der Nürnberger Agilisten hat es mich wirklich entsetzt wieviele Menschen der Meinung sind, dass viele Entwickler nur Ihren Job machen wollen, kein Interesse an einer persönlichen Weiterentwicklung haben und Änderungen in der Firma eher unflexibel gegenüber stehen. Vielleicht war das auch die unterbewusste Motivation den Artikel zu schreiben. Jedenfalls bin ich anderer Meinung. Ich glaube das alle Entwickler gute Arbeit leisten wollen. Ich glaube aber auch, dass jeder Mensch andere Fähigkeiten und Bedürfnisse hat und so auch jeder Entwickler. Diese müssen im Arbeitsumfeld Berücksichtigung finden, sonst ist die Zusammenarbeit nicht fruchtbar. Viele Menschen sind sich ihrer Fähigkeiten und Bedürfnisse auch gar nicht sicher. Diese müssen dann zunächst identifiziert werden. Auch die Vorstellungen und Ansichten über Gut und Schlecht sind stark unterschiedlich. Meist hängen sie von der persönlichen Entwicklung, den persönlichen Erfahrungen und dem Umfeld oder anderen Dingen ab.

Beispielsweise die Vorstellung über guten Kode. Was ist guter Kode? Wie sieht ein guter Kommentar aus? Da gibt es Entwickler die 10 Finger blind schreiben können und für die beliebig lange Bezeichner und Texte kein Problem darstellen. Auf der anderen Seite die – ich nenne sie gern C Programmierer – welche alles möglichst auf einen Buchstaben reduzieren. Dann gibt es die Verfechter des Fluent-Interface. Doch was ist nun wirklich guter Kode? Der mit einem super ausführlichen JavaDoc Kommentar, möglichst noch mit HTML Tags um dem Leser gleich die Möglichkeit des Verzweigens zu geben oder der ohne JavaDoc bei dem sich aus der Verkettung der Aufrufe das Verhalten erschließt? Sowie sie hierzu zwei Antworten erhalten sollten sie davon ausgehen, dass auch die Antwort die nicht Ihrer Ansicht entspricht wohl durchaus begründet ist. An dieser Stelle würde ich mir viel mehr Erfahrungsaustausch unter den Entwicklern wünschen. Doch diesem muss vom Arbeitgeber auch Zeitbudget eingeräumt werden. Stammtische oder OpenSpace Veranstaltungen empfinde ich hierbei als äußerst geeignet. Doch wie läuft es in der Praxis? Zur Community of Praxis sprechen vor dem Team immer nur diese selbst ernannten Gurus und stellen sich hin und sagen wie was gemacht werden soll. Die Anderen, denen das Präsentieren nicht so liegt, werden sich hüten hier aktiv zu werden. Warum nicht einfach mal ein Kodestück aus der Versionskontrolle festlegen (z.B. Person.java Zeile 130 – 140 aus r205) und beim nächsten Treffen durchsprechen. Bis dahin kann sich jeder mit dem Kode befassen und Argumente dafür und dagegen sammeln. Das bringt aus meiner Sicht viel mehr als die monotonen Wiederholungen von „Mache dies so und mach das so“. Auch Katas halte ich für einen guten Weg seine Fertigkeiten zu festigen. In der Arbeitswelt aber nicht im Team als Dojo. Da kommt zu viel Konkurrenz ins Spiel. Dojos per Internet sind kein Problem im Gegenteil, diese können auch sehr fruchtbar sein.

Ein ähnliches Thema habe ich bereits in meinem Artikel Industrielle Softwareproduktion behandelt, dieser könnte sie auch interessieren 🙂

 

 


 

Da es vermutlich nicht schwer fällt, meinen aktuellen Arbeitgeber zu ermitteln, möchte ich vorsichtshalber folgendes Statement anbringen:

Die hier im Blog und speziell in diesem Artikel vorgenommenen Behauptungen, Argumentationen, Meinungen und ähnliches sind rein meine persönlichen. Sie sind weder mit meinem Arbeitgeber abgesprochen, noch von ihm bewertet noch stellen sie dessen Meinung, Behauptungen, etc. dar.

VII. Captain Casa Community Meeting


Flattr this

Motivation

Seit einiger Zeit beschäftige ich mich nebenher mit der Evalutation verschiedener UI-Frameworks. Begonnen hatte ich dies mit der ersten Version von Thinlet. Bin dann auf GUI4J gekommen. Anschließend fand ich Canoo, evaluierte noch JavaFX und letztlich auch den Captain Casa Enterprise Client . Das Captain Casa Framework hat mir von den vorgenannten am Besten gefallen. So hatte ich mir dann auch gleich fest vorgenommen am Community Meeting teilzunehmen. Die dort gesammelten Eindrücke möchte ich in diesem Artikel vorstellen.

Organisation

Das VII. Captain Casa Community Meeting fand am 18.11.2011 in Eppelheim in der Wasserturmstraße 50 in den Räumen der KonSer Systems OHG statt. Organisiert wurde das Meeting vom Captain Casa Gründer Björn Müller über die RIA Gruppe der Internetplatform Xing. Das Treffen findet jährlich statt und wendet sich an Nutzer des Captain Casa Frameworks wie auch an Interessierte. Für alle Frühankommer war gegen 20:00 Uhr ein Treffen am Vortag in Heidelberg in der Lobby des Hotels „Holländer Hof“ organisiert. Anschließend Einkehr in eine Gasstätte und einen Spaziergang durch Heidelberg. Direkt am Veranstaltungstag war der Veranstaltungsraum extra für Frühaufsteher bereits ab 09:30 Uhr geöffnet und mit Kafffee und Brezeln bestückt.

Teilnehmer

Zum Community Meeting kamen vorwiegend proffessionelle Nutzer des Captain Casa Frameworks. Mein Eindruck war, dass es sich dabei sowohl um mittlere wie auch große Firmen handelt. Auch eine staatliche Einrichtung war mit einem aus meiner Sicht sehr großen Projekt vertreten.

Stimmung

Es war eine sehr harmonische Stimmung unter den Teilnehmern. Viele kannten sich bereits durch vorangegangene Treffen und tauschten rege Ihre Erfahrungen über das Framework aus. Alle äußerten sich positiv zum Einsatz des Frameworks und lobten den hervorragenden Support der Captain Casa GmbH.

Inhalt der Veranstaltung

Generell lässt sich der Inhalt in folgende Bereiche einordnen:

  • Erfahrungsberichte von Unternehmen bzw. Captain Casa Nutzern.
  • Vorstellung technologischer Neuerungen durch die Captain Casa GmbH.
  • Vorstellung aktueller Entwicklungen auf dem GUI Markt speziell im Bereich RIA und Mobile.

Für das Meeting war eine strikte Agenda von Herrn Müller entworfen wurden. Diese wurde auch Punkt genau begonnen, jedoch brachten die Vorträge einige Verzögerung in den Ablauf, so dass später einige Vorträge gekürzt und die Agenda dynamisch angepasst wurde. Alle Anpassungen erfolgten jedoch stets unter dem Gesichtspunkt „Was interessiert die Community“. Daher wurde stets auch die Community gefragt wie mit den einzelnen Punkten verfahren werden soll.

 

Einige Teilnehmer hatten Screenshots ihrer Anwendungen zu einem Wettbewerb eingereicht. Auf dieser Grundlage begann die Veranstaltung mit der Vorstellung der Teilnehmer. Jene, welche sich nicht am Wettbewerb beteiligt hatten, wurden mit ein paar persönlichen Worten ebenfalls vorgestellt. Damit waren die Teilnehmer alle untereinander bekannt, was für den Erfahrungsaustausch von großem Wert war.

Anschließend wurden die aktuellen Entwicklungen im RIA Umfeld vorgestellt und bewertet. Hierbei hat die Captain Casa GmbH klar ein Signal gesetzt zukünftig auch Androids zu unterstützen. Eine offizielle Erstversion soll es Anfang des 2. Quartals 2012 geben. Aktuell erarbeitet Captain Casa in einem Projekt mit einer Zeiterfassungsfirma die entsprechenden Bibliotheken. Die bereits existierende, interne Version der Anbindung wurde später in einem kurzen Tutorial zur Android Programmierung vorgestellt. In diesem Tutorial wurde zunächst gezeigt, wie mit den von Google vorgesehenen Werkzeugen eine Android Anwendung erstellt werden kann. Anschließend wurde gezeigt wie das Gleiche mit dem Captain Casa Enterprise Client funktioniert. Im Prinzip kein großer Unterschied, nur dass der Client dann sowohl auf mobilen Geräten wie auch auf Desktop PCs nahezu identisch läuft 🙂 Das Wort identisch wollte Herr Müller an dieser Stelle eigentlich nicht recht verwenden. Jedoch mangels Verfügbarkeit eines treffenderen Begriffes betonte er dann: Indentisch unter Berücksichtigung der Umgebungsbesonderheiten! Damit gemeint sind Besonderheiten wie Wischtechnik, Ortssensor etc.

Nachdem die aktuellen Entwicklungen am Markt betrachtet waren ging es zum nächsten Thema – Vorstellung der neuen Features. Es war eine enorme Menge von der ich hier nur besonders interessante erwähnen möchte:

  • Ein OpenStreetMap Control für die Einbettung freier Landkarten
  • Ein ScreenGraber Control zur Erstellung parametrisierbarer Screenshots
  • Ein Pivot Control welches auf der Grundlage von Apache POI ein vollständiges Excel anbietet
  • Ein TiledArea welches von Aussehen und Funktion an die Portlets von SUN erinnert

Bei CaptainCasa muss über Dinge wie Browserunabhängigkeit, identische Darstellung auf unterschiedlichen Systemen, einen möglichst kleinen UI Stack der Anwendung und über kleine Roundtrips zum Server durch Deltalieferungen kaum noch gesprochen werden, weil diese vom Framework sichergestellt sind. Aus diesem Grund möchte ich hier erwähnen, dass die Firma auch immer bestrebt ist, das Rad nicht neu zu erfinden sondern auf bestehende und erprobte Standards wie beispielsweise JSF setzt.

 

Präsentation von Kundenanwendungen

Es folgten nun diverse Präsentationen von Kundenlösungen. Hierbei stellten die einzelnen Firmen kurz das Projekt und die grundlegenden Anforderungen vor. Anschließend gab es dann einen Schnelldurchlauf durch die mit Demodaten gefüllte Anwendung. Hierbei wurden hier und da natürlich besondere Schmankl hervorgehoben.

Zwei Dinge haben mich persönlich am meisten begeistert. Zum Einen wurde ein Verwaltungssystem vorgestellt, bei dem eine Mail aus Outlook über Drag&Drop in das System fallen gelassen wurde und sofort als Dokument bzw. wenn mit Anhängen versehen sogar in Form mehrerer Dokumente im System verfügbar war. Zum Anderen haben viele Firmen das Casa Framework um eigene Controls erweitert. Diese ließen sich wie Casa eigene Contols in der gewohnten Entwicklungsumgebung verwenden. Ein solch nathlose Integration von Eigenentwicklungen habe ich selten in einem so mächtigen System gesehen. Ein Kunde wird seine Applikation sogar als SaaS anbieten. Damit kann Captain Casa dann auch zeigen wie sich das Framework innerhalb der Wolke verhält. Da aber viel auf Standards gesetzt wird sind hier eher positive Ergebnisse zu erwarten.

Die von den Kunden eingesetzten Technologie Stacks waren durchaus unterschiedlich, besaßen jedoch auch Gemeinsamkeiten. Eine häufige Kombination war Tomcat als Webcontainer für JSF und Hibernate zur Realisierung der Persistenz. Ab und an wurde noch ein EJB Container in Form von JBOSS seltener Classfish ergänzt. Bei den verwendeten Datenbanksystemen war es bunt gemischt. Vom Platzhirsch Oracle über MSSQL Server bis PostgreSQL war vieles vertreten.

Besonders schön empfand ich es, dass einige Präsentationen nicht nur die umgesetzten Features darstellten sondern auch auf Probleme eingingen. Dies führte zu einem besonders fruchtbaren Erfahrungsaustausch, da andere Kunden die gerade dabei waren ähnliche Wege zu beschreiten gleich prüfen konnten ob bei ihnen ein mögliches Risiko bestand. Vor allem aber konnten sie sich Tipps holen wie das Problem vermieden werden kann.

Captain Casa und Open Source

Die Captain Casa GmbH scheint generell eine Open Source freundliche Firma zu sein. Was jetzt nicht heißt, dass das Casa Framework Open Source Software sei. Nein – das nicht. Der Bezug des Quelltextes wird erst bei entsprechender, kostenpflichtiger Lizensierung möglich. Aber es sind Open Source Produkte wie Open Office und Thunderbird intern im Einsatz. Was in anderen Firmen ja teilweise undenkbar ist. Erkennbar war dies in den Vorbereitungspausen zu einzelnen Präsentationen.

Außerdem stellt Captain Casa eine freie Binary Lizenz für Entwickler bereit. Auf Wunsch kann diese auch in Form eines Dokumentes bereitgestellt werden. Diese Lizenz ist nicht exklusiv und ohne Garantien. Der Quellkode ist nicht dabei, das Logo darf nicht ausgeblendet werden aber die damit erstellten Programme dürfen mit den enthaltenen Casa Binaries verbunden an die Endnutzer weiter gegeben werden. Gerade dies ist aus meiner Sicht ein ganz wichtiger Punkt für die Entwicklung von Anwendungen im Open Source Bereich.

In der Lizenzpolitik unterscheidet sich Captain Casa damit entschieden von anderen Konkurrenzprodukten. Auf Grundlage meiner persönlichen Erfahrungen kann ich hier nur mit Canoo vergleichen. Letztlich war es die Lizenzpolitik von Canoo weshalb ich deren Framework nicht umfangreich evaluieren konnte und mich so gegen dessen Verwendung entscheiden musste. Auch einige Kunden von Captain Casa hatten zunächst Vaadin, JavaFX sowie Canoo evaluiert und sich schließlich für Captain Casa entschieden.

Schlußwort

Zusammenfassend habe ich den Eindruck erhalten, dass es sich beim Captain Casa Enterprise Client um ein sehr gutes, solides und fantastisches Framework handelt.

Hinweise und Kommentare zum Artikel sind wie immer ausdrücklich erwünscht.

Maven Download from SF.net


Flattr this

Motivation

Die OpenSource Entwickler welche ein Maven Plugin Projekt auf Sourceforge.net hosten und es ihren Nutzern maven like zum Download anbieten möchten, haben damit seit der Geburt von maven ein Problem. Sie müssen ihre Artifakte im File Release System (FRS) des Sourceforge Portals hosten. Ein Hosting im Bereich der Projekt Homepage auf Sourceforge ist nicht gestattet.

Hintergrund dieser Regelungen scheint die Lastverteilung beim Download zu sein. Das FRS von Sourceforge ist optimiert auf eine schnelle Verbreitung der Artifakte über diverse in der Welt verteilte Proxies. Bei der Web Area in welcher die Hompages der Projekte gehostet werden, scheinen andere Mechanismen im Einsatz zu sein als im FRS.

Aber auch der automatische Upload der Artifakte per Maven ist nicht trivial, da Sourceforge bestimmte Sicherheitsrichtlinien aufgesetzt hat, welche den Projekten eine entsprechende Sicherheit garantieren sollen.

Lösung für den Download

Nachdem ich eine Weile nach Lösungen gesucht hatte fand ich von Brian Matthews das Projekt wagon-sf auf sourceforge. Allerdings hatte Brian seinen Schwerpunkt wohl auf andere Projekte verlagert, denn es waren keine Artifakte zum Download verfügbar. Durch das Projekt auf die richtige Spur gebracht schrieb ich mir daraufhin einen eigenen Maven Wagon. Dieser ist als Unterprojekt wagon-http-sourceforge unter meiner Maven Plugin Sammlung zu finden.

Lösung für den Upload

Hierbei konnte ich auf Maven Boardmittel zurück greifen. Es ist lediglich die pom.xml um folgende, angepasste Einträge zu erweitern:

<distributionManagement>
<!– use the following if you’re not using a snapshot version. –>
<repository>
<id>sourceforge-sf-mvn-plugins</id>
<name>FRS Area</name>
<uniqueVersion>false</uniqueVersion>
<url>sftp://web.sourceforge.net/home/frs/project/s/sf/<your_project>/<your_folder></url>
</repository>
<site>
<id>sourceforge-sf-mvn-plugins</id>
<name>Web Area</name>
<url>
sftp://web.sourceforge.net/home/project-web/s/sf/sf-mvn-plugins/htdocs/${artifactId}
</url>
</site>
</distributionManagement>

<build>

<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh</artifactId>
<version>1.0-beta-6</version>
</extension>
</extensions>

</build>

Um die Zugangsdaten an den Upload Wagon zu übermitteln, kann man in der lokalen settings.xml folgende Einträge vornehmen (die settings.xml muss vor lesenden Zugriffen anderer Nutzer geschützt werden!):

<servers>
<server>
<id>sourceforge-sf-mvn-plugins</id>
<username>loginname,projectname</username>
<password>your-password</password>
</server>
</servers>

Die fett geschriebene ID ist natürlich beliebig wählbar, sie muss nur an allen Stellen gleich sein – sonst funktioniert es nicht. Das Komma zwischen dem LoginNamen und dem Projektnamen bei der Angabe des username ist ebenfalls wichtig.

Die Entwicklerfähigkeiten festigen


Flattr this

Motivation

Wenn sich Menschen in bestimmten Bereichen verbessern möchten, werden sie anfangen zu trainieren. Entwickler die sich verbessern möchten, trainieren mittels sogenannter Kata’s oder auch Code Kata’s. Hintergründe und wie alles begann lassen sich im Blog von Dave Thomas nachlesen ([DaveThomasBlog]). Ein paar einleitende Worte auf deutsch finden sich unter [CodeDojos].

Solche Übungen lassen sich allein durchführen. Allerdings so richtig Spaß macht die Sache erst wenn man die Lösungen mit anderen vergleichen kann. Eine schöne Art eines Vergleiches ist auch die Durchführung von Code Dojos. Eine Umgebung zur Aufzeichnung, Analyse und Kommentierung von Code Kata’s findet sich unter [CodersDojosBlog].

Eine generelle Anleitung zur Arbeit mit den Katas und dem Aufsetzen der Umgebung gibt folgender Screencast:
http://content.codersdojo.org/documentation/command-client-screencast/

Im vorliegenden Artikel werde ich kurz beschreiben wie das System unter Windows mit Eclipse zum Laufen gebracht wird.

Los geht’s

  1. Download des Ruby Installers in Version Ruby 1.9.3-p0 von http://rubyinstaller.org/downloads/ und Setup als Admin ausführen mit:
    • „Tcl/Tk support“ anwählen
    • „add to path“ anwählen
    • „check file assosiation“ anwählen
  2. Das Programm unter c:\Program Files\ruby193 installieren
  3. Consolen Fenster als Administrator öffnen (Admin Console) und in das Verzeichnis c:\Program Files\ruby193\bin wechseln
  4. Dort folgenden Befehl ausführen: gem install codersdojo
  5. Nun starten wir mit dem Befehl: codersdojo und prüfen ob der Hilfetext erscheint (das Programm sollte alleine ohne Fehler enden)
  6. Jetzt erstellen wir mit Eclipse ein Java Projekt, beispielsweise prime welches wir wie folgt konfigurieren:
    • SourceFolder: < Projektfolder>
    • OutputFolder: bin
  7. Nun wechseln wir in die Console (keine Admin Shell) und führen in unserem Projektverzeichnis folgenden Befehl aus:
    codersdojo setup java.junit Prime.java
  8. Ein Refresh in Eclipse zeigt uns welche Dateien alles hinzugekommen sind.
  9. In das lib Verzeichnis unseres Projektordners kopieren wur nun ein junit-4.x.x.jar (wichtig ist nur Version > 4 für Annotationen) und benennen es in junit.jar um!
  10. In Eclipse binden wir dieses junit.jar nun in den Projekt Classpath ein.
  11. In der Console können wir die Bearbeitung des Katas starten über Eingabe des Befehls: run-endless.cmd
  12. Wir bearbeiten nun das Kata solange in Eclipse bis es gelöst ist.
  13. Haben wir das Kata beendet und wollen die Aufzeichnung ebenfalls beenden, dann wechseln wir in die Console und geben Control-C ein.
  14. Anschließend bitte u eingeben um das Kata auf das Portal zu laden.
  15. Den auf der Console ausgegebenen URL bitte im Browser eingeben und die Meta Daten zum Kata ergänzen. Hierbei kann auch ausgewählt werden, ob das Kata öffentlich sichtbar ist oder nicht.

Das war schon alles. Jetzt noch ein paar nützliche Links.

Die Liste der öffentlich zugänglichen Katas auf CodersDojo:
http://codersdojo.org/katas/list

So lassen sich Katas auch alternativ aufzeichnen aber leider nicht kommentieren und vergleichen:
http://www.veengle.com/v/vGnl

Abschließend noch ein Katalog diverser Katas:
http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue

Leider kommen die Skripte von codersdojo nicht mit Unterverzeichnissen klar. Somit wird ein Maven typisches Layout nicht unterstützt. Wer das ändern will kann sich an den Sourcen probieren. Diese sind hier zu finden: http://t.co/xRL2tsY

Ansonsten viel Spass beim Üben 🙂

Quellennachweis

[DaveThomasBlog]
Hintergründe und Details vom Erfinder des Begriffes Code Kata (Autor des Pragmatic Programmer)
[CodeDojos ]
http://www.it-agile.de/code-kata-dojo.html
[DojosDEBlog]
http://codedojos.wordpress.com/
[CodersDojosBlog ]
http://codersdojo.org/

Eclipse aufsetzen


Flattr this

Motivation

Sie programmieren in Java? Arbeiten auch mit Eclipse? Benutzen SVN? Administrieren Projekte auf Sourceforge? Builden Ihre Projekte mit Maven? Bauen sich eigene DSLs mit EMFText?

Nachdem Sie längere Zeit ihre zuverlässig arbeitende Traumkonfiguration der IDE und Ihrer Plugins erfolgreich benutzen, steht nun ein Versionswechsel an? Da inzwischen die Eclipse Entwicklung um einige Releases vorangeschritten ist lohnt sich kein Update sondern nur eine Neuinstallation der aktuellen Eclipse Version? Dann geht es Ihnen wie mir!

In längeren Intervallen aktualisiere ich mein System vollständig. Da ich es noch nie geschafft habe sofort das gleiche System wie vorher zu installieren beschreibe ich in diesem Artikel wie ich die Konfiguration durchführe. Damit es zukünftig schneller geht ohne eine Komponente zu vergessen bzw. nicht benötigte Komponenten irrtümlicher Weise zu installieren.

Los gehts

  1. Download der aktuellen Eclipse Version (IDE Classic Version) per Torrent und Installation unter
    c:\Program Files\eclipse\<eclipseversion>\
  2. Anpassen der eclipse.ini wie folgt:
    • hinzufügen der Option: -showLocation
    • anpassen der Speicheroptionen auf:
      –launcher.XXMaxPermSize
      256m
      -vmargs
      -XX:MaxPermSize=256m
      -Xms128m
      -Xmx512m
  3. Einrichten der Update Sites:
  4. Alle verfügbaren Update Sites auf enabled setzen (nicht funktionierende entfernen)
  5. Folgende Pakete auswählen und installieren
    • Collaboration/m2e Maven Integration for Eclipse
    • Collaboration/m2e slf4j over logback logging
    • Collaboration/Subversive SVN Team Provider
    • EMFText/EMFText SDK
    • EMFText/EMFText Access
    • EMFText/EMFText Shared ANTLR 3.4.0 Runtime
    • Modeling/Acceleo SDK
    • Modeling/Ecore Tools SDK
    • Subversive SVN Connectors/Subversive SVN Connectors
    • Subversive SVN Connectors/SVNKit 1.3.5 Implementation
  6. Einstellungen unter Windows/Preferences
    • General/Editors/Text Editors
      • Show line numbers
      • Show print margin at 80
    • Install/Update/
      • Automatic Update: true
    • Java/Build Path
      • Source: src/main/java
      • Bin: target/classes
    • Java/Compiler
      • Comilance Level: 1.6
    • Java/Installed JREs
      • C:\Program Files\Java\jdk1.6.0_14
    • Maven/Installations
      • Add: C:\Program Files\apache-maven-3.0.3
    • Maven/User Settings
      • C:\Users\SchubertT006\.m2\settings.xml

Hinweis: Nach der Konfiguration darf das ECLIPSE_HOME nicht mehr umbenannt oder verschoben werden. Bei den Konfigurationen zu Maven und anderen Dingen werden offensichtlich irgendwo vollständige Pfadinformationen hinterlegt. Nach einem Umbenennen sind diese Plugins nicht mehr verfügbar bzw. ihre Einstellungen erscheinen nicht mehr unter Windows/Preferences .

Preferenzen einstellen (Window/Preferences/…)

Weitere Quellen

Industrielle Softwareproduktion


Flattr this

Um was geht es?

Heute gibt es mal nichts für den Praktiker. Um genau zu sein es gibt nicht einmal etwas für den Architekten oder Theoretiker. Dieser Artikel soll einfach nur zum Nachdenken und zur Ideenfindung anregen.

Was bisher geschah

Mein Informatikstudium liegt nun schon einige Jahre zurück, doch ich kann mich noch sehr gut an die Zeiten erinnern in denen mir grundlegende Methoden und Praktiken beigebracht wurden. Häufig waren diese zunächst unklar und lichteten sich dann für das Verstehen. Oft blieben jedoch trotzdem Teilbereiche unklar. In Datenbanken beispielsweise die Relation mit eigenen Attributen oder die Relation zwischen 3 Entitäten und ihre praktische Bedeutung. Doch da war der Gedanke, dass ein Lehrling erst einmal seine Werkzeuge zu benutzen lernen sollte, dann wird sich der Rest als Geselle schon erschliessen. Das hat in aller Regel auch so funktioniert. Doch einige Dinge blieben unklar, beispielsweise:

  • Datenbanken gibt es bereits sehr lange, warum bieten führende Hersteller immer noch kein Tool in dem ich die Verbindungsdaten zweier Datenbanken eingebe und das Tool bestimmt die Deltas (je nach Wunsch nur Struktur oder auch Struktur und Daten) und erzeugt ein Skript welches fehlerfrei durchläuft sofern keine Änderungen an den Datenbanken vorgenommen wurden. Also ohne Meldungen wie „XXX-01418: specified index does not exist“ und ähnliche Dinge.
    Es gab Zeiten in denen habe ich Logs von Deltaskripten nach aufgetretenen Fehlern durchsucht. Dabei musste ich aus hunderten Fehlermeldungen die finden die wirklich relevant waren. Nicht gerade optimal für einen Rollout auf Produktion. Alles nur weil die Skripte händisch erstellt wurden und dabei ein erprobtes aber fixes Schema verwendet wurde.
  • UML in Verbindung mit OOA/OOD sollte den Bruch wie er von SA/SD bekannt war verhindern und eine einheitliche Sprache für alle Stakeholder bieten. Doch warum wurde immer beim Klassendiagram und nicht beim Use-Case eingestiegen? Weil es nach dem Use-Case nicht weiter ging. Da war eine Lücke und nach dieser kamen die Klassendiagramme und die Interaktionen, Aktivitäten und der Rest.

Umso länger ich darüber nachdenke um so mehr Beispiele würden mir einfallen. So haben wir gearbeitet! Jeden Tag! In fast jeder Firma! Wir sind von der Uni gekommen oder aus der Lehre, mit vielen Ideen und haben dann die klägliche Praxis kennengelernt. Waren wir damit zu frieden? Natürlich nicht! Haben wir was geändert? Wohl kaum! Generelle Änderungen gingen immer nur in kleinen Schritten und dauerten viele Diskussionen, Argumentationen und vor allem Zeit. Warum willst Du denn von CVS auf SVN umstellen nur weil es das jetzt gibt? Wegen der Ordner? Mein Gott wen interessieren die Ordner – das ging doch bis jetzt auch und ob da die Historie erhalten bleibt ist noch die 2. Frage. In den Kommentaren sind auch Sonderzeichen – ich glaube nicht das das geht. Hat das schon mal jemand gemacht? Das kannst Du doch einfach in der Root editieren – wo ist Dein Problem? Das machen wir jetzt nicht! Viel zu großes Risiko. Kommt ihnen einer der Sätze bekannt vor?

 

Dazu kamen dann noch diese ständigen Hypes. Gestern war es eine Client-Server Anwendung, dann ein Web Client (ja ich weiss das sind wirklich verschiedene Architekturen). Dann war der Web Client nicht mehr gut genug. Zurück? Mit Nichten! Wir brauchen einen Rich Client. Und dann gings erst richtig los. Thin Client, Fat Client, Smart Client, Rich-Thin Client, …. Alles dasselbe doch nie ganz. Jetzt musstest Du vor dem Gespräch beim Café erstmal erklären was Du unter welchem Begriff verstehst damit Du mit den Anderen reden konntest. Dannach die Frameworks: Hibernate, Spring, Keel, … und die Methoden: Objektorientiert, Aspektorientiert, Datenzentriert, agile, XP, Scrum und letztlich die Sprachen: Scala, Ruby, Rails, Closure, …

Viele von uns waren doch nur am Ausprobieren was sich wie einsetzen lässt und was sich wie mit was verträgt. Nebenbei auch noch die Arbeit schaffen, da waren ja noch neue Features zu implementieren – Wahnsinn!

Bei dieser Fülle an Ablenkung blieb die eigentliche Herausforderung unbeachtet auf der Strecke liegen: Wie werden wir besser, schneller, effizienter und effektiver? Wie erhöhen wir die Qualität, wie können wir schneller ausliefern und die Kundenzufriedenheit verbessern?

Nicht das es nicht genug Controling gegeben hätte. Oh nein! Excel wurde schon massiv benötigt um schicke Statistiken für das Management zu erstellen. Doch was haben sie gebracht? Wir haben Continius Integration eingeführt und Prüfungen mittels Checkstyle und Cobertura eingebaut aber das Build bei Verletzungen nicht brechen lassen. Wir haben gezielte Aktionen durchgeführt, eine Woche lang die Verstösse durch Refactoring eliminiert. Die Anzahl der Verletzungen sank unter die festgelegte Grenze. Die fachlichen Fehler stiegen vereinzelt 🙂 Dann wechselte der Focus des Managements und nach einem Jahr wurden die Statistiken erst wieder ausgewertet. Den alten Wert der Verstösse hatten wir wieder erreicht und um etliches überschritten. Wem ging das nicht so? Wer lies das Build brechen und riskierte eine verspätete Auslieferung auf die nächste Testumgebung? Ihr habt den Systemtest in Bedrängnis gebracht! Wegen Euch konnte er erst später anfangen mit testen!

Trotz allem immer der Glaube es wird besser werden, irgendwann werden wir es schaffen, wir verbessern unsere Prozesse bis es fluscht. Habt Ihr heute Prozesse? Seit Ihr Kundenorientiert, serviceorientiert arbeitet Ihr nach ITIL und bereitet Euch bereits auf SOA vor? Oder seit Ihr sogar agile? *psst*! Fluscht es jetzt?

Dennoch, ich habe in letzter Zeit tatsächlich wieder Hoffnung. Es gibt Leute, die fragen uns ob wir eigentlich professionell arbeiten. Ob das was wir da machen eigentlich Hand und Fuß hat. Die fragen das auch sich selber! Die vergleichen Softwarentwicklung mit einem Handwerk. Die hinterfragen unsere Ausbildung und unsere Arbeitsweisen. Und sie tun gut daran. Ich bin begeistert davon. Endlich fangen wir mal am Anfang an und stellen die hoffentlich richtigen Fragen in der richtigen Reihenfolge. Endlich ist es mal nicht unsere Sturrheit wegen der wir dem Chef vorschlagen das nicht mehr noch vor dem täglichen Wartungsfenster um 20:00 Uhr zu fixen sondern es ist unsere Verantwortung die uns dazu antreibt. Den Gedanken finde ich gut.

Aber das eigentliche Problem haben wir immer noch nicht entdeckt. Wir haben es über die vielen Jahre aus den Augen verloren. Die Frage die sich viele von uns schon vor Jahren stellten. Aber wir haben sie nicht vergessen! Gestern tauchte sie wieder auf. In google*plus. Da fragte einer: „Was ist so anders bei Softwareentwicklung?“. Ja genau: Was ist es? Warum bauen wir Software nicht genauso wie andere Autos oder Schrauben am Fließband? Ich habe viele Antworten bislang auf diese Fragen gehört. Keine hat mir diese Fragen zufriedenstellend beantwortet.

Wir sollten anfangen jetzt darüber nachzudenken, bevor wir das nächste Framework schreiben oder die nächste tolle Sprache erfinden.

Ich finde es ist ein wichtiges Thema und ich finde es hat einen solch langen Artikel auf meinem Blog verdient. Außerdem hoffe ich, dass die nahe Zukunft endlich Antworten auf diese Fragen liefert. Weltweit sind bestimmt genug Berater verfügbar um Antworten auf diese Fragen liefern zu können. In diesem Sinne – frohes, professionelles Schaffen.

DSL Tutorial Teil 2


Flattr this

Um was geht es?

Dies ist der letzte Teil meines 2 teiligen DSL Tutorials. Ziel des Tutorials ist das Erstellen einer DSL zur Beschreibung von Vektorgrafiken und der Bereistellung eines Generators um daraus svg Dateien zu erzeugen. Die DSL wird in [DSL-1] erstellt. Dieser 2. Teil befasst sich aufbauend auf Teil 1 mit der Erstellung eines Generators.

Einrichten der Arbeitsumgebung

Vor Beginn dieses Teils müssen Sie alles unter [DSL-1] beschriebene durcharbeiten. Ich setze die funktionierende DSL mit der im Teil 1 vorgenommenen Definition voraus.

Los gehts

Die folgend dargestellten Projekte sollten im Eclipse Arbeitsbereich zu sehen sein.

015 ProjektUebersicht

Als Erstes fügen wir dem DSL Projekt die Acceleo Nature hinzu und aktualisieren die Ansicht.

016 AddNature

Nun weisst unser DSL Projekt ein Overlay Icon von Acceleo auf und wir können über das Kontextmenü das Generatorprojekt erzeugen.

017 GeneratorProjektErzeugen

Es erscheint ein geführter Dialog per Wizard. Hier passen wir den Projektnamen so an, dass er statt auf ui auf generator endet. Außerdem nehmen wir Änderungen an den Settings (letzte Tab) vor. Die nachfolgenden Bilder verdeutlichen dies.

018 Dialog 019 Einstellungen

Wichtig der Filter der Dateinamen! Er entscheidet darüber für welche Dateien der Generator zur Verfügung stehen wird. Außerdem habe ich mich für einen eigenen Target Pfad entschieden (target/generated-sources), damit nicht ausversehen Projektdateien überschrieben werden.

Zum Abschluss bitte mit Finish bestätigen.

Im neuen Projekt setzen wir als Erstes den Java Output Build Pfad auf target/classes, da ohne diesen Schritte manchmal keine Templates angelegt werden können. Nun müssen wir auch dem neuen Generator Projekt zunächst manuell die Acceleo Nature zuweisen (leider nimmt Acceleo diese Zuweisung nicht automatisch vor). Nun stehen auch hier weitere Kontextmenüeinträge zur Verfügung. Somit können wir nun im Package org.emftext.language.svgd.generator ein Main Template anlegen. Dazu bitte auf dem Package Ordner über das Kontextmenü den Neu Dialog aufrufen und Acceleo Main Module File auswählen. Dann einfach Next und Finish – der Rest ist bereits korrekt vorbelegt.

020 MainTemplateAnlegen

Jetzt sind 2 neue Dateien im Package entstanden: eine Main.java (interessiert uns nicht weiter) und eine main.mtl. Letztere sollte auch geöffnet wurden sein und wird von uns nun mit folgendem Inhalt gefüllt:

[comment encoding = UTF-8 /][module main(‚http://www.emftext.org/language/svgd&#8216;)/][template public main(model : SVGModel)][comment @main /][for (element : Form | model.elements)] [file (element.name.concat(‚.java‘), false, ‚UTF-8‘)] Testfile [/file][/for][/template]

Im common Package in der Klasse GenerateAll ersetzen wir die doGenerateMethode mit folgendem Code:

Code der doGenerate Methode in GenerateAll.java

Wenn wir unsere DSL jetzt wieder als Eclipse Anwendung starten, können wir dort zu unserem Beispiel bereits Code generieren. Achtung die verschiedenen Formen sollten auch verschiedene Namen bekommen damit nicht alle die gleiche Java Klasse generieren 🙂

021 BeispielInstanz

So sieht ein erstes Beispiel aus. Damit ist der Generator prinzipiell arbeitsfähig und wir können uns dem Implementieren der Fachlichkeit zuwenden.

Den vollständigen Umfang der Acceleo Sprache zu erklären möchte ich hier gar nicht erst versuchen (dazu gibt es eine sehr schöne Hilfe in Eclipse selber). Aber damit das Tutorial am Ende auch eine SVG Datei generiert, habe ich folgende Änderung an der main.mtl durchgeführt. Bitte den Inhalt der Datei komplett ersetzen mit dieser main.mtl (odt) oder dieser main.mtl (doc) .

Leider lies sich der Code hier im Blog nur schlecht formatieren. Auf jeden Fall muss die <?xml Zeile ganz links anfangen da sonst der Browser das Bild nicht interpretieren kann. Und so kann ein funktionierendes Beispiel in Eclipse aussehen.

022 FinalesBeispiel

Ich hoffe das Tutorial konnte einen Einblick in die Praxis des Generatorbaus geben. Ziel war den Leser schrittweise zu einem funktionierenden Beispiel zu verhelfen. Der Aufwand zur Erstellung des Tutorials hat dann doch mehr als ein Wochenende in Anspruch genommen. Daher habe ich auch auf die Erklärung vieler Details verzichtet.

Falls jemand weitere Fragen dazu hat oder Details wissen möchte, bitte kommentieren dann liefere ich diese noch nach.

Vielen Dank fürs Lesen und viel Spass beim Generieren 🙂

[DSL-1]

DSL Tutorial Teil 1