IDEs und der K(r)ampf zwischen Statik und Dynamik

Für Java existieren heute mit Eclipse, IntelliJ IDEA und Konsorten sehr mächtige Entwicklungsumgebungen. Cross-Referencing, Refactoring und Auto-Completion sind Features, die man nicht mehr missen möchte.
Dass diese Features für die aktuellen Skriptsprachen a la Python, Ruby oder Groovy nicht oder nur eingeschränkt existieren, wird häufig als Argument gegen diese Skriptsprachen verwendet.

Aber wird über diese Features wirklich reflektiert?

Cross-Referencing
Mit den Cross-Referencing-Möglichkeiten der IDE kann man auf Tastendruck oder Mausclick von einer Codestelle zum referenzierten Element gelangen (z.B. von einer Variablendeklaration zur Klasse, von deren Typ die Variable ist).

Natürlich sind die Cross-Referencing-Möglichkeiten in den IDEs deutlich mächtiger als eine Textsuche über Dateien. Aber ist der Unterschied wirklich so groß? Und ist die Textsuche häufig nicht sogar schneller?

Refactoring
Refactoring ist eine der großen Errungenschaften in der Neuzeit der Softwareentwicklung und ihr Automatisierungsgrad ist wirklich erstaunlich hoch. Aber welche automatisierten Refactorings nutzen wir überhaupt bei der täglichen Arbeit und wie häufig? Viele Entwickler verzichten sogar absichtlich auf bestimmte einfache Automatisierungen (z.B. "Introduce Variable"), weil sie von Hand schneller sind - die Mächtigkeit der IDEs führt bei großen Projekten leider dazu, dass die Arbeit mit ihnen mitunter doch etwas zäh wird.
Viele Refactorings kann man in der Tat mit vertretbarem Aufwand und Risiko auch von Hand durchführen. Einige andere (z.B. "Rename Class") lassen sich auch auf anderem Wege automatisieren (Find&Replace über Dateien). Natürlich kann man sich dann oft nicht 100%ig sicher sein, dass alles korrekt geändert wurde. Man muss anschließend die Tests ausführen. Dass muss man in Java aber auch, weil es immer mehr untypisierte Referenzen in XML-Dateien (Struts, Spring, EJB etc.) gibt, die den IDEs auch mal durch die Lappen gehen.

Auto-Completion
Bei der automatischen Vervollständigung tippt man nur den Beginn eines Wortes ein und die IDE ergänzt die fehlenden Zeichen. Dadurch spart man Tippzeit, reduziert die Wahrscheinlichkeit von Tippfehlern und muss sich nur an den Anfang von Methodennamen erinnern.
Interessanterweise gibt es auch in programmiersprachen-unabhängigen Editoren wie Emacs oder JEdit Auto-Completion. Dabei werden viel einfachere Verfahren eingesetzt als in den Java-IDEs, die aber erstaunlich gute Ergebnisse liefern. Ein ganz einfacher Ansatz besteht z.B. darin, bei der Auto-Completion nur die Wörter zu berücksichtigen, die in der aktuellen Datei schon mal verwendet wurden. Etwas umfangreicher ist der Ansatz, die Wörter aller Dateien eines Projektes zu verwenden.
Ähnlich wie beim Cross-Referencing sind diese Auto-Completion-Features der Editoren qualitativ denen der IDEs unterlegen. Aber wie beim Refactoring sie sind schneller.

Und das ist ein Faktor, den man nicht unterschätzen sollte. Ich ertappe mich beim Java-Programmieren jedenfalls immer wieder dabei, dass ich Namen komplett manuell eintippe, weil ich damit schneller bin als die zäh reagierende Entwicklungsumgebung. Und wenn ich in einem einfachen Editor eine Skriptsprache programmiere, genieße ich es, dass der Editor immer sofort reagiert. Die IDEs sind nur Bruchteile von Sekunden langsamer, aber das reicht schon aus, um den Flow beim Programmieren zu beeinträchtigen.

Post bewerten

Closures in Common Lisp

Martin Fowler published an online article about closures. He used the Ruby programming language for the examples. There are translations of the examples to Python and a language called Boo.

As a programming task for myself I did the examples in Common Lisp, which supported Closured already decades ago. A real lisper might be able to write the code in a more elegant way but I think the principle should become clear.

I didn't use the Common Lisp Object System (CLOS) since for this simple example an ad-hoc modeling with hashes is simpler.

;; Ruby
; def managers(emps)
; return emps.select {|e| e.isManager}
; end

;; Common Lisp
(defun is-manager (emp) (getf emp :is-manager))

(defun managers (emps)
  (remove-if-not (lambda (emp) 
                   (when (is-manager emp) emp))
                 emps))


;; Ruby
; def highPaid(emps)
; threshold = 150
; return emps.select {|e| e.salary > threshold}
; end

;; Common Lisp
(defun high-paid (emps)
  (let ((threshold 150))
    (remove-if-not (lambda (emp)
                     (when (> (getf emp :salary) threshold) emp))
                   emps)))


;; Ruby
; def paidMore(amount)
; return Proc.new {|e| e.salary > amount}
; end

;; Common Lisp
(defun paid-more (amount)
  (lambda (emp) (when (> (getf emp :salary) amount) emp)))

;; Ruby
; highPaid = paidMore(150)
; john = Employee.new
; john.salary = 200
; print highPaid.call(john)
  
;; Common Lisp
(let ((high-paid (paid-more 150))
      (john '(:name John :is-manager nil :salary 200)))
  (princ (funcall high-paid john)))


;; Tests
(defparameter manager-list 
  '((:name Stefan :is-manager nil :salary 150)
    (:name Henning :is-manager t :salary 151)
    (:name Martin :is-manager nil :salary 120)
    (:name Christian :is-manager t :salary 200)))

(princ #\newline)
(princ "Test function managers") 
(princ #\newline)
(princ (managers manager-list))
(princ #\newline)

(princ #\newline)
(princ "Test function high-paid")
(princ #\newline)
(princ (high-paid manager-list))
(princ #\newline)

Post bewerten

Sensing Variables for Refactorings

Michael Feathers hat ein Konzept namens Sensing Variables beschrieben, mit dem sich Refactorings an Methoden sicherer durchführen lassen. Ein häufiges Problem mit dem Refactoring "Extract Method" besteht darin, dass der selektierte Code-Block sich nicht automatisch in eine Methode verschieben lässt (z.B. weil die neue Methode dann mehrere Rückgabewerte haben müsste). Also muss man erstmal manuell die Methode manipulieren, bevor man "Extract Method" ausführen kann. Dazu muss man häufig die Reihenfolge von Anweisungen in der Methode ändern, kann aber nur schwer feststellen, ob sich durch das Verschieben die Semantik der Methode ändert. Sensing Variables helfen, an dieser Stelle mehr Sicherheit zu bekommen.

Post bewerten

DSL: Domain Specific Languages

Martin Fowler hat einen kurzen Artikel über DSLs in seinem Blog veröffentlicht. In dem Artikel erklärt er den Unterschied zwischen General Purpose Languages (GPL) und DSLs. Außerdem argumentiert Fowler, dass der Übergang zwischen APIs und DSLs fließend ist. Das API einer Bibiothek könne durchaus vergleichbar sein mit einer DSL.

Das finde ich sehr überzeugend, vor allem wenn man sich die dynamischen Skriptsprachen a la Ruby, Groovy oder Lisp ansieht. Dort wo in Java eigene DSLs für Build-Skripte (ANT), Datenbankabfragen (Hibernate Query Language, HQL) oder Oberflächenbeschreibung (HTML, JSP) verwendet werden, haben Ruby und Konsorten einfach nur Bibiotheken, die innerhalb der Programmiersprache verwendet werden.

Interessant finde ich, dass alle Artikel zum Thema DSL, die ich kenne (ich gebe zu, dass das nicht allzu viele sind), sich ausschließlich um Technologie-Domänen kümmern. Es kommen immer wieder dieselben technischen Beispiele für DSLs: SQL, ANT, etc. Das finde ich schade. Schließlich sind die technischen Aspekte in einem Softwareprojekt eher uninteressant im Gegensatz zu den fachlichen. DSLs nur für technische Aufgaben zu verwenden, riecht nach einer Optimierung an der falschen Stelle (wenn ich in einem Bereich 50% Aufwände spare, der nur wenige Prozent meiner Gesamtaufwände ausmacht, ist der Gesamtgewinn marginal).

Eigentlich müssten wir nach fachlichen DSLs suchen. Interessiert das Niemanden, ist das so schwer oder lese ich einfach nur die falschen Quellen?

Post bewerten

Flow - Softwareentwicklung im Fluss

Wenn ich heutige Java-Projekte sehe, dann ertappe ich mich immer wieder bei derselben Frage: "Muss das alles so schwerfällig sein?" Um dieser Frage nachzugehen, habe ich mich selbst gefragt, wie ich mir Softwareentwicklung vorstelle. Dazu fällt mir zuerst ein Wort ein: Flow

Meine Gedanken dazu habe ich in einem Online-Artikel niedergeschrieben.

Post bewerten

YouOS: Bye, bye Betriebssystem?

YouOS ist ein webbasiertes Betriebssystem mit allerhand Anwendungen. Das ganze Ding ist noch im Alpha-Stadium, aber die Richtung ist schon mal interessant:

• Keine Installation von Software auf dem eigenen Rechner.
  
• Zugang zu den eigenen Programmen und Daten von jedem Rechner der Welt aus.
  
• Automatische Datensicherung
  
• Zentrale Sicherheitsmechanismen gegen Viren und andere Angriffe

Eigentlich ist das Ganze eine naheliegende Idee. Mit Writeboards, Writely, GMail, NumSum, Flickr und anderen sind längst mehr Funktionen im Internet verfügbar, als der durchschnittliche Anwender benötigt. Was bisher fehlte, war die Integration. Man musste mehrere Accounts verwalten, sich URLs merken und konnte schlecht übergreifend über die Systeme arbeiten.

YouOS leistet das noch nicht vollständig, aber das Potenzial ist da.

Post bewerten

Buch: Hackers and Painters

Ich habe gerade das Buch "Hackers and Painters" von Paul Graham durchgelesen. In dem Buch ist eine Reihe von Essays veröffentlicht, die (fast?) alle auch online auf auf der Web-Site von Paul Graham verfügbar sind. Trotzdem lohnt sich das Buch, um es in der Bahn oder im Urlaub zu lesen.

Die Essays decken verschiedene Themenbereiche ab begonnen vom typischen Hacker-Charakter über Innovationen und Startups in der IT bis hin zum Programmiersprachenentwurf. Dabei vertritt Paul Graham häufig ungewöhnliche Ansichten und Ideen und regt damit zum Denken außerhalb der gängigen Bahnen an (warum die nächste Webanwendung nicht in Lisp schreiben?).

Mir hat das Buch jedenfalls sehr gut gefallen.

Post bewerten

Verantwortung in der Softwareentwicklung

Ich habe zusammen mit Henning Wolf einen Artikel über Berufsethos und Verantwortung in der Softwareentwicklung im Java-Magazin veröffentlicht. Der Artikel ist online verfügbar.

Der Artikel ist kontroverser als der Titel vielleicht vermuten lässt. Die drei Hauptthesen des Artikels sind:

1. Jeder ist verantwortlich für alles, was er tut.
   
2. Jeder ist verantwortlich für alles, was er denkt.
   
3. Jeder ist verantwortlich für alles, was mit ihm geschieht.
   

Wer würde das schon einfach so unterschreiben? Wer nicht, sollte den Artikel lesen.

Post bewerten

Regeln vs. Eigenverantwortlichkeit in agilen Projekten

Bei den agilen Methoden gibt es deutliche Unterschiede in den Vorgaben und Regeln, die sie definieren. So ist z.B. Feature-Driven-Development sehr strikt bzgl. Rollen und Verantwortlichkeiten und eXtreme Programming definiert den Entwicklungsprozess sehr detailliert. Auf der anderen Seiten steht Scrum, dass nur grob regelt, wie die Anforderungen in das Projekt eingebracht werden. Die restliche Ausgestaltung des Projektes obliegt den Entwicklern.

Was ist das bessere Modell? Wieviel Freiheit brauchen die Entwickler, um höchste Produktivität zu erreichen und wieviel Regeln muss man definieren, damit das Projekt nicht im Chaos versinkt?

Vielleicht hilft bei der Beantwortung dieser Frage das Dreifus-Modell der Qualifikationsaneignung (Skill Acquisition). Demnach brauchen Anfänger Regeln und Vorgaben. Bei der Arbeit in dem so vorgegebenen Rahmen entwickelt sich Erfahrung und Intuition, so dass die Regeln und Vorgaben immer weniger wichtig werden und sogar behindern können. Also wären Feature-Driven-Development und eXtreme Programming eher für Neulinge geeignet und Scrum für erfahrene Entwickler?

Post bewerten

XP-Days 2006 in Hamburg

In diesem Jahr finden die XP-Days in Hamburg statt. Sie werden dieses Jahr zusammen von Andrena und it-agile ausgerichtet. Nähere Infos zum Einreichen von Beiträgen gibt es unter http://www.xpdays.de.

Post bewerten

Korrektur zu GroUnit: JUnit ohne Bytecode

Dierk König wies mich darauf hin, dass mein erstes Argument für GroUnit im Gegensatz zu JUnit so nicht stimmt . Mit groovy.util.AllTestSuite kann man sehr wohl in JUnit auch direkt Groovy-Quellcode testen, ohne diesen vorher nach Bytecode zu compilieren.
Vielen Dank an Dierk für die Klarstellung.

Post bewerten

GroUnit: Unittests mit Groovy

Ursprünglich als reine Fingerübung gedacht, habe ich ein Unittest-Tool für Groovy geschrieben: GroUnit. Das ist nicht weiter schwer, weil Groovy bereits Unterstützung für Unit-Tests mitbringt, allerdings ohne UI. Man kann wg. der nahtlosen Groovy-Java-Integration JUnit auch für Groovy verwenden (siehe z.B. Groovy-Web). Das hat aber ein paar Nachteile:

• Man muss die Groovy-Klassen nach Bytecode compilieren. Für Produktionscode ist das OK, aber während der Entwicklung verlängert es unnötig die Turn-Around-Zeiten.


• Wenn ein Test fehlschlägt, bekommt man im Stack-Trace auch die ganzen Core-Reflection-Geschichten angezeigt, die Groovy im Hintergrund durchführt. Dadurch muss man immer erst mal eine Weile im Stacktrace suchen, bis man das eigentliche Problem überhaupt gefunden hat.


• Seit JUnit 4.0 bringt JUnit keine eigene Benutzungsoberfläche mehr mit. Diese wird von den Entwicklungsumgebungen gestellt. Das ist für Jave wunderbar. Es erzwingt für Groovy aber, dass man eine schwergewichtige Java-Entwicklungsumgebung verwendet. Häufig wäre man mit einem mächtigen Editor besser bedient.

Ich habe versucht, in GroUnit diese Probleme zu adressieren. Sehr weit bin ich in der ersten Version 0.1 sicher noch nicht gekommen. Aber vielleicht engagieren sich noch weitere Leute für GroUnit und es wird noch was richtig Gutes.
Zur GroUnit-Homepage mit Download-Möglichkeit.

Post bewerten

Groovy im Vergleich zu Java am Terminplaner-Beispiel

Ich habe den Terminplaner, den ich als Beispiel für testgetriebene Entwicklung programmiert hatte, von Java auf Groovy migriert. Für den Terminplaner in Java hatte ich testgetrieben ca. 180 Minuten benötigt. Für die Migration nach Groovy habe ich dann ca. 60 Minuten investiert.

Der erste Unterschied der Groovy-Lösung zur Java-Lösung ist der Wegfall der Klasse TeilnahmeStatus (war Enum bei Java). Die Teilnahme-Status-Informationen landen bei Groovy einfach in der Klasse Teilnahme.

Die equals- und compareTo-Methoden sind in Groovy einfacher zu implementieren, weil es für beides eigene Operatoren (== und <=>) gibt, die mit Null-Werten umgehen können.

Bei einer der compareTo-Methoden habe ich bei der Migrationen einen Fehler gefunden, der im Groovy-Code sofort offensichtlich wird. Im Java-Code kann man den Fehler durch die Klammerung beim flüchtigen Lesen übersehen (ist mir beim Schreiben der Java-Lösung ja offensichtlich auch passiert).

Die betroffene Java-Zeile sieht so aus:

int startZeitCompare = startZeit.compareTo(startZeit);

In Groovy wird der Problem sofort offensichtlich:

int startZeitCompare = startZeit <=> startZeit

Es muss natürlich heißen:

int startZeitCompare = startZeit <=> o.startZeit

Die Zahlen nach der Umstellung lesen sich so:

Java-Zahlen

• 5 Fachklassen, 1 Exception-Klasse, 1 Testklasse
  
• 37 Methoden inkl. Konstruktoren + 10 Methoden in Testklasse
  
• 246 LOC operativ + 144 LOC für Testklasse (inkl. Leerzeilen)
  
• 4 For-Schleifen, 4-If-Abfragen
  

Groovy-Zahlen

• 4 Fachklassen, 1 Exception-Klasse, 1 Testklasse
  
• 30 Methoden inkl. Konstruktoren + 9 Methoden in Testklasse
  
• 203 LOC operativ + 123 LOC für Testklasse (inkl. Leerzeilen)
  
• Alle 4 For-Schleifen wurden durch Closures ersetzt, die 4-If-Abfragen blieben bestehen.

Die Code-Ersparnis lässt sich im Wesentlichen auf folgende Groovy-Konzepte zurückführen:

• Closures machen For-Schleifen überflüssig und sind kürzer aufzuschreiben.
  
• Durch Properties werden Getter und Setter überflüssig.
  
• Typecasts entfallen.
  
• In den Tests spart die Uniformität von Arrays und Collections Konvertierungen.

In Groovy habe ich also ca. 80% der LOC (Lines of Code) benötigt, die ich für die Java-Lösung benötigte. Das hört sich erstmal nicht nach einem Quantensprung an. Allerdings muss man bedenken, dass ich „lediglich“ Java durch das doch sehr ähnliche Groovy ersetzt habe. Also hat eine Einzelmaßnahme 20% Code-Ersparnis gebracht. Setzt man das einfach mal naiv mit 20% Kostenersparnis gleich, ist man sehr schnell in Regionen, die interessant erscheinen (die meisten Offshoring-Untersuchungen sprechen von geringeren Einsparungspotenzialen).

Außerdem ist zu bedenken, dass mein Terminplaner-Beispiel die Strukturen in den Vordergrund stellt und die Daten ignoriert (so hat der Benutzer nur seinen Namen und der Termin nur 4 Datenfelder). In einer vollständigen Terminplaner-Anwendung sind viel mehr Datenfelder zu verwalten (MS-Outlook hat für Kontakte so um die 30 Datenfelder). Und gerade wenn es nur um das Halten von Datenfeldern geht, spielt Groovy seinen LoC-Vorteil aus. Die 30 Datenfelder würden in Groovy ca. 10 LoC bedeuten und in Java ca. 130 LoC (beide Zahlen inkl. Leerzeilen).

Nicht zuletzt habe ich die Terminplaner-Anwendung relativ stumpf auf Groovy umgestellt. Ich muss prüfen, ob sich der Code durch fortgeschrittene Groovy-Konzepte noch weiter vereinfachen lässt.

Der Groovy-Code findet sich hier zum Download.

Post bewerten

TDD-2: Testabdeckung bei TDD-Code

Ich habe mal die Testabdeckung bei meinem Terminplaner-Beispiel analysiert, das ich testgetrieben entwickelt habe. Dabei hat sich herausgestellt, dass die Testabdeckung nicht bei 100% lag, wie ich zunächst vermutet hätte, sondern bei gut 80%. Nach einigem Nachdenken und Rumprobieren habe ich entschieden, die Testabdeckung nicht auf 100% zu bringen (was problemlos möglich gewesen wäre).
Die Reports der Testabdeckung sowie die Diskussion der Analyseergebnisse finden sich hier zum Download.

Post bewerten

Software-Architektur: Die vergessene Dimension?

Wenn über Software-Architektur gesprochen wird, werden ihr die solche Funktionen zugeschrieben - sowohl bei klassischer Betrachtung wie auch aus dem Blickwinkel agiler Methoden:

• Rahmen für die Realisierung der funktionalen Anforderungen setzen
  
• Nicht-funktionale Anforderungen wie Wartbarkeit, Robustheit, Sicherheit etc. sichern
  

Dabei wird aus meiner Sicht ein ganz wichtiger Faktor übersehen oder ignoriert. Die Software-Architektur beeinflusst ganz wesentlich die weitere Ausgestaltung des Entwicklungsprozesses und der Projektorganisation. Wie aufwändig die Koordination verschiedenen Entwicklungsteams in einem großen Projekt wird, ist ganz wesentlich von der gewählten Architektur bestimmt.

Ich habe inzwischen eine ganze Reihe von Projekten erlebt, in denen die Architektur gewählt wurde, ohne auf den Entwicklungsprozess und die Projektorganisation zu achten. Die Konsequenz war immer eine sehr unangenehme Beschränkung der Möglichkeiten im Projektverlauf. In einem Fall hätte man ein schlecht laufendes Projekt retten können, wenn man die Entwicklermannschaft von 8 auf 20 Entwickler hätte erhöhen können. Die Architektur hat das aber verhindert. In einem anderen Fall hat die gewählte Architektur erzwungen, dass man ganz genau vorher planen musste, wer was tun muss. Als der Umstieg auf eine agilere, reaktivere Vorgehensweise mit kurzen Releasezyklen anstand, war das faktisch nicht möglich.

Aus meiner Sicht muss bei der Definition und Weiterentwicklung der Architektur jeweils auch berücksichtigt werden, welche Beschränkungen und Möglichkeiten die Architektur für den Entwicklungsprozess und die Projektorganisation mit sich bringt. Und das bedeutet für viele Software-Architekten eine ganz neue zusätzliche Dimension in ihrer Tätigkeit.

Post bewerten

TDD-1: Testgetriebene Entwicklung am Beispiel

Ich habe zum Spaß mal zwei Sessions zu je 90 Minuten am Beispiel "Terminplaner" testgetrieben programmiert (Java und JUnit). Protokoll und Code gibt es hier zum Download. Vielleicht hilft es ja bereits in der jetzigen Form dem einen oder anderen beim Verständnis von TDD?

Richtig interessant wird es aber erst später. Dann will ich verschiedene Aspekte des Beispiel-Codes und des Vorgehens beleuchten.

Zwei interessante Beobachtungen kann man aber bereits jetzt machen:

1. Ich war beim Programmieren wg. der fortgeschrittenen Zeit immer wieder mal abgelenkt. Das testgetriebene Vorgehen hat mich immer wieder schnell auf den richtigen Weg gebracht.
   
2. Es gibt nur eine Testklasse für 5 Klassen. Man hätte auch Tests für die einzelnen Klassen schreiben können. Das schien mir aber immer doppelte Tests zu implizieren.

Post bewerten

Revenge of the Nerds

Durch Dierk König bin ich auf einen Artikel von Paul Graham aus dem Jahr 2002 gestoßen: Revenge of the Nerds. Dort argumentiert Paul Graham, dass die Programmiersprachen sich mit der Zeit immer weiter an LISP angenähert haben, allerdings immer noch nicht die Ausdruckskraft von LISP erreicht haben (das ist schon erstaunlich, wenn man bedenkt, dass LISP bereits 1958 erfunden wurde). Außerdem behauptet er, dass die Programmiersprache eine große Rolle bei der Produktivität spielt. Die zweite These erscheint mir sofort plausibel und passt auch mit den gängigen Untersuchungen zur Produktivität in Softwareprojekten zusammen.
Die erste These war mir neu, scheint mir aber ebenso plausibel. Sie hat mich dazu animiert, nochmal an meine Studienzeit zurückzudenken, in der LISP-Programmierung zur Grundausbildung gehörte. Und tatsächlich: Die Programmiersprachen sind immer LISP-ähnlicher geworden und haben LISP immer noch nicht erreicht. Und ich trauere irgendwie doch immer mal wieder der Art und Weise nach, wie man LISP programmieren konnte. Es ist doch schon erstaunlich, dass man mit LISP bereits die Möglichkeit hatte, sich für sein Problem eine adäquate Sprache zu definieren und dann das Problem in dieser Sprache zu lösen. Modern ausgedrückt ist in LISP von Anfang an die Möglichkeit enthalten gewesen, DSLs (Domain Specific Languages) zu definieren. Smalltalk, Ruby, Python und Groovy sind trotz ihrer Dynamik nicht so ausdrucksstark geworden. Aber viel fehlt nicht mehr. Warten wir noch ein oder zwei Programmiersprachengenerationen ab und wir programmieren alle in LISP. Das heißt dann vielleicht etwas anders und hat vielleicht ein leicht andere Syntax, aber konzeptuell wird es LISP sein - wenn Paul Graham Recht hat. Irgendwie freue ich mich darauf und hoffe, dass ich selbst dann noch zum programmierenden Volk gehöre.

Post bewerten

Skype-Diskussion Java-Magazin: Technology First

Im Java-Magazin 04/2006 wurde ein Artikel mit einer Skype-Diskussion veröffentlicht, an der ich auch beteiligt war. In der Diskussion ging es um die Frage, warum wir als Softwareentwickler die vielen tollen Techniken so selten einsetzen, obwohl wir sie lange kennen (Bsp.: Test-First, Entwurfsmuster etc.).
Vor kurzem wurde ich von einem Leser des Artikels gefragt, ob die Diskussion tatsächlich so stattgefunden hat oder ob sie erfunden wurde. Die Diskussion hat tatsächlich stattgefunden und das Protokoll wurde lediglich etwas gekürzt und um Rechtschreib- und Grammatikfehler bereinigt.
Der Artikel als PDF findet sich hier.

Post bewerten

Ruby on Rails vs. ???

Zur Zeit ist Ruby on Rails in aller Munde. Von vielen wird es für die Technologie der Zukunft gehalten. Aber gegen wen ist Ruby on Rails eigentlich positioniert?

Ich bin kein Experte für Skriptsprachen a la PHP oder Perl, habe aber das Gefühl, dass Ruby on Rails gegenüber diesen Sprachen keinen wahnsinnig großen Fortschritt darstellt - klar ist die Sprache Ruby cooler, aber kann man dadurch seine Webanwendungen soviel schneller schreiben?

Bliebe als Konkurrent also Java. Dort dürfte Ruby on Rails nur für einen kleinen Teil der existierenden Java-Kunden interessant sein. Wer sich strategisch für Websphere als Application-Server entscheidet, kann dann schlecht wichtige Anwendungen in Ruby in einer anderen Ablaufumgebung entwickeln. Bleiben also die Kunden übrig, die heute Java-Projekte starten und die sich keine strategischen Gedanken über Transaktionsmonitore oder Application-Server machen.

Wenn sich allerdings Groovy und Grails als Java-Technologien verbreiten, ist das dann für die existierenden Java-Kunden nicht viel attraktiver als Ruby on Rails? Immerhin lassen sich ihre existierenden Projekte leicht mit Groovy integrieren.

Ich finde Ruby als Sprache cool und Ruby on Rails für eine bestimmte Art von Anwendungen auch. Allerdings befürchte ich, dass der Coolness-Faktor nicht ausreicht, um eine nennenswerte Verbreitung zu finden. Die allermeisten Entwickler suchen sich ihre Programmiersprache schließlich nicht selbst aus. Und Manager sind bekanntermaßen relativ immun gegen Coolness...

Post bewerten

Hibernate-Buch erschienen

Ich habe soeben ein Belegexemplar des Buches "Hibernate - Persistenz in Java-Systemen mit Hibernate 3" vom dpunkt-Verlag erhalten, dass ich zusammen mit Robert Beeger, Arno Haase und Sebastian Sanitz geschrieben habe.

Das Buch ist bei Amazon noch im Status "noch nicht erschienen", aber das wird sich in den nächsten Tagen ändern.

Am 8. Mai 2006 halten wir auf der JAX in Wiesbaden einen ganztägigen Power-Workshop zu Hibernate 3.

Post bewerten