Donnerstag, 22. Dezember 2011

Schöne neue Maven Welt

Was mich an Maven oder viel mehr an Maven Entwicklern stört, ist dass sie Abhängigkeiten aufbauen statt sie abzubauen. Wenn ich an einem Open Source Plugin eines größeren Systems nur eine Zeile Code ändern möchte, dann  muss ich gleich das ganze System und nicht nur das Plugin auschecken. Das ist absurd. Guter Code hat eine eine geringe Kopplung zwischen Modulen und wenige Abhängigkeiten. Parent Module sind schön aber nicht immer notwendig. Hört auf alle möglichen Features zu nutzen. Jedes neue Feature sollte das Gesamtsystem einfacher und nicht komplizierter machen.

Samstag, 22. Oktober 2011

Clean Code 2

Ich hatte schonen einen Post zu Thema Clean Code geschrieben, da wurde ich auf das Buch Clean Code von Robert C. Martin hingewiesen. Er beschreibt dort keine Techniken sondern eher Prinzipien, also mehr wie man Code schreibt. Immer wenn ich mit Programmierern über das Thema sprach, ergaben sich lebhafte Diskussionen über einzelne Prinzipien. In meiner Arbeit sind mir viele der Dinge im Buch begegnet. Klassen mit generischen Namen wie Statistik. Jeder mit dem ich sprach kennt eigene Episoden, die man auch in dieses Buches wiederfindet. An der ein oder anderen  Stelle an wird sich jeder Softwareentwickler wieder erkennen. So ist es hervorragend für Diskussionen unter Kollegen oder im Team geeignet. Schön an dem Buch ist, das man es auch quer lesen kann und wenn man genug Zeit hat auch sich die umfangreichen Codebeispiele ansehen. Es ist eines der wenigen Bücher bei denen ich dies wirklich getan habe. Dafür wird man dann aber auch meist mit einer neuen Einsicht belohnt.


Es ist aus meiner Sicht ein wichtiges Buch für alle Programmierer und unbedingt jedem zu empfehlen. Ich kann neben der englischen auch die deutsche Version empfehlen. Beide Versionen sind gelungen.

Dienstag, 6. September 2011

Onlinepetition zum Thema Vorratsdatenspeicherung

Ich habe ja nichts zu verbergen, also warum sollen meine Daten denn nicht gespeichert werden. Das ist wohl die bekannteste Meinung zu diesem Thema. Aber die Verdachtslose Speicherung  von Onlinedaten lässt sich per Knopfdruck in ein Überwachunginstrument verwandeln und Überwachung ist der erste Schritt zur Abschaffung der Freiheit, im Internet wie auch in der realen Welt.

Auch der renommierte Chaos Computer Club (CCC) bezieht zum Thema Vorratsdatenspeicherung deutlich Stellung. Der CCC lehnt die Vorratsdatenspeicherung ab.


Darum denkt darüber nach und macht mit, unterzeichnet die Onlinepetition zum Verbot der Vorratsdatenspeicherung

Dienstag, 30. August 2011

Welche Stadt ist die IT Hauptstadt Deutschlands 2011

Hauptstädte gibt es viele, jedes Land hat eine Hauptstadt. Das Verbrechen hat eine Hauptstadt, Frankfurt. Aber welche ist die IT Hauptstadt Deutschlands. Eine Suche zum Thema bei Google bring nur PR-Informationen. Aber wir können auch anders, die Zugriffsdaten lüften das Geheimnis. Die IT Hauptstadt Deutschlands ist ... nein, nicht Berlin sondern das Rhein-Ruhr-Gebiet (Köln, Dortmund, Düsseldorf, ...). Also genauer gesagt die Java Hauptstadt ist die Rhein-Ruhr-Region im Jahr 2011 dicht gefolgt vom Berlin und München. Auch wenn man die Daten des Umlands der Metropolen mit einbezieht, bleibt das Rhein-Ruhr-Gebiet vor Berlin und München. Mit Abstand folgen Hamburg und Frankfurt. Interessant ist, dass 2010 die Reihenfolge leicht anders war. Sie war Rhein-Ruhr-Gebiet, München, Berlin, Frankfurt, Hamburg.

Die Daten sind Zugriffsdaten des Blogs und damit nur bedingt übertragbar, aber sie zeichnen gut ein Bild über die Verteilung der Software-Industrie (Java) in Deutschland. Was die Daten auch zeigen, dass es ganze Regionen in Deutschland existieren, in denen die Softwareentwicklung keine Rolle spielt.

http://de.wikipedia.org/wiki/Metropolregion#Liste_der_Metropolregionen_in_Deutschland

Montag, 11. Juli 2011

SVN Server aufsetzen

Codemanagement ist ein Grundbaustein fürs Projektmanagement. Die meisten Unternehmen betreiben eigene Server fürs Codemanagement. Mache sogar Mehrere. Aber auch hier gilt, viel hilft nicht viel. Private Projekte liegen oft bei Sorce Forge oder ähnlichen Anbietern. Aber man kann auch in 5 Minuten einen eigenen Server fürs Codemanagement aufsetzen. Im Internet gibt es eine Vielzahl von mehr oder weniger guten Anleitungen:

Aber es geht noch schneller:

Freitag, 1. Juli 2011

Vergleich von Build Systemen: Ant, Maven und Gradle

JAXenter versucht sich an einem besonderen Vergleich, es wurde versucht die Build Systeme Ant, Maven und Gradle zu vergleichen (Link).

Dabei wurden einige Argumente vorgebracht die nicht richtig sind.
  • Ant arbeitet sequenziell aber es ist sehr einfach mehrere Tasks zu parallelisieren. 
  • Maven kann ab Version 3 auch mehrere Task benutzen (Link).
  • Ant und Maven arbeiten auch inkrementell.
  • Maven ist auch in der Lage Ant in den Build einzubeziehen. Wenn auch in Grenzen (Link).
Trotz dieser kleinen Patzer ist es trotzdem nicht uninteressant die Artikel in JAXenter zu lesen.

Mittwoch, 29. Juni 2011

Maven: Build Jar with Dependencies

Um eine Applikation zu bauen die aus nur einer JAR-Datei besteht nahm ich früher das Maven Shade Plugin (http://programming-2.blogspot.com/2010/05/maven-shade-plugin.html). Dies geht auch einfacher mit Hilfe des, nein nicht des JAR Plugins, sondern mit Hilfe des Maven Assembly Plugins (maven-assembly-plugin). Das sieht dann wie folgt aus:


Freitag, 27. Mai 2011

Continuous Integration: Hudson

Brown Field Projekte sind oft in einem schlechten Zustand, oft wissen die Beteiligten gar nicht wie es um ein Projekt steht, oft haben sie nur eine Ahnung oder ein Gefühl. Um Brown Field Projekte unter Kontrolle zu bringen und Wartbarkeit, Qualität und Sicherheit zu erhöhen wird bei Brown Field Projekten als eine der ersten Massnahmen Continuous Integration (CI) etabliert. Zurzeit sind eine Reihe von CI-Systemen verfügbar. Dazu zählen die populären Systeme:
Alle drei Systeme eignen sich für Java-Projekte, sind aber offen und flexibel auch andere Programmiersprachen zu unterstützen. Der prinzipille Ablauf ist folgender:
  • Auschecken des Projektes aus der Codeverwaltung (CVS, SVN)
  • Build des Projektes (Maven, ANT)
  • Benachrichtung von Benutzern über das Ergebnis (Email)
In den Klammern hinter den Schritten stehen die populärsten Vertreter für diese Schritte. Sie werden in der Regel von allen CI-Systemen unterstützt. Oft unterstützen die CI-Systeme auch noch andere Systeme.

Continuum 1.3.7
Auf meinem Testrechner lief ein aktuelles Windows 7. Continuum ist sowohl aus Webapp für Tomcat als auch als Standalone-Version verfügbar. Letztere probierte ich zu installieren und zu benutzen. Leider liess sich Continuum nicht starten und eine Beschreibung war nicht zu finden. Das ist das AUS für Contiunuum. Continuum macht sonst den Eindruck sehr stark auf Maven zu fokussieren, also ist Continuum ein Tipp für alle Maven Benutzer.


Hudson 2.0
Auf meinem virtuelle Testrechner lief ein Fedora 14 Linux. Zusätzlich habe ich JAVA, ANT und Maven2 installiert. Leider ist keiner der CI-Systeme per YUM zu installieren. Schade, doch Hudson lies sich einfach von der Website über einen Link aus installieren. Das funktionierte sehr gut. Auch bei Hudson entschied ich mich für die Standalone-Variante. Nach der Installation lief Hudson schon als Demon, nur leider funktionierte Hudson nicht ganz, die Weboberfläche (http://localhost:8080) war da, liess sich aber nicht benutzen. Nach einem manuellen Start von Hudson als Root funktionierte alles.
/etc/init.d/hudson stop
java -jar /usr/lib/hudson/hudson.war
Strg+C
/etc/init.d/hudson start
Ich konnte Jobs einrichten und abarbeiten. Für den Zugriff aus CVS musst ich das Passwort und den Benutzernamen in Feld CVSROOT eingeben. Je nach dem wer (Root oder User) und wie (Demon oder Terminal) Hudson gestartet wird legt Hudson eine Verzeichnisstruktur an verschieden Orten auf dem Volume an. Also nicht erschrecken, wenn ihr Hudson als User startet und nicht die Jobs seht, die ihr vorhin angelegt habt, wahrscheinlich lief Hudsun da als Demon, also Huson beenden und als Demon neu starten. Dann ist alles wieder OK.
Zur CVS Integration kann Hudson auch die Datei .cvspass benutzen, das funktioniert aber nur eingeschränkt. So kann Hudson als Demon gestartet trotz richtiger Dateirechte nicht auf die .cvspass eines Benutzers zugreifen.
Ein schönes Feature ist auch die Möglichkeit von Hudson Programme wie ANT oder Maven selbständig aus dem Internet zu laden und sogar in verschiedenen Versionen dem Benutzer anzubieten. Auch wenn Fedora über ein aktuelles ANT verfügt ist es trotzdem zu empfehlen, das ANT via Hudson zu installieren, die erhöht die Konsistenz in der Softwareentwicklung und elemeniert ein potentielle Fehlerquelle, unterschiedliche ANT oder Maven Versionen.
Trotz dieser Hürden schien Hudson gut zu funktionieren, bis ich versuchte die Plugins zu aktualisieren. Dabei wurde meine Hudson Installation so beschädigt, dass Hudson nicht mehr zum Arbeiten zu überreden war. Schade.
Trotz dieser hidden Features ist Hudson zu empfehlen.

Sonntag, 15. Mai 2011

Java Performance Tipp Nummer 1

Die einfachste Möglichkeit die Geschwindigkeit von Java-Anwendungen zu erhöhen besteht darin, die aktuelle JVM zu verwenden. Es gibt einen deutlichen Performanceunterschied zwischen den zur Zeit gebräuchlichen Java-Versionen. Leider sind meine Bio-Benchmarkergebnisse (DNA Alignment) nicht mehr existent aber unter folgenden Links sind ähnliche Tests und Aussagen zu finden. Java 7 ist schneller als Java 6. Java 6 ist schneller als Java 5. Die Unterschiede sind größer als 10%, d.h. ein Update auf die aktuelle Java-Version lohnt sich auf jeden Fall.

Samstag, 14. Mai 2011

Codeoptimierung: Wurzel allen Übels

Das erste mit dem Softwareentwickler in Projekten anfangen, ist die Optimierung ihres Codes. Wahrscheinlich dient dies als Beweis ihres Könnens. Klar, Optimierungen sind sind immer ein Fall für erfahrenen Entwickler. Aus diesem Grund ist dieses Streben nach optimiertem Code von Beginn an verständlich. Nur was nützt schneller (dazu kommen wir in einem andern Post) Code der schnell Fehler produziert aber nicht die gewünschte Funktion? Durch die aufwendige Fehlersuche und Fehlerbehebung kostet das oben beschriebene Vorgehen mehr Entwicklungszeit im Vergleich zum normalen Entwickeln. Was lernen wir daraus, Optimierungen sind prima, wenn man sie nicht macht.

The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

Aus agiler Entwicklungssicht sind Optimierungen erst notwendig, wenn sie notwendig sind. Optimierungen sind Teil des Refactoringprozesses in der agilen Softwareentwicklung. Wichtiger ist die Verständlichkeit und die Wartbarkeit des Codes. Aber zurück zur Optimierung, der erste Schritt bei der Optimierung ist es, festzustellen das es ein Problem gibt, dass durch Optimierung gelöst werden kann, der zweite Schritt ist es das entsprechende Verhalten der Software zu dokumentieren und ein Testset aufzubauen mit dem die Ergebnisse nachvollziehbar sind. Im dritten Schritt wird das Problem analysiert (Profiling) und die beste Stelle (Bottleneck) zur Optimierung gefunden. Erst im vierten Schritt wird der Code optimiert. Dann wird der Effekt der Optimierung mittels des Testsets dokumentiert (fünfter Schritt). Die Optimierung von Code besteht aus folgenden Schritten:

  1. Feststellen und Dokumentieren das es ein Problem gibt.
  2. Definieren eines Testsets und Dokumentieren der Ergebnisse für den nichtoptimierten Code.
  3. Analyse des Problems z.B. mittels Profilings und finden der Codestelle für die Optimierung.
  4. Optimieren des Codes.
  5. Dokumentation der Ergebnisse des optimierten Codes mit Hilfe des Testsets.

Und eins sollte man nie vergessen, die Entwicklungszeit die in eine Optimierung fliesst, muss durch den Optimierungsgewinn gerechtfertigt sein.

Montag, 7. Februar 2011

Broken-Window-Theorie und Null-Tolleranz-Strategie bei der Softwareentwicklung

Für Alle die nicht mit den Themen vertraut sind, hier eine Minimaleinführung. Die Broken-Window-Theorie kann erklären wie Kleinigkeiten z.B. ein zerbrochenes Fenster zu Verwahrlosung eines Hauses, des Stadtviertels führen. Darauf aufbauend wurde von der New Yorker Polizei die Zero-Toleranz-Strategie angewandt, die kleinste Vergehen konsequent angeht und damit der Verwahrlosung schon in deren Entstehung begegnet. Dies ist ein effektive Strategie zur Verhinderung solcher Missstände.

Was hat die mit Softwareentwicklung zu tun? Dazu folgendes. Wenn ein neuen Entwickler zu einem bestehenden Projekt kommt und anfägt Code zu schreiben, dann setzt er den Code nicht nur so um, wie er es für richtig hält, sondern der bestehende Code wirkt sich auf ihn aus. Wenn also der bestehende Projektcode in einem suboptimalen Zustand ist, dann wirkt sich dieses Manko auf alle Programmierer aus. Sie werden zusehens schlechteren Code abliefern, im schlimmsten Fall kann dies zu einer negativen Abwärtsspirale führen. Als Gegenmassnahmen gibt es zwei Dinge. Erstens, der Code muss aufgeräumt werden und zwar sofort. Selbst Kleinigkeiten im Code korrigiert müssen korrigiert werden. Und Zweitens, dass man Code-Review auf Basis der Null-Toleranz-Strategie fahren muss. Mit Hilfe dieser beiden Verfahren ist es möglich eine gewachsene Code-Basis für zukünftige Erweiterungen fit zu machen. Aus einer anderen Perspektive, ohne Aktives Gegensteuern im Bereich der Softwarequalität werden schlechte Softwareprojekte schlechter. Diese Erkenntnis ist nicht neu, aber man kann sie mit Hilfe der Broken-Window-Theorie erklären und damit kennt man auch die Gegenmaßnahmen. Und so können Programmierer der New Yorker Polizei dankbar sein.