everflux

Ich lese hin und wieder sehr gerne verschiedene Blogs – darunter sind natürlich „ganz große“ wie das lawblog, aber auch verschiedene kleinere, spezialisierte Blogs regen immer wieder zum Lesen an.
So z.B. auch das Blog von Thomas, der sich in meinen Augen jedoch mit diesem Posting völlig disqualifiziert hat. Ich habe schon überlegt, ob sein Account vielleicht gehackt wurde, er einfach völlig betrunken war, oder von Aliens geclont wurde.
Stein des Anstoßes: Grundlagenentbehrendes marketing-blabla gewürzt mit einer Prise Bashing. Der Artikel beginnt mit der offen gestellten Fragen, warum Thomas seiner Begeisterung für das .net Framework von Microsoft Ausdruck verleihen muß. Beantwortet wird die irgendwie mit „weil die Philosohpie aufgeht“.
Ich möchte auf keinen Fall Thomas hier auseinander nehmen, eher möchte ich meiner Enttäuschung über diesen Beitrag in einem sonst so gern gelesenen Blog ausdruck verleihen. Von seinen Kommentaren mal ganz zu schweigen…

Dennoch nehme ich den Beitrag einmal als Anlaß für eine Nachbetrachtung der Argumentation. Ich beschränke mich dabei nicht auf Microsoft Technologien und werde auch meine Meinung zu einigen Kommentaren darstellen.

Also .net ist deswegen so gut, weil man damit in der Windowswelt schier unbegrenzte Möglichkeiten hat und weil die Philosophie von Microsoft, dem Entwickler ein umfassendes Toolkit an die Hand zu geben, mehr und mehr aufgeht.

Anders formuliert: .net ist deswegen so gut, weil man außerhalb der Windowswelt quasi keine Möglichkeiten hat, und es außer Microsoft keinen Hersteller für .net Tools gibt. Ganz so schlimm ist es natürlich nicht, und die Umkehrung ist keine logische Schlußfolgerung, aber sie verdeutlicht doch die wesentlichen Aussagen, die die Begründung für „.net ist so toll“ liefern sollen.
Außerhalb der Windows welt entwickelt sich langsam Mono – auch mit Unterstützung von Microsoft. Das ist auch gut so, denn ich möchte meine Investitionen in eine Umgebung nicht auf eine Plattform festlegen müssen, die von einem Hersteller kontrolliert wird.
Dabei geht es mir nicht nur um die erstellen Programme, sondern vielmehr um das Knowhow (Tools, API, Framework, Prozesse), dass ich mir mit der Zeit aneigne – da steckt Lebenszeit drinn, und die ist teuer!

Gehen wir die unbegrenzten Möglichkeiten der Technologie weiter durch:

• Entwicklung von (Enterprise-) Webanwendungen mit ASP.NET 2.0.
  Fein. Alternativen dazu gibts natürlich, Java, PHP – aber setzt man auf PHP zieht das Argument, dass man mit verschiedenen Technologien hantieren muss.
• Entwicklung von Desktop-Applikationen mit WinForms und/oder WPF.
  Für Windows. Mit Java kann ich auf Basis von Eclipse RCP oder Swing (und verschiedenen Toolkits) arbeiten und alle Plattformen mit Java bedienen
• Entwicklung von Rich-Media- und Rich-Gui-Anwendungen mit Silverlight (bald).
  Hier gibts wohl als vernünftige Alternative erstmal nur Flash, evtl. später JavaFX – für alle Plattformen auf denen es Flash oder Java gibt
• Entwicklung von Windowsdiensten.
  Mit Java kann ich Dienste für alle Plattformen entwickeln.
• Entwicklung von kommandozeilenbasierten Tools.
  Für Windows. Ich wiederhole mich nur ungern, aber Java…
• Entwicklung von komplexen Datenbanklösungen.
  Auf einem Windows Rechner? Jeder, wie er mag. Mit Java kann ich mich später umentscheiden, wenn ich ein größeres Eisen benötige.
• Entwicklung von mobilen Anwendungen für Telefone und PDAs.
  Nur für Geräte, die das supporten. Gerade im Konsumerbereich ist Java quasi der Standard. Und wenn ich mir anschaue, womit Jamba – und Zulieferer – stinkenreich geworden sind, so ist das nicht WindowsCE

Also was hier so nach „das geht nur mit Microsoft Technologien“ klingt, ist eher Marketinggetrommel. Sicherlich ist es schön mit einer Technologie zu arbeiten – eben das reizt mich ja an .net und Java – jedoch finde ich es etwas kurzsichtig etwas pauschal über den grünen Klee zu loben.
Meiner Meinung nach bedarf soetwas einer differenzierten Betrachtung, denn es gibt einfach keinen goldenen Hammer. Für richmedia ist einfach Flash derzeit Mittel der Wahl. Für Handyspiele ist es Java ME.
Und bei Java ist gerade die Offenheit, die Community mit dem Haufen an Frameworks und Lösungen ein wesentlicher Pluspunkt. Ja, ich möchte mich mit verschiedenen Tools auseinandersetzen, und für mich einen Mix zusammenstellen, der meine Bedürfnisse am besten absteckt.

Immer wieder gibt es Diskussionen zwischen mir und Stefan, ob IntelliJ Idea oder Eclipse „besser“ ist. Verschiedene Blickwinkel, verschiedene Ansätze sind wichtig und machen einen flexibel. (Abgesehen davon halte ich Visual Studio ohne Resharper für quasi unbenutzbar)

Unflexibel stellt sich mir Thomas an dem Punkt dar, an dem es darum geht, dass man Plugins für Visual Studio haben möchte, namentlich für Subversion (SVN). Thomas argumentiert, dass er das lieber über den Explorer (Dateibrowser von Windows) macht, als über die IDE.

Dafür gibt es viele Gründe, Stichwort Tellerrand. So kann man z.B. bequem Files einchecken bzw. verwalten, die in der eigentlichen Solution nichts zu suchen haben (Ressourcen, Dokumente, Grafiken, whatever), und man muss nicht die IDE starten um das Repository zu aktualisieren bzw. etwas hinzuzufügen.

Tellerrand? Gute Güte!
Ich habe im Eclipse SVN Support über Subversive, benutze unter Windows zusätzlich Tortoise und unter allen Plattformen Kommandozeilentools. Denn je nach Anwendungsfall möchte ich gerne optimal arbeiten können. Es gibt nämlich – noch immer – keinen goldenen Hammer.

Im Yahoo Developer Blog berichtet Jeremy Zawodny im Yahoo’s Hadoop Support über den Fortgang der Hadoop Entwicklung seit Doug Cutting von Yahoo angestellt wurde, um Hadoop auszubauen.
Hadoop dient als Grundlage für im großen Stil auf lokale Cluster verteilte Applikationen, wie Nutch, Google-Search und Yahoo-Search, die auf tausenden Rechnern Petabytes von Daten analysieren.
Ein schönes Beispiel wie sowohl Firmen als auch OpenSource Software voneinander profitieren können.

In diesem Blogeintrag beschreibt Jim Alateras seine Erfahrungen mit Buildr als Maven/Maven2 Ersatz.
Versprechen wie:
– drop-in Ersatz für Maven, keine „nderungen am Repository oder pom
– höhere Build-Geschwindigkeit
– Abhängigkeitsprüfungen bei Builds
– und nicht zuletzt einfache Erweiterung für spezielle Tasks

versprechen natürlich einiges.
Vielleicht ist JRuby doch den einen oder anderen Blick wert – und sei es nur hinter den Kulissen.

Je teurer es ist, Daten auszulesen (Speicher, Datenbank, Festplatte, remote-host), desto wichtiger ist Caching, zumindest wenn auf die Daten mehrfach zugegriffen werden soll. (Und das ist regelmäßig der Fall)
Stellt sich die Frage: Was nimmt man zum Cachen. Ganz bestimmt keine Eigenbaulösung, denn es gibt einiges an OpenSource Tools oder Produkten in deren Einsatz sich eine Investition lohnt.
Im Java Bereich dominieren JCS und ehcache, beide implementieren die JCache API (JSR107).
Ich habe noch keine genauere Evaluation durchgeführt, aber ein paar Dinge gefunden, die bei der Bewertung helfen könnten.
JCS vs. Ehcache (hätte auch Fedehandschuh heißen können)
Comparative Cache Performance Numbers (2006, cache4j-performance-tester)

Aber ganz besonders interessant finde ich den Vergleich von ehcache mit memcached. Memcached ist besonders im PHP und Perl Umfeld sehr beliebt, um die Datenbanklaste bei Webseiten zu verringern, die einen hohen Lese- vs. Schreibanteil haben. (Wikipedia z.B.)

Als echter Newcomer wäre dann noch Terracotta zu sehen, hier ist der Ansatz aber auch gänzlich anders. Werden bei den anderen Cache Lösungen allgemeine Objekt oder Datencaches implementiert, bietet Terracotta eine TreeMap Implementierung, die als backing einen verteilten Cache verwendet.

Eine der Kernideen von Google war, auf billiger (commodity) Hardware zu laufen – und auch zu skalieren. Aus der Not heraus geboren (die Studenten Page und Brin hatten einfach wenig und zum Teil nur schrottige Hardware zur Hand um die Google Plattform aufzubauen) wurde das MapReduce Framework geschaffen – auch heute noch der Schlüssel für Google, um zu skalieren.
MapReduce ist auch ein Teil von Nutch, auch hier soll Skalierbarkeit erreicht werden – in Java!
Die freie Java implementierung ist inzwischen ein Apache Projekt, hört auf den Namen Hadoop, und besteht im wesentlichen aus einer MapReduce Implementierung zzgl. einem eigenen Dateisystem zur Verteilung der Daten.
Das powered-by-hadoop sieht schonmal ganz eindrucksvoll aus – last.fm und Yahoo sind Namen, die man kennt.

Für rechenintensive oder aus anderen Gründen in einem lokalen Cluster zu verteilende Anwendungen ist man nunmehr nicht mehr auf C angewiesen, sondern kann sich auch der Hochsprache Java bedienen.

In der Eclipse-Zone habe ich diesen Blog-Beitrag gefunden: Your next favourite keystroke: Ctrl+3
Klar, mußte ich auch sofort testen! Mit strg+3 öffnet sich eine Auswahl von „allem“ dass man öffnen wollte – durch weitere Tastatureingaben wird die Auswahl eingeschränkt.
Praktisch, noch weniger „Umschalten“ auf die Maus in Eclipse nötig. Ich werde mal sehn, ob ich mich daran gewöhnen kann.

Es gibt hier einen interessanten Blog-Post, 5 Reasons why I think I will not use Spring.
Gründe gegen Spring?
Die Hauptargumente sind die langsame Start-Up Zeit des Containers, die nicht gerade schlanke Konfiguration, XML als Konfigurations-Format und nicht zuletzt die mangelhafte Typprüfung bei der dependency-injection.
Auch die entsprechende Diskussion auf TSS sollte man sich zu Gemüte führen, wenn man an dem Thema interessiert ist.

Ich denke Spring bietet eine ganze Menge mehr, als nur Dependency-Injection, und auch wenn einer der Kritikpunkte gerade der ist, dass die ganze Applikation anfägt vom Spring Framework abhängig zu sein, sobald man Features außerhalb von spring-core verwendet, so halte ich das für akzeptabel.
Von irgendwas ist man schließelich immer abhängig, und wenn ich eine Anwendung erstelle, die Jakarta-Commons verwendet, bin ich davon ja auch abhängig.

Abseits der „Eleganz“ oder „Loose-Kopplungs“ Diskussionen sollte man vor allem sehen, dass das Spring Framework einen echten Nutzen bringt, der derzeit durch kein anderes Framework so umfassend abgedeckt wird.

Auch wenn es keinen Standard gibt, hat das Spring Framework doch einen de-facto Standard geschaffen, und Anwendungen die entsprechend der Spring Philosohpie entwickelt wurden, können leicht durch andere Entwickler betreut werden. Umgekehrt fällt es mir als Spring-affinen Entwickler leicht, mich in andere Projekte einzuarbeiten.

So macht Java dann Spaß – Learn once, work everywhere.

Eclipse Europa ist – endlich – da.
Also gleich mal runterladen und durchtesten: http://www.eclipse.org/

Ein lustiges Phänomen: Ein Kunde hatte Probleme mit dem Versand von E-Mails aus einer Java Applikation heraus. Das äußerte sich dann so, dass per JavaMail versandte E-Mails keine richtigen Umlauten enthielten.
Zuerst war der Mailserver in Verdacht, der auch brav ein „Content-Transfer-Encoding: 7bit“ angab. Aber der Postfix Mailserver wurde bereits mit E-Mails gefüttert, die entsprechend „defekt“ waren, und als Subject tauchte „Subject: =?ANSI_X3.4-1968?Q“ auf.
Die Ursache: Auf dem verwendeten Linux Server war keine Locale gesetzt, so dass „C“ / ANSI als Standardlocale verwendet wurde. E-Mails die so versandt werden, haben keine richtigen Umlaute und JavaMail setzt das Subject auf „Subject: =?ANSI_X3.4-1968?Q“. Die Ursache dafür konnte ich bisher nicht finden – aber Abhilfe:
Einfach die Locale richtig setzen bevor Java bzw. der Applikationsserver gestartet wird (Tomcat, Jboss, Resin, …) oder in der Applikation folgendes Property setzen:

System.setProperty("mail.mime.charset","Cp1252");

Anschließend kommen auch Umlaute richtig rüber.

Besser als Sex 😉
Ich habe den Resin J2EE Server getestet und stolperte dabei über einen (eigentlich kleinen) Bug, der mich fast verzweifeln ließ.
Dank der Hilfe von Stefan konnte das jedoch schnell als Kombination von „Bug“ und „falsche URL aufgerufen“ identifiziert werden. Als braver OpenSourceler hab ich dazu einen Bug bei Caucho eingestellt und eine halbe Stunde später war die Sache bereits erledigt.
Wow.