Eclipse

20110409184854521-0-istock_000011251556xsmall

Seit vielen Jahren bietet eclipse eine erst klassige Java Entwicklungsumgebung. Besonders interessant ist jedoch die Erweiterungsmöglichkeit über plugins mit extension point Mechanismus. Eclipse ist damit der „Quasi Standard“ für die Entwicklung von eigenen Tools:
http://www.eclipse.org

Intellij Idea

Idea ist ebenfalls eine phantastische IDE, die besonders bei Grooy und Grails sowie Scala glänzen kann (gut dass ich bei der Java Usergroup bei einem Vortag eine persönliche Lizenz gewonnen habe)
http://www.jetbrains.com/idea/

Frying Pan

UML

Auch wenn die UML angetreten ist eine Verständlichkeit zwischen Anwendern und Entwicklern zu bieten, so gibt es doch sehr viele, oft nicht eingängige Modelle. Selbst Software Entwickler haben hiermit einige Probleme und riesige Class Diagram Tapeten sind nicht wirklich hilfreich. Hier die Spezifikation:
http://www.omg.org/spec/UML/

BPMN

mit der Business Process Modeling Notation rückt der lang gehegte Traum, dass sich Fachleute und Entwickler verstehen, endlich in greifbare Nähe.

Bei geschickter Modellierung werden diese Prozesse damit auch ausführbar, wobei eine komplette Unterstützung – ohne die Umsetzung durch Entwickler – doch eher einen Fast Food Charakter hat.

Mittlerweile gibt es eine akademische Initiative zur BPM Modelling (in der auch der Oryx Modeller aufgegangen ist):
http://bpt.hpi.uni-potsdam.de/Oryx

und die – „Activitiisten“ 😉 – Bernd Rücker und Jakob Freund haben auch ein leicht verständliches Praxishandbuch BPMN geschrieben.

Mit anderen austauschen kann man sich dabei im:
http://www.bpm-netzwerk.de/

DSL

Domain Specific Languages versprechen eine höhere Produktivität und Verständlichkeit.

Insbesondere Groovy und Scala eignen sich bestens zum Bauen von internen DSLs:
http://www.amazon.com/Groovy-Domain-Specific-Languages-Fergal-Dearle/dp/184719690X/

Und wer umbedingt statt einer internen DSL mit einer externe DSL noch seine eigene „Software Language“ – neben der Flut von Sprachen auf der JVM – erstellen möchte, dem sei zu xText geraten:
http://www.eclipse.org/Xtext/

20110409184854698-2-istock_000016079800xsmall

Framework

Ohne eine Unterstützung eines Application Frameworks lassen sich die heutigen Systeme aufgrund deren Komplexität kaum noch bewältigen. Moderne Frameworks treten jedoch eher in den Hintergrund. Sie unterstützen InversionOfControl und rufen damit die Applicationsklassen auf anstatt wie gewohnt umgekehrt.

Benötigte „Services“ werden durch eine Dependency Injection zur Laufzeit automatisch „verwebt“ – entweder durch Konfigurations Dateien oder auch über Anotationen. Mit der CDI (Context und Dependency Injection) des Java EE 6 Standards wird erstmals eine fachliche „Verknüpfung“ möglich.

Ausserdem erscheint es heute mit ConventionOverConfiguration – mit einem Scaffolding Ansatz – nicht mehr nötig die GUI – ob Desktop Client oder Web RIA – mühsam auszuprogrammieren, wenn sich die GUI quasi automatisch aus dem Domain Model ergibt. Insbesondere Grals ist hier sehr stark. Auch wenn dort Scaffolding eigentlich nur für eine CRUD – Admin Oberfläche gedacht ist, kann man hier viel mir einer eigenen Anpassung erreichen. Hierzu ist jedoch ein bisschen Framework Erfahrung nötig, da man dann ja den Generator für den Generator schreibt …

 

Test Driven Development

Cook's knife

Nur mit automatisierten Tests kann man die Qualität der Software sicherstellen. Ausserdem ist erst damit ein Refactoring des gesamten Systems möglich ohne etwas nebenbei zu zerstören.
Daher ist ein TestDrivenDevelopment heute Standard.

 

Static Code Analsysis

20110409185839306-1-istock_000000551625xsmall-2

Um Java Umfeld sind die folgenden Tools Standard:
Find Bugs – analysiert den Source Code und findet viele „bedenkliche Stellen“:
http://findbugs.sourceforge.net/

PMD – verschiedenste Metriken:
http://pmd.sourceforge.net/

Check Style – prüft ob der Source Code sich and die Vorhaben hält:
http://checkstyle.sourceforge.net/

nach Simon Wiest (siehe Köche) lassen sich alle diese Metriken gut mittels dem Sonar Server visualisieren, sein Buch Continous Integration mit Hudson/Jenkins ist ein unbedingtes Muss …
http://www.sonarsource.org/

ein Beispiel gibt’s unter:
http://nemo.sonarsource.org/

 

Versions Kontroll-System

Ohne Versionsverwaltung kann man heute keine Software mehr im Team entwickeln. In letzter Zeit erfreut sich das verteilte GIT grosser Beliebtheit:
http://git-scm.com/

Build Tools

20110409185839368-2-istock_000016535672xsmall2-2

Bei der Entwicklung im Team ist es zweckmäßig einen Standard Bau Prozess einzusetzen, der selbständig ausserhalb der IDE läuft. Im Java Umfeld vereint dabei Graddle die Ansätze von Ant und Maven, ein erstes Buch dazu Building and Testing with Gradle :
http://www.gradle.org/

Etwas bodenständiger ist da noch Maven:
http://maven.apache.org/

mit tycho kann man dabei auch eclipse plugins, features, update sites und Produkte nach dem Manifest First Ansatz mit minimalen Aufwand ausetzen:
http://www.eclipse.org/tycho/

und mit archiva gibt es einen guten Repository Server, der auch p2 repositories von eclipse packt:
http://archiva.apache.org/

Es gibt mittlerweile auch ein Grundlagenwerk für alle Themen der Automatisierung:
http://www.amazon.de/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912/

Continous Integration

Wenn man einen automtisierten Build hat liegt es Nahe im Hintergrund – nach jedem einchecken – alles automatisch aus der Versionsverwaltung zu holen, zu bauen und auch Tests und Metriken auszuführen. Hierfür gibt es die Continuous Integration Tools wie Cuise Control und derzeit angesagt Jenkins:
http://jenkins-ci.org/

Dev Ops

im Zeiten der „totalen“ Automatisierung hin zu einer „Continuous Delivery“ ist das Zusammenrücken von Entwicklern und Administratoren gefragt. Damit die ständigen Releases nicht zum Alptraum eines gewissenhaften Admins werden. Damit ist auch eine zunehmende Automatisierung der Administration von Nöten. Mit Chef:

http://www.opscode.com/chef/

steht eine Open source Lösung zur Verfügung …