J and I and Me
2006-08-29
  Enterprise Software und Stabilität
Eigentlich sollten Enterprise-Produkte stabil sein. Man will ja nicht bei jedem Versionssprung gleich die ganze Anwendung ändern. Ein Beispiel: Man kann eine existierende Spring 1.0 Anwendung durch Austausch der Bibliothek mit Spring 2.0 laufen lassen, siehe hier. Anderes Beispiel: Man kann in Ruby in 1.8.5. keine Breakpoints mehr setzen, siehe hier oder auch bei InfoQ. Interessanterweise war das Ziel von 1.8.5 höhere Stabilität...

Nun ja, kommt wahrscheinlich überall mal vor und die Implementierung von Breakpoints zu testen ist ja auch nicht vollkommen trivial.
 
Bookmark and Share
2006-08-28
  Wie organisiert man Vertrieb?
Warum nicht von IBM lernen? Hier die drei geheimen Training-Videos:
eins

zwei

drei
 
Bookmark and Share
2006-08-25
  SOA beim Software Engineering Radio
In der aktuellen Folge beim Software Engineering Radio sprechen Markus Völter und ich über das SOA. Die Folge gibt es hier mit einem recht schönen Kommentar und das Java Magazin hat es auch schon hier angekündigt.
 
Bookmark and Share
2006-08-14
  Spring Trainings
Ich werden vom 26.-29.9. ein Spring Training in Hamburg geben und dann vom 21.-24.11. eines in München. Registrieren kann man sich online, noch gibt es Plätze und vor allem auch die Frühbucher-Rabatt...
 
Bookmark and Share
2006-08-13
  Hibernate, Spring, Persistenz
Auf InfoQ gibt es einen Artikel über die richtige Abstraktion in der Persistenz-Schicht. Leider werden dort mehrere Dinge vermischt.


Zunächst gibt es die Kritik, dass man keine Abstraktion über eine Lösung wie Hibernate bauen sollte, weil man sowieso irgendwann proprietäre Features nutzen muss. Dem stimme ich zu, für Performance-Tuning sind solche Sachen unablässig. Warum allerdings Spring's HibernateTemplate dort als eine schlechte Abstraktion aufgeführt wird, ist mir unklar: Es bietet vollen Zugriff auf die gesamte Mächtigkeit von Hibernate, nur eben eleganter. Und die mangelnde Definition der Semantik des HibernateTemplates ist ebenfalls komisch: Es gibt Dokumentation und im Zweifelsfall auch Code, den man anschauen kann. Übrigens schreitet der Artikel dann fort und behauptet, JPA sei die einzig sinnvolle Abstraktion. Schade nur, dass JPA nicht - wie im Artikel auch angesprochen - alle Features aller Implementierungen standardisiert (was ein Standard nie tut) - hier wird Spring in Zukunft als "Vereinheitlicher" dienen.

Dieser Artikel weißt der Spring Unterstützung für Hibernate immerhin einen Sinn zu, sieht aber auch das HibernateTemplate als nicht sinnvoll, leider ohne Begründung. Es bietet eben einheitliche Exceptions für JDBC und Hibernate, meistens sehr kompakten Code und außerdem ein automatisches Aufräumen der Ressourcen. Warum man das nicht haben wollen würde, ist mir unklar, aber dann kann man immer noch Transaktionen von Spring steuern lassen und sich die Session holen, wie in den Artikeln ausgeführt. Spring zwingt niemanden zu seinem Glück.

Viel interessanter und hier leider nur in Ansätzen ausgehführt, ist jedoch die Frage, wie man überhaupt mit der Persistenz umgehen will. Heutzutage ist Hibernate meistens das Werkzeug der Wahl. Hibernate ist jedoch kein triviales Stück Technologie, d.h. es vereinfachte Dinge nicht bedingt. Wenn man komplexe OO-Logik hat, wird man sich ohne Hibernate schwer tun, sie zu implementieren. Dennoch hat man oft Schwierigkeiten, Hibernate dazu zu überreden, die "richtigen" SQL Statements abzusetzen. Warum dann nicht das SQL selber schreiben? Auch Argumente wie Caching ziehen hier nur bedingt, da man mit iBATIS oder einer AOP-Cache-Lösung auch dies leicht nachbauen kann. Das einzige Argument gegen ein solches Vorgehen ist, wenn man komplexe Logik hat, so dass man von dem transparenten Nachladen von Daten (Lazy Loading) profitiert.

Die eigentliche Frage sollte also sein, ob O/R-Mapper wie Hibernate im Moment nicht überbewertet werden. In vielen Situationen sind andere Lösungen wie Springs JdbcTemplates oder iBATIS einfacher und effizienter. Man muss ja O/R Mapper nicht gleich als ein Vietnam bezeichnen.
 
Bookmark and Share
2006-08-12
  29 Jahre PC
Auch in den "normalen" Tageszeitungen ist das Thema "25 Jahre PC", was aber genauer eigentlich 25 Jahre IBM PC heißen müsste, denn den Apple II, Commodore PET, Tandy TRS-80 usw. als persöniche Compueter gab es schon länger. Lesenswert auf jeden Fall heise: Hätten wir dich so vermisst? Der PC wird 25 mit einem Hinweis darauf, dass es zum Erscheinen des IBM PC von Xerox schon Rechner mit grafischer Benutzeroberfläche gab. Wenn man 1977 (Commodore PET, Apple II, TRS 80) ansetzt, haben wir mittlerweile 29 Jahre PC ...
 
Bookmark and Share
2006-08-10
  Objektorientiert auf Englisch?
Und? Wie lautet die Übersetzung für "objektorientiert". Richtig, asset-related. Nachzulesen hier.

PS: Wie schon in einem Kommentar zu lesen, kommt die richtige Übersetzung (object-oriented) aber auch zurück. Eigentlich fand ich es nur lustig, dass selbst dieser Begriff mehrdeutig ist.
 
Bookmark and Share
2006-08-09
  Neues auf InfoQ
Auf InfoQ gibt einen Artikel, der recht gut zu dem AOP-Thema der letzten Postings passt, was auch kein Wunder ist, weil er von Adrian Colyer kommt, der ja bei uns dieses Thema verantwortet.

Bei O'Reilly gibt es dann noch ein Blog-Eintrag, der sich mit Spring-Vorurteilen beschäftgt...

Viel Spaß beim Lesen!
 
Bookmark and Share
2006-08-08
  Neues von Apple...
Tja, VMWare für den Mac war nicht die einzige Neuheit. Außerdem wird es Virtual PC von Microsoft nicht mehr für den Mac geben....

Dafür gibt es als Nachfolger für den G5 jetzt den Mac Pro. Mac OS X 10.5 hat jetzt eine Time Machine, eine Art globales Undo, das dazu auch noch cool aussieht und bei dem es mir unklar ist, wie es überhaupt technisch funktioniert. Und virutelle Desktops namens Spaces gibt es auch - ein Feature, dass ich eigentlich schon unter X11 nicht genutzt habe, aber lassen wir uns mal überraschen. Gesehen haben muss man die Demo zu Core Animation, sehr coole Sache.

Oh, und neben Tomcat und JBoss wird die Server Version auch Ruby on Rails enthalten.

Also: Kleinere Verbesserungen, aber nichts wirklich dramatisches. Und ich habe anscheinend die Chance verpasst, mir zum Abschied von den PowerPC Prozessoren noch einen G5 zu kaufen.
 
Bookmark and Share
2006-08-07
  VMware für den Mac
Jetzt ist es klar: VMware kommt auf den Mac, wie man hier nachlesen kann. Ein weiterer Grund für einen Intel Mac....
 
Bookmark and Share
2006-08-05
  Nochmal: AOP
Ein Kommentar zum letzten AOP-Posting (Danke für das Feedback!) kritisiert, dass es noch keine Best Practices zu Thema AOP gibt. Dem muss ich natürlich widersprechen...

Dabei könnte ich erstmal auf unser AOP-Training hinweisen, das diese Themen behandelt, aber solche billige Werbung erspare ich mir lieber...

Mein Kollege Adrian Colyer, der sich mittlerweile schon eine Ewigkeit mit AOP beschäftigt und zuvor z.B. an der Einführung von AOP bei IBM u.a. in den Middleware Bereich gearbeitetet hat, schägt ein Verfahren vor, wie man AOP einführen kann. Durch das Verfahren wird auch das Design-Thema klar: Er schlägt vor, als ersten Schritt Aspekte zu definieren, die bei z.B. aus Layering Gesichtspunkten heraus verbotene Operationen (siehe hier) als Compiler-Error klassifizieren. Als nächsten Schritt sieht er dann die klassischen technischen Aspekte wie Tracing, Profiling usw, die bei AspectJ auch in Development und Production Aspekte eingeteilt werden. Erst dann kommt Aspekt-orientierte Analyse und fachliche Aspekte. Zu diesem Thema hat Ivar Jacobson auch schon ein Buch geschrieben (immerhin der Erfinder der Use Cases...) und es gibt auch noch ein zweites Buch in diesem Bereich (siehe unten). Also gibt es sogar im Bereich AOP Analyse bereits publizierte Best Practices.

Diese Diskussion bezieht aber noch nicht Spring ein und durch Spring ändert sich hier nochmal einiges. Ohne AOP kann man nämlich keine nicht-triviale Spring-Applikation bauen. Security, Transactions usw. bauen alle darauf auf und es gibt auch eine breite Vielfalt an vorbereiteteten technischen Aspekten (Tracing, Performance Monitoring), die man nutzen kann. Daher ist durch Spring der erste Schritt zur Adaption von AOP die Benutzung von Spring, bei der man ohne AOP eh nicht auskommt. Das Schreiben eines eigenen Aspekts ist ebenfalls recht einfach und auch in der Online-Doku nachzulesen. Daher gibt es hier eigentlich auch keine Barriere: Spring ohne AOP macht keinen Sinn und selber Aspekte schreiben ist recht einfach. Man muss es nur tun...

Das interessante ist nun, dass man bereits mit diesen technischen Aspekten zum Teile ganze Layer einsparen kann, weil man eben Security, Transactions und auch Exception-Handling nicht mehr in jeder Klasse ausprogrammieren muss, sondern es zentral irgendwo als Aspekt macht. So gibt es Beispiele, in denen es ganze Layer gibt, die nur für die Remote Aufrufe die Themen Security, Transactions und Konvertierung der Exceptions behandeln und dabei einen signifikanten Anteil des Gesamtcodes darstellt, weil man eben für jede Remote zugreifbare Funktion nochmal dasselbe hinschreibt. Nur mit AOP oder ähnlichen Hilfsmitteln kann man das zentralisiert implementieren und das ist wirklich kein Hexenwerk. Deswegen glaube ich, dass man nur mit AOP den Don't-Repeat-Yourself-Imperativ in statisch typisierten Programmiersprachen umsetzten kann und halte AOP für eine wesentliche Basis-Technologie.

Zweifel habe ich im Bereich aspekt-orientierter Analyse. Meine Erfahrung ist, dass auch objekt-orientierte Analyse noch nicht flächendeckend eingeführt ist, so dass es fraglich ist, ob man hier schon in den Bereich Aspekt-Orientierung vorstoßen will, wenn man Objekt-Orientierung noch nicht vollständig umgesetzt hat.

Meiner Meinung nach hat man schon bei der Beschränkung von AOP auf technische Aspekte ein großes Produktivitätspotential. Diesen Bereich hat die Software-Entwicklungs-Community auch gut verstanden und setzt es spätestens seit EJB 1.0 auch so um - schließlich sind Transaktionen und Security dort als eine Art Aspekt implementiert, auch wenn niemand es damals so genannt hat und vollwertige AOP-Lösungen auch mitttlerweile wesentlich mächtiger sind.

Also schauen wir mal - immerhin bietet Spring 2.0 einen einfacher Einstieg in AspectJ, so dass Spring 2.0 die Einstiegsbarriere für AspectJ eliminiert. Bei der Popularität von Spring kann es sehr gut sein, dass dadurch auch AspectJ sich einer deutlich breiteren Benutzer-Basis erschließt.



 
Bookmark and Share
2006-08-01
  JPA Anomalie?
Bisher ist die Java Persistence API JPA als ein sehr sinnvoller Teil von JSR 220 wahrgenommen worden. Erstaunlich, dass es dennoch komische Effekte gibt. Beispiel: Man hat einen Employee, der AnnualReviews hat. Die AnnualReviews haben keine Referenz zurück auf den Employee (was ja auch OK ist). Auf DB-Ebene würde ich persönlich es so bauen, dass man eine AnnualReview-Tabelle hat, die einen Fremdschlüssel auf den Employee hat. Ich halte die Modellierung für recht offensichtlich. JPA sagt dazu im Standard, dass ein JoinTable entsteht, der die Beziehung abbildet, also Fremdschlüsselbezeihungen zu beiden Tabellen hat. Dadurch hat man eine Tabelle mehr und beim Navigieren eine Tabelle mehr im Join. Wäre das ganze in beide Richtungen navigierbar, würde JPA das ohne Join Table auf der Datenbank implementieren. Komische Sache.
 
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