J and I and Me
2005-11-29
 
Spring Fitness Integration

Mit Spring arbeite ich ja nun schon einige Zeit. Ein anderes interessantes Tool ist Fitnesse. Mit diesem Werkzeug kann man Akzeptanztests in einem Wiki ablegen hinter denen dann Java Code steht, der diese ausführt. Die Akzeptanztests werden dabei als Tabellen dargestellt, so dass man durchaus auch Fachbereichen die Formulierung der Tests zumuten kann. Nun bietet es sich natürlich an, den ausführenden Java Code mit Spring zu konfigurieren. Und genau das habe ich gebaut. Es ist ingesamt recht trivial, da Spring schon entsprechende Funktionalitäten anbietet, um JUnit Tests mit Abhängigkeiten zu Spring-Beans zu versehen. Wer es ausprobieren will, findet es hier.
 
Bookmark and Share
2005-11-24
 
Annotationen und Aspekte

Auf TheServerSide ist hier gerade eine Diskussion in Gange, bei der es um Annotationen geht. Gavin King (der Hibernate Erfinder) mahnt an, dass Annotationen deutlich umfangreichere Möglichkeiten zur Überprüfung und Validierung haben sollten.

An dieser Stelle habe ich das Gefühl, dass Annotationen übertrieben werden. Sie sollen nur Methoden, Klassen usw. mit Informationen versehen. Schon die Idee, dass es direkt eine Konfiguration des Elements ist, ist eher weniger richtig (siehe auch den Blog-Eintrag zu Adrian Colyers Vortrag auf der WJAX). Die Frage ist, wie man die Semantik abbildet. Da bietet sich AspectJ an.

Wenn man nun dieses Werkzeug verwendet, kann man die Aktivierung eines Aspekts nicht nur von einer Annotation abhängig machen, sondern auch noch zusätzliche Einschränkungen vornehmen z.B. anhand ders Klassennahmens oder des Methodennamens, der Parameter usw. Eben die komplette Mächtigkeit der AspectJ Pointcut Sprache. Und man kann auch Fehler bei der Kompilierung anzeigen, wenn der Aspekt an der falschen Stelle ansetzt.

Mal sehen, vielleich verwendet ja auch die JBoss Group in Hibernate eines Tages AspectJ...
 
Bookmark and Share
2005-11-21
 
Adrian Colyer über Aspekte, Spring usw.

Adrian Colyer ist als AspectJ Projekt-Leiter einer der Leute, die AOP wirklich gut verstehen. Außerdem hat er gerade neu bei Interface21 angefangen (als Chief Scientist) und durfte nun auf der WJAX präsentieren.

Spannend war schon der Einstieg mit großen Namen wir Parna oder Dijkstra. Interessante auch der Gedanke des Rise and Fall and Rise of OOP. Der Fall natürlich Java EE und der zweite Rise Spring.

Das erste inhaltliche Konzept, das ich interessant fand, war die Idee, einen dünnen Aspekt mit einer Strategy zu kombinieren, die dann die wirkliche Funktionalität implementiert. Dadurch kann man dann das, was in dem Aspekt gemacht werden soll, durch Dependency Injection definieren: Man verwendet einfach ein andere Objekt.

Seine Sicht auf Annotationen ist, dass sie Informationen über eine Methoden oder Klasse geben und keine kein direkten Befehle sein sollten. Gut ist also @Transaction, schlecht @StartTransaction. Gut ist auch @ReadOnly, schlecht wiederum @AcquireReadLock.

Ein interessantes technisches Problem, dem er sich dann widmete, sind POJOs, die zwar von der Anwendung erzeugt werden, aber durch Dependency Injection konfiguriert werden sollen. Ein Beispiel sind Domänen-Objekte wie Kunde, die dann eine Referenz auf einen Dienst bekommen sollen. Dazu ist eine Trennung zwischen Konfiguration und Erzeugung notwendig. Das bedeutet, dass die Objekte einfach mit new erzeugt werden, aber dann durch Spring konfiguriert werden. Dazu ist dann eine Annotation wie @SpringConfigured("KundeBean") notwendig. Der Parameter ist der Name der Spring-Bean, die dann in der Konfiguration gesucht wird. Default ist der Klassenname. Zur Implementierung dieses Features ist ein recht einfacher AspectJ Aspekt notwendig, der auf das Erzeugen von Objekten reagiert.

Obwohl dies ein cooles Feature ist, bin ich noch nicht sicher, ob es wirklich zielführend ist, da die Domänen-Objekte meiner Meinung nach nicht unbedingt die Services kennen sollten. Spätestens in einem Szenario, wo man ein solcher Objekt von einem Server auf einen Client übertragen will, hat man da ein Problem.

Soweit also die Möglichkeit, Annotationen zur Markierung für Aspekte zu verwenden. Eine andere interessante Möglichkeit, die Adrian noch zeigte, ist es, einen Aspekt dazu zu verwenden, Annotationen zu bestehendem Code hinzuzufügen. Dadurch kann man in der AspectJ Pointcut Sprache definieren, wo bestimmte Annotationen gesetzt sein sollen. Zusammen z.B. mit den Annotationen für EJB 3 könnte das eine ganz coole Vereinfachung sein...
 
Bookmark and Share
 
Spring auf der WJAX

Der Einfluss von Spring auf die WJAX war kaum zu übersehen. Für mich fing es mit einem Interview mit Rod Johnson und Adrian Colyer für das Java Magazin an. Dabei war für mich vor allem interessante, dass EJB 3 sehr deutlich als keine ernsthafte Konkurrenz für Spring wahrgenommen wird. Teilweise ist die Marke und der Begriff "EJB" schon in den Unternehmen verbrannt, bis dahin, dass es in einigen Unternehmen schon nicht mehr erlaubt ist, mit dieser Technologie zu entwickeln. Außerdem ist EJB 3 und Java EE 5 in den Bereichen Dependency Injection und aspekt-orientierte Programmierung sicher um Meilen hinter Spring. Bei DI geht es für mich neben den eingeschränkten DI Arten, die EJB und Java EE unterstützen, vor allem darum, dass EJB und Java EE DI nur für EJBs, Servlets usw. erlauben. Spring erlaubt es hingegen für alle Java Objekte. In meinen Vorträgen versuche ich auch deutlich zu motivieren, warum man eben auch "normale" Java Objekte mit Dependency Injection verwalten will. Ein weiterer Punkt ist ebenfalls eher strategischer Natur: EJB 3 wird im Moment nur von JBoss nachhaltig unterstützt. BEA unterstützt neben EJB 3 auch Spring. Bei IBM ist die Situation unklar. Und bei Oracle ist es schließlich so, dass zwar ein Fokus auf EJB 3 gelegt wird, aber wahrscheinlich eher die Persistence API das wichtige Element ist. Außerdem wäre es sicher mal spannend herauszufinden, wie viele Oracle Application Server wirklich im Einsatz sind.

Ebenfalls hat Rod darauf hingewiesen, dass Ruby on Rails eine sehr stark vereinfachende Lösung ist. Die direkte Abbildung zwischen Objekten und Datenbank-Tabellen ist eben unrealistisch, vor allem, wenn man in einer Enterprise Umgebung Namenskonventionen für Tabellen hat.

In seiner Keynote ging Rod Johnson dann darauf ein, warum Java EE Projekte schief gehen. Die gibt es auch hier bzw. hier zu sehen. Ich denke zwar, dass Projekte eigentlich immer aus organisatorischen Gründen schief gehen und nicht aus technischen, aber Java EE ist eben nicht trivial und legt vor allem auch nicht unbedingt die Benutzung der Best Practices nahe, sonder die sind meist schwierig. Auf jeden Fall fand ich den Vortrag sehr positiv - ich bin auch nicht unschuldig daran, dass er auf der WJAX gehalten wurde - und würde jedem an einem Java EE Projekt beteiligtem empfehlen, ihn anzuschauen.
 
Bookmark and Share
 
Projektretrospektiven

In dieser Session stellt Jutta Eckstein ihre Perspektive auf Projektretrospektiven dar.

Wichtiges Leitmotiv einer Retrospektive muss es sein, zu lernen und nicht Fehler zu finden. Die gemeinsame Basis, von der aus man diskutiert, sollte sein: "Jeder hat sein bestes angesichts der Umstände gegeben".

Eine interessante mögliche Eingangsfrage ist: "Wieviele verschwendete Tage hatte jeder?" Über die nächste Frage "Wie vermeiden wir die?" kommt man dann schnell zu konstruktiven Verbesserungen.

Andere mögliche Fragen sind zum Beispiel "War das Projekt ein Erfolg?" mit der genaueren Nachfrage "Würde man es nochmal so machen?". Das interessante ist, dass es bei der Antwort "Das Projekt war super." im Rahmen der Retrospektive dann erfahrungsgemäß ein Drama gibt. Bei einem "ganz gut, aber..." gibt es eher eine konstruktive Diskussion.

Eine spannende Technik ist die Aufstellung: Man stellt sich so auf, dass Leute, mit denen man eng kommuniziert, auch tatsächlich in der Nähe stehen. Dadurch kann man Kommunikationsflüsse gut visualisieren. Die Ergebnisse sind dann oft eher überraschend.

Man kann auch einen Zeitstrahl in die Vergangenheit machen und dann dort die einzelnen Ereignisse aufzeichnen. Die kann man dann rot für schlechte Ereignisse und grün für gute signalisieren. Natürlich kann dasselbe Ereignis für einige positiv und für andere negativ sein, was dann wiederum interessante Diskussionen ermöglicht. In der Analyse kann man dann die Frage klären, ob Dinge zusammengehören und wie sie zusammengehören. Dafür gibt es den schönen Begriff "Gold Schürfen", denn hier ergeben sich die wirklichen Ergebnisse der Retrospektive.

Man kann das ganze auch spielerisch aufarbeiten: Man definiert bestimmte Qualitätskritierien wie Zeit, Spaß und Budget. Anschließend kann jeder dann 3 Dinge definieren, die geändert werden sollen, und drei, die so bleiben sollen. Diese Karten kann man dann auf die einzelnen Bereiche "ausspielen". Die Idee ist, dass man nur wenige Sachen umsetzen kann und das auch im Team machen sollte.

Am Ende stehen dann Sachen, wie zum Beispiel eine symbolische Friendenspfeife. Fragen, die man noch zum Abschluss bearbeiten kann, sind z.B.:



Im Fazit ging Jutta Eckstein dann noch einmal darauf ein, warum Retrospektiven für Agilität so wichtig sind: Agilität betont eben das Element des Lernens. Und Retrospektiven sind ein sehr wichtiges Element des Lernens aus Projekten.
 
Bookmark and Share
2005-11-20
 
Google ownz the Internet

Wenn man das hier so liest, bekommt man langsam den Eindruck, dass Google tatsächlich das Internet dominieren wird. Es macht nicht nur die Werbung und die Suche sondern dann wohl auch das Caching. Fehlt nur noch der Content, dann ist alles bei Google...
 
Bookmark and Share
2005-11-18
 
Wie starte ich ein erfolgreiches Projekt?

Bernd Oesterreich päsentierte hier einige Idee, was man bei einem Projektstart beachten muss. Es ging zunächst um die Zuweiseung klarer Kompetenzen und von Rollen. Außerdem muss man sich über Annahmen und Prämissen klar werden. Das Problem ist, dass man hier in der Angebotsphase ist und (noch) kein Geld hat, aber dennoch die richtigen Weichen stellen muss. Also muss man die richtigen Weichen stellen und sich überlegen, was jetzt die hauptsächlichen Herausforderungen sind. Die Phase läuft seiner Meinung nach bis das Angebot angenommen worden ist bzw. das Projekt läuft.

In dieser Zeit sollte man eine Reihe von Workshops machen, um etwas mehr Klarheit zu erreichen. Dazu gehören Workshops über die Stakeholdern (Identifizieren, Priorisieren, Aufwand und Risiko), über die Anforderungen, zur Auftragsklärung, zur Klärung des Risikos, über die Kalkulation und zur Angebotsvorbereitung. Bei diesen Workshops ist auch der Weg wichtig, weil man durch die Diskussion viele weitere Informationen bekommt.

Ein weiterer Punkt ist die Systemidee und die Zielsetzung: Man muss sie entwickeln. Sie sollte knapp sein und schriftlich formuliert werden. Vorbild: Der Text auf einem Produkt-Karton.

Beim Risiko ist die Betrachtung der Erfolgskritierien wichtig. Außerdem sollte man die Risikos jeweils mit Beschreibung, Wahrscheinlichkeit und dem dann entstehenden Schaden bewerten. Dabei sollte man sich zum Beispiel auf die Top 10 beschränken, weil man mehr sowieso nicht verwalten kann. Man kann auch neben Risikos Chancen verwalten: Man kann "Begeisterungsanforderungen" sammeln, die den Kunden eben nicht nur die gewünschten Features liefern, sondern ihn begeistern. Die kann man später zum Beispiel als Tauschangebot nutzen.

Das nächste Thema war das Thema Preismodelle. Dieses Thema ist ausgesprochen interessant, denn üblicherweise gibt es Festpreis-Szenarien, die dann agilen Methoden entgegenstehen. Agil Entwickeln bedeutet ja gerade, auf sich ändernde Anforderungen reagieren zu können. Dadurch ändert sich der Aufwand und damit auch der Preis. Also hat man ein Problem. Auf der anderen Seite verlangen die Kunden - und zwar zu Recht - dass auch Software Entwicklung gegen Festpreis funktioniert - wie eben im Rest der Welt auch. Auf der anderen Seite hat man dann eben Probleme, weil man in einen starren Prozess verfällt, der nicht nur weniger gut funktioniert, sondern auch dem Kunden weniger Flexibilität lässt. Wenn man nun aber am Preismodell etwas ändert, kommt man hier weiter.

Bernd Oesterreich verglich dann also verschiedene Modell. Das erste ist der Festpreis. Man kann ihn auch noch jeweils phasenweise bzw. pro Iteration festlegen oder komplett. Vorteil ist die Stabilität, Nachteil die fehlende Flexibilität. Die Stabilität ist auch für den Auftragnehmer ein Vorteil, weil man eben nicht so leicht aus dem Vertrag rauskommt.

Bei Aufwand ist man flexibel, aber der Auftragnehmer muss auch mit Reduktion, Verschiebung oder Unterbrechung rechnen, was ein höheres Risiko ist. Wenn man den Aufwand noch mit einer Obergrenze des Preises kombiniert, hat man als Auftragnehmer ein noch größeres Problem, weil man kein Gewinn mehr machen kann. Wenn man effizient ist, kann man den Gewinn aus einem Festpreis nicht realisieren, und wenn man nicht effizient ist, hat man den gleichen Verlust wie bei einem Festpreis.

Der Festpreis pro Phase erzeugt einen Wettbewerb pro Phase. In jeder Phase kann man im Prinzip eine neue Ausschreibung starten. Dadurch kann der Kunde das ganze besser steuern.

Ein Idee ist ein agiler Festpreis. Dabei wird ein fester Gesamtpreis vereinbart und gleichzeitig ein Verfahren festgelegt, mit dem man den Preis eines Features bewerten kann. Dazu gibt es verschiedene Möglichkeiten: Function Points, Widget Point (orientieren sich an der Anzahl der GUI Elemente) und Essential Use Case Steps. Es ergibt sich ein Festpreis mit inhaltlichem Spielraum. Noch nicht realisierte Anforderungen können entsprechend dem Bewertungsverfahren durch gleichteure ersetzt werden. Dadurch schafft man sich eine zusätzliche Option und hat den Festpreis als Rückfall. Dies kann beispielsweise im öffentlichen Bereich sinnvoll sein, denn dort muss man den Preis fest machen, aber hat bei dem vorgeschlagenen Verfahren inhaltliche Flexibilität.

Dann gibt es noch den agilen Phasenfestpreis. Dabei wird pro Iteration ein fester Preis entsprechend einem transparentem Kalkulationsverfahren ermittelt.

Die letzte Alternative ist die Preisgarantie, die darauf hinausläuft, dass man nicht nur das Projekt, sondern auch die weitere Wartung zu einem garantierten Preis durchführt. Siehe hierzu auch IS-Rating.
 
Bookmark and Share
2005-11-17
 
Spring Powerworkshop

Heute war der Spring Powerworkshop auf der WJAX angesagt. Markus Kehle und ich hatten gut 60 Teilnehmer. Das ganze war daher etwas stressig, aber sehr spannend und ich habe das ganze sehr genossen - ich gebe gerne Trainings. Positiv war vor allem, dass es zahlreiche Fragen gab, was bedeutet, dass die Teilnehmer wirklich interessiert waren. Außerdem war es so möglich, auf die konkreten Fragen und Themen einzugehen. Auf diese Weise habe ich auch viel Input für die Verbesserung der Unterlagen aber auch meines Spring-Buchs mitgenommen. Von daher ein schöner Erfolg, den wir hoffentlich auch wiederholen werden.
 
Bookmark and Share
2005-11-16
 
WJAX: ARG!

Ich sitze gerade in der End-Veranstaltung der WJAX. Leider habe ich es nicht geschafft, drüber zu bloggen, hole das aber noch nach. Das zeigt auch den Charakter der Veranstaltung: Ich habe extrem viel Zeit damit verbracht, mit einer Unmenge von Leuten zu reden. Die Ergebnisse waren sehr spannend. Ein weiteres Ergebnis ist, dass Spring eines der wesentlichen Themen der Konferenz war. Adrian Colyer hat einige coole Sachen bezüglich Aspekten und Spring gezeigt. Das waren gleich zwei Sessions. Rod Johnson hat die Keynote "Why J2EE Project Fail" gezeigt. Und morgen habe ich noch den Spring Powerworkshop.

Stay tuned...
 
Bookmark and Share
2005-11-13
 
WJAX

Nächste Woche ist WJAX angesagt. Eine üblicherweise sehr spannende Konferenz. Ich spreche zu folgenden Themen:

Spring

BOF: Architektur - eine Frage des Stils?

Spring Powerworkshop

Aks the Spring Experts mir Rod Johnson


Wird sicher eine spannende Konferenz, vor allem hat sie auch einen kaum zu übersehenden Spring Schwerpunkt...
 
Bookmark and Share
2005-11-12
 
Application Server und Ressourcen Verwaltung

Ein traditioneller Grund für einen Application Server ist ja die Verwaltung von Ressourcen. Mittlerweile kommen mir da allerdings Zweifel. Eine recht unstrittige Ressource, die ein Application Server verwalten muss, sind Threads und Sockets. Auch die effiziente Verwaltung dieser Ressourcen ist sehr wichtig und wird zum Beispiel auch von Web Servern implementiert.

Dann ist man allerdings beim Pooling. Das schlägt an verschiedenen Stellen zu. Bei EJBs ist hier die Frage, ob ein Pooling überhaupt noch sinnvoll ist, weil das Erzeugen von Objekten mittlerweile sehr billig ist. Es kann sogar sein, dass Pooling eine wenig effiziente Lösung darstellt. Dies ist zum Beispiel der Fall, wenn man mit einem Singleton auskommt, weil das Objekt sowieso Thread-safe ist. Genau das passiert öfter, als man denkt, denn die typischen Server-Objekte sind zustandslos. Wenn sie aber zustandslos sind, gibt es auch kaum etwas, worum sich Concurrency Probleme ranken können. Wenn dann die Objekte, die dort aufgerufen, auch alle genauso strukturiert sind, hat man gewonnen. Aber selbst wenn dies nicht der Fall ist, kann man nachträglich (mit Spring natürlich) Pools einbauen und dadurch nur dort Pooling verwenden, wo es sinnvoll ist.

Bei Datenbank-Verbindungen stellt sich die Frage, ob man nicht mit einem eigenen Verbindungs-Pool in der Anwendung nicht genauso weit kommt. Dafür gibt es unterschiedliche Open-Source Implementierungen.

Das bedeutet eigentlich, dass man mit einem Ansatz, einen Web Server zu verwenden, auch recht weit kommen sollte, weil man dort eben nur noch die Verwaltung von Threads und Sockets hat, was eben auch die wesentlichen Ressourcen sind, die ein Application Server unter Kontrolle hält. Als Unterschied bleibt eigentlich nur noch Features wie 2 Phase Commit mit einem Transaktionsdienst wie JTA, was aber eben keine Ressourcen Verwaltung ist...
 
Bookmark and Share
2005-11-11
 
Deutsche Oracle Anwendergruppe Tag

Ich hatte das Vergnügen, in dieser Woche zum ersten Mal bei dem "Deutsche Oracle Anwendergruppe Tag" zu sein. Schon beim Betreten der Tagung hat man nach meinem Empfinden gesehen, dass dies keine Java Veranstaltung war und zwar am höheren Alter der Teilnehmer und dem etwas vornehmeren Dress-Code. Nach einer eher chaotischen Anmeldung ging es dann los: Wir sprachen im Track der SIG Development. Erste Präsentation war - wenig überraschend - Herr Jäkle von Oracle mit den Themen EJB 3 und Top Link. Dabei gab es nicht viel neues zu berichten.

Rudolf Jansen sprach dann über JDBC. Ich hatte hier eigentlich nicht viel spannendes erwartet, wurde aber eines besseren belehrt. In JDBC 4.0 wird sich die Schnittstelle weitgehend ändern und iBATIS sehr ähnlich werden. Vor allem werden dort JDK 1.5 Annotationen verwendet. Dadurch ist es möglich, die Datenbank-Verbindung nur noch zu deklarieren. Anschließend entwirft man dann eine Klasse, auf die das Ergebnis einer Anfrage gemappt werden soll, die also für jede Spalte ein Attribut hat. Anschließend definiert man ein Interface mit Methoden, die jeweils mit einer Query in einer Annotation versehen werden. Diese Query wird bei der Ausführung der Methode an die Datenbank übergeben und das Ergebnis in Objekte umgewandelt und anschließend zurückgegeben. Um die Implementierung des Interfaces zu bekommen, muss man die QueryFactory benutzen. Die geben dann ein DataSet des passenden Typs zurück und man kann darüber iterieren. Außerdem gibt es Erweiterungen von XML Daten. Ingesamt eine recht coole Sache, mit der die Funktionalität von iBATIS nachgebaut wird. Offene Fragen sind für mich, ob z.B. Caching auch integriert ist. Zudem frage ich mich, ob es eine gute Idee ist, wenn ein Treiber eine solche Schnittstelle hat. Wobei mit aber auch nicht klar ist, ob die gesamte Implementierung von JDBC 4.0 im Treiber liegen muss.

Es gab dann einen Vortrag von Frank Schwarz (SignSoft) über JDO und JDO 2.0. Dann sprach Markus Kehle (wie ich von Saxonia Systems) über Hibernate. Mein Spring Vortrag war recht kompakt, d.h. ich habe in 45 Minuten Dependency Injection, JDBC Templates, Transaktionen und iBATIS vorgestellt. Es gab dann anschließend im praivten Gespräch noch einige Fragen und interessante Kontakte.

Den Abschluss bildete noch ein Oracle Thema: ADF und BC4J. Das ist die Java Oracle Lösung, deren Ziel wohl eine 4GL bzw. Oracle Forms ähnliche Entwicklung für Java ist. Entsprechend gibt es eine gute Untersützung in JDeveloper und vor allem CRUD (Create Read Update Delete) Operationen sind leicht implementierbar. Nachteile sind die typischen für einen solchen Ansatz: Vieles ist verdeckt und dann auch schwer zu verstehen. Wenn man eigenen Code integrieren will, wird auch der Einarbeitungsaufwand hoch. Pflege und Anpassung sind entsprechend schwer. Und ein Releasewechsel im Framework ist dan auch ein Problem. Lösung kann eine Schicht zwischen dem Generat und eigenen Erweiterungen sein. Das ganze wird gerade standardisiert, wobei ich mich aber nach dem Sinn frage, denn ein Vorteil ist gerade die Integration in das Oracle Paket - wenn man eh alles aus einer Hand kauft, macht ein Standard wenig Sinn.

Ingesamt also eine recht interessante Veranstaltung, vor allem, weil es ein ganz anderer Blickpunkt war, als man ihn auf den Java Konferenzen so hat, und auch die Fragen waren sehr anders. Und sowas erweitert immer den Horizont.
 
Bookmark and Share
2005-11-07
 
Trails Hype

Ich habe über Trails schon hier gebloggt. Heute berichten das Java Magazin und The Server Side über das 0.8 Release. Damit sollten es in Zukunft mehr im Fokust der Java Gemeinde stehen. Im Java Magazin 12/05 gibt es passend auch einen Artikel zum Thema von mir...
 
Bookmark and Share
 
VM Ware kostenlos!

Tja, da hat wohl die Blogger Software noch ein Problem gehabt. Also, was ich sagen wollte:

Mit dem VMWare Player steht eine Software bereit, mit der man umsonst zumindest virtuelle PCs abspielen kann. Wie kommt man an ein passendes Image? VMWare selbst bietet hier einige VMs an, aber darunter ist z.B. kein SuSE 10.0. Wie kommt man da weiter? Hier findet man vorbereitete leere Images für alle Betriebssysteme und hier einen Thread dazu. Eine Möglichkeit zur Installation von Gentoo findet sich hier. Wer keine Probleme hat, mit einem Editor umzugehen und sich wagt, mit QEmu Images zu erstellen, kann so umsonst VMs bauen und Betriebssysteme installieren.

Bei mir gab es nur das Problem, dass die VM nicht vom DVD-ROM booten wollte. Aber in schon zitierten Thread finden sich Hineweise, wie man das virtuelle DVD-ROM der VM auf ein ISO Image umlenken kann und dann geht's.

Jetzt fehlt nur noch das Intel Powerbook und VMWare Player für Mac OS X / Intel...
 
Bookmark and Share
 
 
Bookmark and Share
2005-11-03
 
Vortrag Oracle Tag

Nächste Woche am 8.11. halte ich beim Oracle Tag in Mannheim einen Vortrag über - richtig - Spring. 45 Minuten für Spring Dependency Injection, JDBC, iBATIS und Transaktionen ist sportlich, aber machbar. Details hier und hier.
 
Bookmark and Share
 
Another one bites the dust...

Tja, da scheint es einer Firma, die früher mal richtig cool war, an den Kragen zu gehen: SGI fliegt bei der NYSE raus. Früher waren die Maschinen die ultimativen Kisten, jetzt bekommen sie durch Linux und durch die Mac OS X Durchdringung im kreativen Bereich so viel Konkurrenz, dass es eigentlich kaum noch eine Chance gibt. Zwar versucht SGI, im Linux Business mitzuspielen, aber ob das reicht? Wäre schade drum, falls es schief geht!
 
Bookmark and Share
2005-11-01
 
AJAX und Java

AJAX als Modell für bessere Web GUIs ist einer der Hype Begriffe. Dabei geht es darum, mit JavaScript die Web Seite dynamisch zu ändern, ohne dabei einen kompletten HTTP Request mit einem Formular abzuschicken, sondern XML Daten zu übertragen.

Wenn man nun die Ruby on Rails Lösung hier anschaut, kann man sehen, wie man die Komplexität dieses Paradigma recht gut verstecken kann. Schaut man auf die Java Lösungen, sieht man dort Low-Level JavaScript Gehacke, zum Beispiel hier oder hier. Dies ist nicht das, was man als Entwickler will. Man will eigentlich auf einer höheren Abstraktionsebene arbeiten und von XML und JavaScript nicht mehr so viel sehen. Es gibt anscheinend alternative Lösungen z.B. die diese Tag Library. Auch im JSF Umfeld gibt es einiges.

Was bedeutet das? Die vielen Lösungen im Java Umfeld sorgen dafür, dass nicht klar ist, welche nun die beste ist und zum Teil wieder Low-Level gebastelt wird. Das ist sicher keine gute Herangehensweise und hier muss die Community noch lernen.
 
Bookmark and Share
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff