Reflektion

Eine Entwicklung ohne die Einbeziehung von Open Source ist anhand der zunehmenden Komplexität der Software Lösungen nicht mehr vorstellbar. Allerdings gibt es bei der Benutzung oftmals wegen fehlender Doku, Bugs und unnötig kompliziertem Sourcecode – viele Köche verderben den Brei – doch einige Problemchen, die einen zum „Troll“ werden lassen: – zum Internet Troll Thema gibt es dieses wunderbare Video: http://www.stubbornella.org/content/2012/05/31/dont-feed-the-trolls/

Meine „Wut“ ist aber eher daher bedingt, dass ich schon oft in der Firma erleben musste, dass wieder mal ein Silver Bullet Syndrom ohne kritische Hinterfragung verfolgt wird. Und wenn man dann Missstände angespricht, wird man als zu blöd für die tolle XY Technology hingestellt …

Doch dafür können die Macher nix. Allerdings erlebt man auch zwei unterschiedliche Lager. Die einen scheinen so eine Art M(V)ision zu verfolgen und erstellen neben blütenreinen Lösungen auch noch eine umfangreiche Dokumentation. Die anderen sind „echte Entwickler“ und vermeiden die Dokumentation wo es nur geht …

Vom Herzen her würde ich gerne „Open Source Entwickler“, zumindest zu einem Teil sein. In der Freizeit bin ich dazu zu „faul“ aber in der Firma könnte man ja für solch eine Option immer wieder werben.

Ich hatte in meiner beruflichen Laufbahn schon immer mehr Freude für alle Entwickler ein Framework zu basteln, statt mich auf den „Produkt Lorbeeren auszuruhen“ …

Alles begann mit der Java Platform
meinen Berufsstart hatte ich mit der C++ Entwicklung auf dem Macintosh. Codewarrior war damals eine sehr schöne Entwicklungsumgebung. Aber die Sprache C++ war eher nackt und wir haben alle möglichen Bibliotheken drum herum gestrickt.

Ab 1999 bot sich dann die Gelegenheit einen Internet Marktplatz mittels der recht neuen J2EE Platform zu entwickeln. Und auf einmal hatte ich mit einer unglaublich umfangreichen und gut durchdachten Platform zu tun, ich war völlig davon begeistert und habe bis 2012 dieses Know How ausbauen können. Sicher war einiges kompliziert, aber die Vision des Standards und die aufkommenden J2EE Patterns überzeugten…

Irgendwie ist dennoch J2EE als zu kompliziert in Verruf gekommen und die Community um JBoss und Spingsource hat das ganze stark vereinfacht. Erfreulicherweise sind heute diese Erfahrungen auch wieder im Java EE 6 Standard angekommen.

Eclipse – modular und erweiterbar

Seit Ende 2004 erstelle ich sei Harman Becker im Architecture & Tools Team eine modellgetriebene Entwickler IDE mit Plugins auf Basis von Eclipse RCP …

Erich Gamma hat in seinem Team bei iBM mit dem Eclipse Framework – insbesondere mit den Erweiterungsmöglichkeiten mittels Extension Points – ein zukunftweisendes Framework für die IDE Entwicklung und eine phantastische Java IDE zu Wege gebracht.

Mit dem Eclipse Modeling ist auch eine Platform verfügbar, die heute doch noch den MDSD Ansatz zum Erfolg geführt hat, wie auch wir in verfolgen…

Insbesondere ist aber das Projektmanagement der Eclipse Community hervorzuheben, die es jedes Jahr wieder schafft auf den Punkt alle Top Projekte synchron auszuliefern, einfach unglaublich …

Erich Gamma hat versucht auch diese Erfahrungen in der Jazz Entwicklung weiterzugeben in einen visionären Ansatz für ein Tooling, das die kolloborative Entwicklung in weltweit verstreuten Teams unterstützt. Allerdings kenne ich irgendwie keinen der das Ding benutzt (das mag ja auch an IBMs Sales Strategie liegen). Nun ja jetzt ist er auch bei Microsoft …

Allerdings erscheint mir vieles in Eclipse – insbesondere EMF, auch wenn damit das XML Bindung super von der Hand geht – unnötig kompliziert. Viel Zeit kann so aber auch mit der GUI Entwicklung verbraucht werden – die Sache mit den Layout Managern ist – ebenso wie in Swing – schon eine schöne Idee, allerdings sollte es daneben auch eine „einfachere Konvention“ geben …

Doch mit Ellipse 4.2 – das Juno Release kommt im Juni 2012 – wird die RCP Entwicklung mit moderneren und fexibleren Ansätzen – z.B. Dependance Injektion und Pojos für Views, sowie Java FX Rendering hoffentlich deutlich einfacher.

Groovy und Grails – die Suche hat ein Ende

http://groovy.codehaus.org/
vor ein paar Jahren hab ich dann auf der JAX einen Groovy Vortrag gesehen und beschlossen, das muss ich mal antesten ..

Und da tat sich einen phantastische neue Welt auf. Eine aktive Community hatte für alle Probleme, die ich mir für meinen „Entwicklerhimmel“ so vorstellen konnte, eine super einfache und gut dokumentierte Lösung parat …

Und ich konnte doch noch dem Charme der funktionalen Programmierung erliegen …

und die Bücher Groovy in Action und Grals in Action haben meinen Entwicklerhorizont unglaublich erweitertert. So profitiere ich ständig davon auf der Suche nach der einfachen Lösung.

Der Vortrag Groovy Gems von Dierk König auf der Java Usergroup passte da gut ins Bild – nich zuletzt kam hier auch das Thema Philosophie zur Sprache – die „Groovy Jungs“ glauben einfach an das Gute im Entwickler

Und mit Groovy 2 ist dann endlich die leidige Kritik bzgl. statischer Typisierung vom Tisch – ich versteh das Theater eigentlich nicht, denn Groovy Eclipse zeigt doch mittlerweile schön an, was dynamisch aufgefasst wird und ich benutzte dieses Feature eigentlich sehr gerne.

Besonders hat mich der Convention Over Konfiguration Ansatz in Grals und auch das Scaffolding überzeugt. Die Idee konnte ich in unsere Eclipse Toolchain übernehmen und so lässt sich die Produktivität und Qualität stark verbessern, indem man – aufbauend auf einem Typsystem eine Darstellung anbietet. So kann man sich dann einen Editor für sein Domain Modell mittels nahezu „Zero GUI Coding“ anbieten, aber bei Bedarf jederzeit doch noch erweitern …

NoSQL

Da wir zunehmend verschiedene Model Artefakte in der Firma mit unserer Toolchain unterstützen müssen, bin ich dabei ein eigenes Modell Repository zu entwickeln. Da neben EMF auch beliebige andere Modelle unterstützt werden müssen kam das CDO Repository und der EMFStore nicht in Frage. Naheliegend ist eine kombinierte NoSQL Lösung mit einer Graph Datenbank für die „Modell Beziehungen“ und eventuell einer Dokumenten Datenbank für das Caching und eine verteilte Persistent mit Sharding Unterstützung.

Schnell waren zwei Kandidaten gefunden:
http://neo4j.org als Graph Datenbank und http://mongodb.org als Dokumenten Datenbank. Und was muss ich sagen, beides ist perfekt dokumentiert und hat eine vielfältige Sprach Unterstützung und der Einstieg ist super einfach.

So hab ich mir denn das Neo4J Manual innerhalb einer Woche in der Mittagspause reingezogen und danach hab ich zwei Tage mein Zeugs programmiert und das Ganze hat auch Anhieb richtig gefunkt und selbst die Visualisierung mit Neoclipse war in zwei Stunden eingebaut, einfach traumhaft …

dagegen hab ich dann noch einen halben Tag verbraucht um meine Model Search View in eine Ellipse Section zu packen (hier muss ich wohl noch mein Scaffolding verbessern ;-))

Das einzige, was ich nicht verstehe ist, warum Neo4j bei der Cypher API auf Scala setzt, Groovy würde mir viel besser schmecken …

Actitviti – die BPMN 20 Engine für Entwickler

sicher sind leider viele Open Source Lösungen nicht so gut dokumentiert. Aber einerseits macht das eh kein Entwickler gerne und andererseits kann man das auch nicht erwarten, wenn die Commiter mit Hochdruck an einer Lösung arbeiten. So gibt es auch oft das Modell zusätzlich Support anzubieten, um damit die Erfahrungen weiterzugeben.

Einen guten Weg geht meines Erachtens Camunda. Sie haben ihre Erfahrungen im Praxishandbuch BPMN 20 super weitergegeben. Arbeiten aktiv an Activiti mit (dafür gibt es auch ein Activiti in Action MEAP bei Manning) und zusätzlich bieten sie einen Mehrwert aus Ihrer vielfältigen Projekterfahrung für den Enterprise Ansatz in Ihrem kommerziellen Produkt Cammunda Fox an, welches Activiti als Basis benutzt..