J and I and Me
2006-07-29
  AOP und dynamische Typisierung
Aspekt-orientierte Programmierung ist schon seit geraumer Zeit eigentlich ein Thema. Meiner Ansicht nach wird aber gerade durch die zunehmende Popularität dynamisch typisierter Sprachen die Sache interessanter. Einer der wesentlichen Vorteile ist eben, dass man auf Methoden-Aufrufe anders reagieren kann und dadurch einfacher generische Programme schreiben kann. Wenn man etwas ähnliches mit statischer Typisierung machen will, bleibt eigentlich nur AOP als Mittel der Wahl. Dazu gibt es hier einen recht interessanten Artikel, der zeigt, wie man ein DAO generisch bauen kann und dann bei bestimmten Methoden mit Hilfe einer Namenskonvention eine Hibernate-Query ausführen kann. Das entspricht in etwa dem, was Ruby on Rails mit dem Scaffolding auch anbietet.

Umso verwunderlicher oder dramatischer ist es, dass anscheinend bei vielen Entwicklern die Meinung vorherrscht, dass AOP irgendwie kompliziert und unhandhabbar ist. Das merkt man vor allem daran, dass es Spring-Projekte gibt, die in die Richtung gehen, dass sie zwar Spring verwenden wollen, aber nich AOP oder keine eigenen Aspekte schreiben wollen. Meiner Ansicht nach ist das Schreiben von Aspekten gerade mit Spring recht einfach und löst viele Probleme, die man sonst nicht vernünftig lösen könnte. Gerade bei Java EE Projekten entsteht sonst leicht eine Flut an Code, die kaum etwas sinnvolles tut. Beispiele sind oft Exception Handling, Security oder auch Transaktionen.

Daher ist es wichtig, dass AOP mit Spring recht einfach handhabbar ist und mit Spring 2.0 auch eine einfache Migration in Richtung AspectJ möglich ist. Komischerweise scheint aber dennoch die Hürde höher zu sein als jene für das Erlernen einer neuen Sprache. Vielleicht spielt es auch eine Rolle, dass AOP noch das Siegel eines "offiziellen" Standards fehlt. Aber gerade bei Programmiermodellen sind solche Standards nicht immer förderlich und mit Spring oder Struts gibt es auch gute Beispiele für Programmiermodelle, die sich etabliert haben, ohne dass sie Standards sind. Und am Ende kann Code, der mit AspectJ compiliert wurde, auf jeder JVM laufen, weil es eben ganz normaler Bytecode ist - in so fern hält sich AspectJ also auch an die Standards.

Schauen wir mal, wie es da weiter geht. Interface21 ist mit Adrian Colyer als AspectJ Lead und Ramnivas Laddad im Bereich AOP ganz gut aufgestellt.
 
Bookmark and Share
2006-07-25
  Computer Sammlung


Hier ein Bild von meiner Computer Sammlung.

Von links nach rechts auf dem Tisch:


Unter dem Tisch:



Übrigens benutze ich immer noch den NeXT Laserdrucker. Und ich habe noch einen Apple IIc, der aber nicht auf dem Tisch ist.
 
Bookmark and Share
2006-07-19
  Pressespiegel....
Ziemlich viel Rauschen im Blätterwald im Frühling. Im aktuellen JavaSpektrum findet sich ein Interview mit Rod Johnson, dem CEO von Interface21, und Martin Percival, Senior Technology Evangelist bei BEA. Dort geht es um den EJB 3 Container und das damit assoziierte Open Source Projekt Pitchfork, das Interface21 als freie Implementierung großer Teile der EJB 3 API auf Basis von Spring anbietet. Das bedeutet natürlich nicht, dass EJB 3 jetzt die bevorzugte API für Spring ist, siehe dazu auch die Pitchfork FAQ.

Im Java Magazin gibt es einen Titel zum Thema Spring 2.0, in dem es um die neuen Features geht und zum anderen noch einmal um die Konzepte von Spring. Außerdem habe ich einen Konferenz-Bericht von der Spring One veröffentlicht, der allerdings für die Leser dieses Blogs nicht interessant sein dürfte, weil es hier viel detailierte Informationen über die Konferenz gab.

Fazit: Die Blätter rascheln nicht nur im Herbst, sondern auch im Frühling.
 
Bookmark and Share
2006-07-18
  Spring hat schon wieder gewonnen!
Aber keinen richtigen Preis. Dafür ist es nach Expertenmeinung possibly the best structured code-base in the world! Und das ist doch auch eine schöne Auszeichnung. Mehr Infos gibt es hier, hier und hier. Außerdem wird jetzt seit einiger Zeit auch SonarJ von Hello2Morrow verwendet, um den Code zu analysieren - übrigens eine deutsche Firma...
 
Bookmark and Share
2006-07-10
  PowerBook und UMTS revisited
Mittlerweile arbeite ich jetzt schon seit einem halben Jahr mit meinem SonyEricsson K600i UMTS Mobiltelefon und meinem PowerBook. Ohne würde ich auch nicht mehr zurecht kommen.

Dennoch habe sich mittlerweile Schwächen gezeigt. Ingesammt bin ich sehr zufrieden. Mit UMTS kann man auch Skypen, wobei ich die Erfahrung gemacht habe, dass das eingebaute Mikrofon und Kopfhörer die beste Idee sein. Ich habe auch ein Bluetooth Headset ausprobiert, aber die Ergebnisse waren weniger gut.

Ein anderes Problem ist, dass UMTS eben nicht überall zur Verfügung steht und die Kommunikation mit GPRS, die als Fallback dient, kann teilweise echt nerven. Da gibt es dann nicht nur langsame, sondern auch unzuverlässige Verbindungen. Das nervt dann schon sehr. Zum Teil gibt es dann Problem, vom ICE aus zu surfen, aber das wäre wohl auch etwas viel verlangt.

Ansonsten ist die Kombination aus Notebook und Mobiltelefon nicht wirklich zu empfehlen: Das Mobiltelefon steht nur einige Stunden durch, bis der Akku leer ist. Dabei wird das Telefon auch recht warm. Das lässt sich dann noch optimieren, indem man das Telefon an das Ladegerät hängt, dann wird es nämlich wirklich warm. Und an Tagen wie diesen, kommt es dann dazu (vielleicht wegen der Wärme), dass sich das Telefon einfach abschaltet, was recht unschön ist. Heute zumindest durfte ich dann in der Folge den Rechner neu starten, weil er nicht dazu bereit war, wieder mit dem Telefon zu kommunizieren.

Aufgrund von besserer Stromversorgung und dem Verzicht auf Bluetooth würde ich also daher eher eine UMTS Karte vorziehen, wenn denn das PowerBook einen Slot hätte. Für den neuen Slot im MacBook Pro scheint es noch keine UMTS-Karten zu geben, was auch eher suboptimal ist. Aber schauen wir mal. Übrigens gibt es bei Base dann die Möglichkeit, für die UMTS Karte eine eigene SIM Karte zu bekommen, ohne mehr dafür zu zahlen...
 
Bookmark and Share
2006-07-09
  Die Zukunft von Enterprise Java
Hier berichtet InfoQ über eine Diskussion über die Zukunft von Enterprise Java. Die Zusammenfassung stellt einige spannende Sache klar und ingesamt ist die Diskussion offensichtlich sehr konstruktiv, was eine gute Sache ist....
 
Bookmark and Share
2006-07-08
  Java Starter Equinox Artikel zum Download...
Mein Artikel aus dem Java Starter Magazin zum Thema Equinox kann man hier online anschauen. Equinox ist eine Art Projekt-Kick-Starter, mit dem man schon mal ein Skelett für eine Anwendung bekommt. Vordefiniert sind Hibernate, Spring usw., aber auch eine Integration von anderen Persistenztechnologien wie z.B. iBATIS und anderen Web Frontends wie zum Beispiel JSF ist denkbar. Auch andere wichtige Dinge wie automatische Builds mit CruiseControl sind einigermaßen einfach realiserbar. Ingesamt eine praxisnahe und spannende Sache. Der Artikel beschäftigt sich damit, wie man in Equinox weitere fachliche Objekte integrieren kann.
 
Bookmark and Share
2006-07-07
  Java Forum Stuttgart
Gestern habe ich also als Aussteller zum ersten Mal am Java Forum Stuttgart teilgenommen. Ingesamt eine recht interessante Veranstaltung und es gab auch ein recht großes Interesse an Interface21 und Spring. Von daher sicher eine gelungene Sache. Es ist immer ein gutes Zeichen, wenn am Stand keine Langeweile aufkommt. Interessanterweise gab es auch ein recht großes Interesse an Spring Rich Client, was meiner Ansicht nach auch eine recht gute Technologie ist, aber im Moment immer noch in Version 0.1 ist. Aber gerade das Design und die Architektur sind sicher interessant. Schauen wir mal, wie es damit weitergeht...
 
Bookmark and Share
2006-07-03
  Über das Gängige...
Wenn man wirklich Anwendungen und IT-Infrastrukturen bauen will, die lange Zeit funktionieren, dann ist es sinnvoll, darauf zu achten, dass man gängige Produkte nutzt. Das sind solche Produkte, die im fraglichen Kontext von vielen anderen ebenfalls eingesetzt werden. Warum ist das wichtig? Weil in 10 Jahren nur für diese Produkte noch ernsthafter Support existieren wird, Skills am Markt vorhanden sind usw. Das bedeutet, dass als Investitionssschutz dieses Thema ein wichtiger Punkt bei der Produktauswahl sein sollte. Eine Evaluierung ist eben mehr, als nur eine rein technische Geschichte.
 
Bookmark and Share
2006-07-01
  Vom Pattern zum Anti-Pattern?
Wenn man das GoF-Buch heute liest, sind einige der dort beschriebenen Patterns inzwischen fast zu Anti-Patterns geworden. Ein Beispiel ist Singleton. Während die ursprüngliche Idee, ein Objekt nur einmal zu instanziieren, nicht schlecht ist, ergibt sich gleichzeitig ein Problem: Das Singleton ist überall im Code bekannt und kann verwendet werden, ohne dass man dies von außen erkennen kann. Dadurch wird Testing und isolierte Wiederverwendbarkeit schwierig.

Noch entscheidender ist meiner Ansicht nach die Factory. Das Pattern hat früher die Erstellung eines konkreten Produkte vor dem aufrufenden Objekt versteckt. Grundsätzlich keine schlechte Idee, aber inzwischen weiß ich nicht mehr genau, wieviele Factories ich schon gebaut habe und wenn man dann testen will, muss man die Factories so bauen, dass man auch andere Produkte erzeugen lassen kann (Mocks).

Durch Dependency Injection lassen sich diese Themen natürlich lösen, was aber hier nicht Thema sein soll. Viel interessanter ist die Frage, ob das GoF Buch heute immer noch so geschrieben werden würde. Und ob nicht eben Patterns wie Factory oder Singleton inzwischen sogar Anti-Patterns sind.
 
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