Mittwoch, 31. Oktober 2007

Erfahrungsaustausch

Gestern hab' ich mich mit einem Bekannten unterhalten, der Web-Projekte leitet, eigentlich aber aus der Ecke der Software Entwickler kommt. Die Probleme, Erkenntnisse und Eskalationen in Bezug auf Zeit und Budget in seinen Projekten lassen mich nur Schmunzeln ... "go agile" denke ich und versuche ihn davon zu überzeugen.

Ich:
Wie sehen denn die Rahmenbedingungen bei den Projekte aus?

Er:
Zeit, Budget und Ressourcen werden vorgeben. Die technische Lösung hat damit bereits Nebenbedingungen, die sich bei der Realisierung zeigen.

Ich:
Du hast also keinen Einfluss auf die Resourcenverteilung in deinen Projekten. Wie hoch ist denn die Fluktuation während des Projekts?

Er:
Ja, das ist immer problematisch. Die Ressourcenzuteilung ist nicht garantiert. Es werden oft Leute abgezogen, für die man nicht immer einen adäquaten Ersatz bekommt. Sobald jemand als freie Ressourcen ausgemacht wird, bekommt man wieder ein neues Teammitglied.

Ich:
Wie erfolgreich sind den diese Projekte?

Er:
Sehr erfolgreich. Wir haben nur selten Budget oder Zeitüberschreitungen bis zum Projektabschluss.


Ok, seltsam. Noch ein paar Fragen und ich war am "Kern". Er eröffnet mir, dass bei vielen Projekten dann nach dem Abschluss erst die grosse Überraschung kommt. Der Kunde hat dann oft noch Change Requests, die allerdings eher Bugs sind und möchte nachträglich die Spezifikation ändern. Da man den Kunden halten möchte, arbeitet man auch nach Projektabschluss noch am Projekt, ohne Aufwandsverrechnung und oft nur mit halbem Team. Was am Ende dann rauskommt, möchte keiner mehr Warten, meint er ...

Nochmal: "go agile"
Ich würde mal unterstellen, dass man das bei agilem Vorgehen besser hinbekommt!

Dienstag, 30. Oktober 2007

WebTest vs Selenium: WebTest gewinnt 13 zu 5

Am 29.10.07 wurde auf TheServerSide.com ein Artikel gepostet, der sich mit Tools zum automatisierten Testen von WebApplikationen auseinander setzt - es wurde WebTest (Canoo) mit Selenium (OpenQA) verglichen.

Insbesondere das aufzeichnen von Tests ist offensichtlich ein Bedürfnis, z.B. mit dem WebTest Recorder von Canoo. Ausserdem wird Element von PragmaticQA angesprochen, was auf Ruby & Watir basiert.

Andere sprechen davon, JUnit performanter zu machen, indem man auf Grid Computing setzt.

Ich setzte auf Selenium, wobei die Testbarkeit von AJAX Anwendung sich als schwierig erweist. Der Selenium IDE Recorder ist hier etwas schwach ...

Mittwoch, 24. Oktober 2007

CruiseControl im Mac Menü

Mit CCMenu kann man bei einem Mac die CruiceControl Server Task/Results in der Mac Menüleiste darstellen.

Erik Doernenburg von ThoughtWorks schreibt mit seinem Team auf Sourceforge über CCMenu.

CCMenu wurden auf der CITCON (Continuous Integration and Testing Conference) 2007 in Brüssel erstmals vorgestellt.

Noch 2 Tage, dann gibts Leopard und dann .....

... gibts bald ein Mac!

Dienstag, 23. Oktober 2007

Ubuntu upgraded

Gutsy Gibbon 7.10, die neueste Version von Ubuntu ist installiert.

Der Update Manger hat mir heute morgen direkt angeboten, meine Version 7.04 Feisty Fawn abzugraden - ein, zwei Klicks - root Password eingeben und ca. 2.5h warten, dann ist Gutsy Gibbon installiert! Ubuntu läuft bei mir auf einem Notebook von Dell - D620 Latitude.

Eine Update Guide in englisch gibts hier, das deutsche Ubuntu Forum gibt sicher auch Auskunft bei Problemen - aber es gibt ja keine Probleme, nur anspruchsvolle Aufgaben ,-)

Go and get it!

Nach dem Restart und dem Login gab's dann noch ne böse Überraschung, die mich dann einen Tag beschäftigt hat - "failed to initialize HAL", ein Bug, der bekannt ist .....

Montag, 22. Oktober 2007

Working in Project Zero

Da Project Zero offensichtlich agile entwickelt wird, habe ich mal nachgefragt:

Man geht iterativ vor, pro Iteration wird ein Milestone entwickelt. Einen Milestone gibt es alle 6 Wochen, das entspricht einer Interation. Aktuell arbeitet man gerade am Milestone 2 (M2). Backlog, ProductOwner, Teammembers und Kommunikation wird Bugzilla eingesetzt.

Am kommenden Mittwoch, 24.10.07 wird ein Branch gezogen, der dann bis Freitag 26.10.07 in den Test geht, also nur zwei Tage. Demnach wird sicher automatisiert getestet. Ich werde weiter fragen ...

ProjectZero publiziert den gesamten agile Prozess in einem öffentlichen Kalendar, den man mit Goolge Calendar lesen kann. Ausserdem gibts drei interessante Blogs:

Google grouplet

Julie Bick schreibt unter der Rubrik “Preoccupations” Artikel für die New York Times. Gestern, 21. Oktober hat Bharat Mediratta von Goolge in einem Interview Julie Bick darüber berichtet, wie man bei Google den Engineers 20% der Zeit überlässt, persönlichen Interessen nachzugehen, die nicht unbedingt von Interesse für das Unternehmen sind, um eventuell etwas Neues zu entwicklen.

Bharat Mediratta berichtet, dass Gmail, Google News und google shuttle busses aus eben diesen 20% als Idee entwickelt worden sind und umgesetzt wurden. Die Personen hinter solchen Ideen so motiviert, dass man nicht um Personal zur Realisierung "werben" muss, wenn man eine neue Geschäftsidee präsentiert.

Da nicht unmittelbar alle 20% Ideen zu einem Produkt führen und die restliche Zeit für die "normale" Arbeit verbleiben sollte, setzt Google auf "grouplets" - ein Board quer durch die gesamte Organisation.

Grouplets haben kein Budget und keine Entscheidungskompetenz. Sie haben ein paar Leute die einer Idee nachgehen und bereit sind, das Unternehmen mit der Idee zu überzeugen und mitzureissen.

Freitag, 19. Oktober 2007

Agile und Offshore - geht das?

Neben content-driven Community Portalen, Blogs, Photo Sharing, Syndication Feeds, MashUps und Google Tools wie GMail, Picasa, Docs and Spreadsheets und vielem mehr hat sich beim Web 2.0 Hype noch etwas gravierent geändert -

die Geschwindigkeit!

Plötzlich "lebt" man RAD (rapid application development). Buzzword von heute, wie Time-to-market, Feature-driven, Beta, Usability, desktop-behavior, rich interface etc ... endlich! Aus der Technologie Ecke gibts die zugehörigen Tools wie Rails, Groovy und AJAX - alles nach dem Motto:
"Whatever tools are necessary, we provide them, and then get the hell out of the way of the developers so that they can do their jobs."
Werner Vogel, CTO amazon.com
Vorbei die Zeit der endlosen Spezifikationen und Pflichtenhefte, vorbei endlose und kostspielige Analyse Phasen, nie wieder "Sorry, it's much to late to change your mind" ......

... und: Offshore ade!

Selbstorgansiert, selbstregulierend, hoch motiviert, interdisziplinär, kommunikativ, flexibel, schnell, iterativ und mit einer nie gekannten Portion job-enrichment arbeiten Teams von 3-8 Leuten an der Realisierung einer Applikation.

Während immer mehr Firmen bei der schnellen Umsetzung ihrer Internetstrategien auf agile setzen, bleiben andere ihrer Strategie treu und setzen auf Offshore.

Rein monetär betrachtet mag das zunächst günstiger sein, nur kann man es sich leisten, der Konkurenz einen Vorsprung im Internet zu gewähren?

Donnerstag, 18. Oktober 2007

Ubnuntu 7.10 ist da! jetzt auch auf Dell


Der Hersteller Dell möchte noch dieses Jahr das neue Betriebssystem Ubuntu 7.10 auf seinen PC's in den Handel bringen.

"We will offer Ubuntu 7.10 preinstalled on our systems soon," said Anne Camden of Dell corporate communications, in an e-mail interview. "For customers who are interested in updating their existing Ubuntu systems, we advise them to visit the Ubuntu 7.10 page on our wiki, which will go live [Oct. 18] after the official launch."


Die ganze Geschichte lesen ...

Mittwoch, 17. Oktober 2007

Best Practice: TDD und JSF managed beans bei agilem Vorgehen

"Änderungen werden erwartet, sie sind willkommen!" Das ist eine zentraler Gedanke bei agilem Vorgehen.

Was aber bedeutet das für die Vorgehensweise bei der Software Entwicklung? TDD! Am Beispiel von JSF möchte ich kurz zeigen, welcher klassische Fehler immer wieder gemacht wird, welche Konsequenzen daraus enstehen und wie man es besser machen kann. Im folgenden geht es um dieses Beispiel:

public class ChangePasswordBean
{
   private String password, passwordRepeat;

   public String doChangePassword() {
      // ...
   }

   public String getPassword() {
      return password;
   }

   public void setPassword(String password) {
      this.password = password;
   }

   public String getPasswordRepeat() {
      return passwordRepeat;
   }

   public void setPasswordRepeat(String passwordRepeat) {
      this.passwordRepeat = passwordRepeat;
   }
}

1# Managed Bean's und deren Abhängigkeiten

Bei JSF werden properties und action's in Managed Bean's zusammengefasst. Of braucht man innerhalb der action Methoden eine Reference zu einem Manager oder einem Service, dem die Verarbeitung delegiert wird. Das ist nicht problematisch, aber wie macht man das, damit das Managed Bean auch ohne Container testbar bleibt?

Nicht gut ist das hier: (faces-config.xml)

<managed-bean>
   <managed-bean-name>changePasswordBean</managed-bean-name>
   <managed-bean-class>example.ChangePasswordBean</managed-bean-class>
   <managed-bean-scope>request</managed-bean-scope>
</managed-bean>

... in Verbindung mit folgender Implementierung:

public String doChangePassword() {
   UserManager.getInstance().changePassword(uid, password);
}

Besser ist, den UserManager per Dependency Injection zu setzen und dann zur Verarbeitung die bean-interne Referenz zu verwenden:

<managed-bean>
   <managed-bean-name>changePasswordBean</managed-bean-name>
   <managed-bean-class>example.ChangePasswordBean</managed-bean-class>
   <managed-bean-scope>request</managed-bean-scope>
   <managed-property>
      <property-name>userManager</property-name>
      <value>#{userManager}</value>
   </managed-property>
</managed-bean>

... in Verbindung mit folgender Implementierung:

public String doChangePassword() {
   this.userManager.changePassword(uid, password);
}

Somit kann man eine Unit Test statt einem Integrationstest schreiben. Der UserManager in diesem Beispiel kann mittels JMock im Unit Test injected werden um State und Behavior des ChangePasswordBean sicherzustellen.

The Future of Software Development



Alex Iskold, einer der Writer bei Read/WriteWeb, schreibt in seinem Artikel "The Future of Software Development" warum der Wasserfall Ansatz bei Software Entwicklungsprojekten nicht funktioniert und wie agile Vorgehensweise die Entwicklung belebt, warum Umdenken Sinn macht und wie man generell mittels Testing den wechselnden Heraus- und Anforderungen bei agilem Vorgehen gerecht wird.

Danke an dieser Stelle an Markus, der mich auf diesen interessanten Artikel hingewiesen hat ...

Montag, 15. Oktober 2007

InfoQ: Werner Vogels über Availability & Consistency

Werner Vogels, CTO Amazon.com, über die Prinzipien einer skalierbaren Service Landschaft, Architektur ein solchen, klassische Probleme wie Transaktionen und State Management und nicht zuletzt Testing ...

Interessant ist an der Stelle, dass Vogels auf die Vorgehensweise eingeht. Er erwähnt, dass es bei Amazon eine 2 Pizza Regel gibt:

Ein Team ist maximal so gross, dass man es mit 2 Pizzen ernähren kann. Wenn das nicht gegeben ist, dann ist das Team zu gross.

Services bei Amazon werden auf teambasis von 8 bis 12 Leuten entwickelt.

Der SOA Ansatz bei Amazon - agile?

Am 28./29. September 2007 habe ich auf dem T.Camp der namics ag einen Vortrag zum Thema SOA gehalten. Primär ging es darum zu erläutern, wie das Buzzword SOA zu vestehen ist, wie sich SOA entwickelt hat, was man heute darunter versteht und wie SOA sich langsam von einem technischen zu einem business Thema verlagert, Stichwort JBI, der zweite Teil meines Vortrags.

Im Anschluss an den Vortrag wurde ich von Tristian Woerth, ein Ruby on Rails Spezialist aus der Schweiz, angesprochen - er hat mich gefragt, ob ich den service-orientierten Ansatz von Amazon kenne ...

Zu meiner Schande, kannt ich ihn nicht. Heute, gut 3 Wochen später und um einige Erkenntnisse reicher habe ich mit Amazon beschäftigt - sehr interessant, sowohl technisch als auch methodisch.

Interessant in diesem Zusammenhang fand ich diese Aussage von Werner Vogels, CTO Amazon.com:

"There is another lesson here: Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. ... This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service. "

und

"Whatever tools are necessary, we provide them, and then get the hell out of the way of the developers so that they can do their jobs."


Klingt nach agile, wird auch agile sein -ich weiss es leider nicht! Würd' mich aber interessieren, besonders weil Herr Vogels die Problematik des testens anspricht - sicher nicht trivial bei einer verteilten Service Landschaft ...

Mittwoch, 10. Oktober 2007

Das Scrum Team

Zentrales Element für den Erfolg bei agiler Vorgehensweise in der Softwarentwicklung ist das Team - es ist selbstorganisierend und bezüglich Disziplin selbstregulierend.

Zweifellos braucht man dafür das "richtige" Team. Agile kann und wird nur funktionieren, wenn jeder im Team mit den agilen Prinzipien vertraut ist, diese achtet, sie stehts befolgt und weiterentwickelt.

Kritik ist gut, zu viel davon ist kontra-produktiv!

Wenn man es schaft, die Skepsis und Kritik in Neugier und Verbesserung zu überführen, dann hat man ein Team!

Nebenbei glaube ich persönlich, dass es unerlässlich ist, die *besten* im Team zu haben. Man mag sich vorstellen, dass ein Team wenn es dem agilen Manifest folgt noch lange nicht erfolgreich ist - man braucht auch das Know-How zur Umsetzung der eigentlichen Aufgabe. Ich verstehe die Projekt Methode als solche als Meta Problem. Eigentlich geht es doch darum, das Problem des Kunden/Auftraggebers zu lösen - dafür nur die *Besten*...

Maven 2 Einführung

Immer wieder ist man bei Softwarentwicklung mit der Tatsache konfrontiert, dass man sich 70% der Zeit mit Infrastruktur, Entwicklungsumgebung, Applikationsserver und Co. beschäftigt. Man investiert nur 30% der Zeit für die Lösung des eigentlichen Business-Problems. Das eingesetzte Projekt-Budget fliesst demnach mehrheitlich in Dinge, die keinen Mehrwert und keinen direkten ROI zur Folge haben.

Um einen Teil der Infrastruktur-Problem zu minimieren wurde Maven2 entwickelt - ein Build und Projekt-Management Werkzeug.

Die Top 5 Punkte, die für Maven2 sprechen:
  • Einfaches, einheitliches Projekt-Setup, IDE unabhängig
  • keine JAR Files mehr im Source Code Repo
  • keine Ant-Scripts mehr schreiben
  • Einfaches Dependency Management (externe JAR Abhängigkeiten)
  • zentrales Company-Repository zur Wiedervendung von Komponenten
Ein Maven2 Projekt hat man in weniger als 5 Minuten eingerichtet und zwar mit compile, clean, package, test etc. ohne dass mein eine Zeile Ant-Script geschrieben hat. Maven2 basiert auf einen POM.xml File, in welchem das Projekt definiert wird. Durch dieses POM.xml wird die Umgebnung für Maven2 eingerichtet.

Ein sehr gutes Buch (PDF) zum Thema Maven2 ist "Better Builds with Maven" (DevZuz), sehr emfpfehlenswert!

Dienstag, 9. Oktober 2007

"State of Agile Development" Umrageergebnisse von VisionOne





Zum zweiten Mal hat VisionOne eine Umfrage in 71 Ländern zum Thema "State of Agile Development" durchgeführt, an der 1.700 Unternehmen teilgenommen haben.

Ein paar Highlights:
  • agile Teams werden grösser und sind häufiger auch physisch verteilter
    • 31% der Umfrageteilnehmer berichten von agilen Teams mit > 250 Mitglider
    • 74% er Umfrageteilnehmer berichten von agilen Teams mit > 20 Mitglider
  • agile Entwicklung liefert aussagekräftige und messbare Ergebnisse für das Business
... alle Umfrageergebnisse

Lotus Notes 8 auf Ubuntu installieren

Lotus Notes 8 auf Ubuntu zu installieren ist vergleichsweise zu früheren Version von Lotus Notes recht einfach.

Zunächst mal runterladen (C13NCEN.tar), dann:

me@ubuntu:/tmp$ sudo tar xvf C13NCEN.tar
me@ubuntu:/tmp$ sudo C13NCEN/setup.sh

Hinweis: Es sollten vorher die Desktop Effekte ausgeschalten werden, da sonst das JAVA Intallationswindow von Lotus Notes nicht richtig dargestellt wird!

Installation laufen lassen und anschliessend X server mit Ctrl+Alt+Backspace restarten, damit Lotus Notes im Menü (Gnome/KDE) erscheint.

Hinweis: Der Launcher konnte nach meiner Installation nicht ausgeführt werden, da die Rechte nicht korrekt gesetzt waren:

sudo chmod +x /opt/ibm/lotus/notes/notes

Im Home-Verzeichnis gibts nach der Installation ein "lotus" Verzeichnis: Löschen oder Umbennenen. Lotus erzeugt beim Starten ein gleichnamiges Verzeichnis "lotus" was dann zu Problemen führt.

So, jetzt der erste Start von Lotus Notes 8 auf Ubuntu 7.04: Failed to login CLFRJ0010E: Notes initialization failed!

Im Notes/Domino 8 Forum gibts Abhilfe ;-)

Gute Anleitungen von Lotus Notes 8 auf Ubuntu in EN gibts noch hier:
Viel Spass.

Ubuntu 7.04 auf Dell Latitude D620 installieren




Dank Wubi ist es einfach und schnell möglich, Ubuntu 7.04 neben Windows auf einer Maschine zu installieren. Nach gut 1.5h runterladen der Pakete durch die Installationsroutine ist das System auch schon betriebsbereit - booten und fertig.

Doch was ist das?! Der Widescreen 1440x900 des Dell Latitude D620 wird nur mit 1024x768 angefahren. Auch ein erneutes XServer konfigurieren hilft nicht:
sudo dpkg-reconfigure xserver-xorg.

Mit Hilfe von Google ist auch das Problem schnell gelöst - 915resolution muss nachinstalliert werden:
sudo apt-get install 915resolution

Anschliessend X Server neu staten (Ctrl+Alt+Backspace) und 1440x900 Widescreen Auflösung einstellen, fertig ;-)

Die nächste Herausforderung steht schon an: Lotus Notes 8 (GOLD) auf Ubuntu installieren ...

Donnerstag, 4. Oktober 2007

Was heisst agiles Vorgehen?

Nach dem agilen Manifest gilt das Prinzip, dass man dem Kunden in regelmässigen Intervallen funktionsfähige, getestet, dokumentierte und brauchbare Artefakte liefert, die einen Mehrwert darstellen.

Wie kommt man von einem klassischen Wasserfall zum agilen Projekt?
Ein Praxisbericht: Schritt 1: man macht den Wasserfall zunächst iterativ.

Bei einem interativen Wasserfall werden pro Iteration Artefakte erarbeitet, die in der kommenden Iteration weiterverarbeitet oder verfeinert werden (Bild oben). Damit bleiben alle Nachteile von phasen- orientiertem Projektvorgehen erhalten: Abkapseln von Anaytikern, Kunden, Testern und Entwicklern sowie Behinderung der direkten Kommunikation aller Beteiligten. (A=Analyse,D=Design,P=Produktion,T=Test)

Da man mit dem iterativen Wasserfall jedoch keine funtionstüchtigen Artefakte mit einem Mehrwert für den Kunden liefert, kommt man zwangsläufig zum Schritt 2: der iterative Mini-Wasserfall (Bild unten).

Um dem agilen Manifest gerecht zu werden und die klassische Vorgehensweise beizubehalten, macht man alle Phasen pro Iteration.
Auch hier gewinnt man nicht viel, denn erfahrungsgemäss ist die Zeit am Ende einer Iteration sehr knapp und Testing fast unmöglich. Dazu kommt, dass die Teammitglieder so noch immer entkoppelt arbeiten und wichtige Kommunikation ausbleibt.

Untersuchen Sie genau Ihre Vorgehensweise. Finden Sie sich teilweise in diesen Aussagen wieder, dann haben Sie kein agiles Vorgehen!

Grundsätze für agile Projekte

Oft stehen im Zusammenhang mit agile Software Entwicklung viele Fehlannahmen im Raum. 5 Punkte, wie man agile Grundsätze interpretieren sollte.

Agile heisst nicht, es herrscht Chaos und Anarchie, vielmehr setzt man Eigenverantwortung und Selbstdisziplin jedes Teammitglieds voraus, gepaart mit Selbstregulierung des gesamten Teams.

Planung ist bei agiler Vorgehensweise keine Aktivität bei Projektbeginn, sondern ein Dauerzustand. Man setzt sich kontinuierlich mit Zielen und deren Erreichbarkeit ausseinander, passt diese der Realität an, um mit den verfügbaren Ressourcen, Budget und Zeit das bestmögliche Ziel zu erreichen.

Es wird dokumentiert, was wichtig ist, nicht Dokumentation des Prozesses wegen. Man spricht von "lebender" Doku, da sich gesamte Dokumenation während des Projekts Veränderung erfährt.

Aus Erfahrungen lernen und diese einfliessen lassen. Prozesse/Abläufe/Wege verbessern, weglassen oder optimieren, nicht alles präzise und exakt immer wieder aufs Neue wiederholen und hier und da was weglassen, um das ganze repetierbar zu machen.

Man setzt konstante Veränderung bei agilen Methodiken voraus. Die Methode ist nur ein Rahmenwerk - jedes Team, jede Organisation und jedes Projekt hat unterschiedliche Bedingungen, die es zu adaptieren gilt.

Mittwoch, 3. Oktober 2007

Braucht ein agiles Team einen agilen Kunden?

Auch bei einem agilen Projekt gibt es einen Kunden, in aller Regel is das der Product Owner. Wie agile muss der sein?

Der Kunde in einem agilen Team hat wichtige Aufgaben, ober will oder nicht! Dazu gehören:
  • schnelles Feedback liefern und schnell Entscheidungen treffen
  • fortlaufend Projekt-Situation beurteilen und ggf. Korrekturen vornehmen
  • Realität im Auge behalten: Markt, Kunden und Trends nicht ignorieren
  • Team vertrauen
... kurz: er gibt die Richtung an!

Wie man sieht, ist der Kunde bei einem agilen Projekt weitaus stärker gefordert als bei traditionellen Entwicklungsprozessen. Wie wichtig die Rolle des Kunden letztendlich ist, kann man gut am Beispiel einer Rudermannschaft versinnbildlichen: der Steuerman ist der Kunde - und der ist der einzige, der in Fahrtrichtung blickt, er bringt das Boot ins Ziel ....

ProjectZero - Zero complexity. Zero overhead. Zero obstacles

Project Zero ist ein einfache Entwicklungs- umgebung mit Applikationserver (WAD CE), Dependency Management, Packaging, Installing, Deployment und Laufzeitumgebung zur Erstellung ein RESTful Applikation nach CRUD Prinzipien. Das ganze basiert auf JAVA plus Groovy bzw. PHP als Scripting Sprachen und wird in Eclipse als Plug-In installiert.

Hinter Project Zero steckt die IBM, die Project Zero zunächst als Incubator Projekt mit dem Fokus auf agile development für zukünftige Generationen von dynamischen Webprojekten vorangetrieben hat. Project Zero ist kein open source Projekt, sondern IBM nennt das Community-Driven Commercial Development - will heissen: jeder kann mitentwickeln - IBM hat die alleinigen Vertriebs- udn Vermarktungsrechte.

Die Community organisiert sich durch Foren, Blogs und einen public Calendar.

Zero complexity. Zero overhead. Zero obstacles - Klingt vielversprechend!

Spring-On-Rails: RESTfull Applikationen mit Spring


Spring-on-Rails Release 1.0 ist seit dem 01.Oktober auf Google Code verfügbar steht unter der Apache License 2.0.
Spring-on-Rails ist ein J2EE Framework für RAD, rapid application development und damit in der agilen Entwicklungs-Szene zu hause. Mit Spring-On-Rails kann man auf einfache Weise RESTfull Applikationen bauen (CRUD), wobei man mit Spring-On-Rails trotz allem eine J2EE Applikation baut - ohne Scripting. Das ganz basiert auf dem Sprint Framework.

Spring-on-Rails wird auf TheServerSide.com heftig kritisiert, es verdiene den Namen "Spring" und "Rails" nicht und vieles mehr...