Skytecs Entwicklerblog

Quelloffener Kaffee

Juhuu, Sun öffnet jetzt wirklich alle Java-Quellen, so dass ich auf meinen Linuxkisten endlich nicht mehr irgendwelche dubiosen Restricted-Pakete installieren muss, um IT-Kaffee auf die Platte zu bekommen. Man könnte sagen, dass das ja auch lang genug gedauert hat und vermuten, dass Mono irgendwie doch irgendwas damit zu tun haben könnte - aber das würde bedeuten, Sun zu kritisieren, und das wollen wir ja nicht. Da hacken wir lieber noch eine Runde auf Microsoft rum, das ist politisch deutlich korrekter und in den meisten Kreisen auch sozial verträglicher.

Microsoft hilft, Silverlight auf Linux zu portieren

Als Microsoft ein eigenes Konkurrenzprodukt zum verbreiteten “Flash” namens “Silverlight” angekündigt hat, wurde die Initiative von vielen Leuten (inklusive mir selbst) eher belächelt. Wer benutzt schon den MSIE? Und wer will überhaupt eine Alternative zu Flash, das mittlerweile mehr oder weniger überall verfügbar ist? Nee, sowas hat doch keine Chance…

Mittlerweile stehe ich meiner ersten Einschätzung etwas skeptischer gegenüber, insbesondere, seit ich gelesen habe, dass Microsoft die Entwicklung einer Linux-Version des Silverlight-Players ganz offiziell unterstützt.  Sollte man im Hause Microsoft etwa verstanden haben, dass man so eine Technologie am besten etablieren kann, indem man sie auch Leuten zugänglich macht, die kein Windows benutzen? Oder wird das eher so eine Nummer, bei der versucht wird, die Technologie zu etablieren, wobei aber später aller Support zurückgenommen wird, damit die Leute eben doch wieder Windows nutzen? Wir werden sehen, aber da ich tendenziell an das Gute im Menschen glaube, begrüße ich diese Microsoftsche Entscheidung sehr.

XSLT 2.0 in wenigen Worten

Was soll ich sagen: In XSLT2 gibt es endlich nur noch Node-Sets, keine Tree-Fragments mehr. Juhuu, es geschehen noch Zeichen und Wunder!

Ja, OK, vermutlich war das für Leute, die sich intensiv mit der Thematik beschaffen, keine wirklich neue Information - aber für Gelegenheitstransformatoren wie mich mag es ein unerwarteter Grund zur Freude sein. Für alle anderen verweise ich noch schnell auf eine Funktionsreferenz für XPath2, die im anderen Artikel für meinen Geschmack etwas zu unauffällig verlinkt wurde, so dass ich hier nochmal mit einem etwas prominenteren Verweis nachlegen will.

JSR-286 - die Zukunft der Portlet-API

Die Kollegen bei Sun haben, wie jeder andere Hersteller, nicht immer ein glückliches Händchen bei der Spezifikation von Standards. Während beispielsweise die Servlet-Spezifikation durchaus rockt und auch die XML-Funktionen nicht wirklich übel sind, war EJB von Anfang an eher eine Totgeburt, die auch durch den dreisten Klau von Ideen bei Spring und Hibernate in EJB3 nicht sehr viel weniger komisch riecht als vorher. Wenn man mich aber fragt, welches die bisher lausigste API war, die jemals durch den JCP gerutscht ist, würde ich sofort JSR-168 nennen. Die Portlet-Spec, jene diabolische API aus den tiefsten Tiefen jener Spezialhölle, in der Elternmörder und Kinderschänder ewig braten.

Um Abmahnproblemen durch Leute ohne genaue Peilung vorzubeugen: Selbstverständlich halte ich keinen der JSR-168-Entwickler für einen Elternmörder oder Kinderschänder, ich halte nur den für alle Ewigkeit andauernden Zwang zur Verwendung dieser JSR für eine durchaus geeignete Maßnahme zur Bestrafung besagter Subjekte.

Keine Schmähung sollte ohne Begründung bleiben, und so möchte ich kurz darstellen, warum ich JSR-168 so hasse: Sie ist kompliziert, die Spezifikation liest sich so unterhaltsam wie mein letzter Steuerbescheid und es ist einem verdammten Portlet nicht möglich, verdammte Ressourcen auszuliefern, so dass schon die verdammte Implementierung eines verdammten Wetterportlets mit einer verdammten Wolkengrafik darin zu einer verdammten Strafe wird. Wen man damit strafen könnte, habe ich oben schon erwähnt.

Wie schon bei EJB zeigt Sun sich aber gnädig und arbeitet an einer neuen Version des Standards. Die erste Version der JSR-268 (Portlets 2.0) kann man sich auch schon besorgen und sie sich zu Gemüte führen, wobei sofort einige Dinge auffallen:

• Portlets können jetzt auch Ressourcen ausliefern, hurra!
• Portlets dürfen miteinander kommunizieren, statt isoliert und sozial verarmt in ihrem Container abzuhängen - Events machen es möglich.
• Viele Punkte, deren definitorische (gibt es das Wort?) Klarheit in der ersten Spezifikation in Richtung Milchglas oder gar Milchreis tendierten, sind deutlich präziser Formuliert.
• Der Zugriff auf User-Informationen ist immer noch in einer Weise spezifiziert, die mir das Wort “*$§&/!” entlockt.
• Mein Steuerbescheid lässt immer noch größeres schriftstellerisches Talent beim Autor vermuten als die Spec.

Wie dem auch sei, die Spezifikation ist ja noch nicht fertig und der gute Wille seitens Sun ist deutlich erkennbar, das ist ja schon mal ein Anfang. Vielleicht wird ja doch noch was aus den Java-Portlets und wir müssen nicht alle auf Sharepoint umschwenken, wo man derzeit meiner Meinung nach deutlich stressfreier zum Ziel kommt.

Kann Google JavaScript?

Suchmaschinen sind toll, aber es soll ja Informationsisolationisten geben, die ihre Websites ganz für sich alleine haben wollen. Kein anderer soll sehen, was sie gemacht haben, deshalb verwenden Sie für ihre Navigation JavaScript. Ha, Google, das verstehst Du nicht, ich kann ganz alleine bleiben!

Erm, nein.

Wenn die Experimente einiger russischer “Google-Optimierer” nicht falsch angesetzt oder interpretiert wurden, muss man davon ausgehen, dass der Googlebot und seine Kollegen sehr wohl JavaScript interpretieren - zumindest bis zu einem gewissen Grad. Wer sich also vor der Welt verstecken und seine Seiten ganz für sich allein behalten will, muss sich doch etwas mehr Mühe geben, um sein Ziel zu erreichen. Oder seine Page einfach auf der lokalen Platte ablegen, die ist bis zur Einführung des “Bundestrojaners” mit anschließendem Aufkauf der deutschen Regierung durch Google vermutlich halbwegs suchmaschinensicher.

Pegasus und Mercury geben den Geist auf

Eine der Anwendungen, die man bei der Entwicklung einer Webapp auf seiner Kiste haben sollte, ist ein Mailserver - schließlich ist Mailversand eine dieser Standardfähigkeiten, und die Benutzung produktiver Mailserver ist nur in den wenigsten Fällen eine gute Idee. Glaubt mir, ich weiß das… Spätestens, seit ich mal durch einen Configfehler beim Testen echte Mails an echte Leute verschickt habe. Sowas kommt nur gut, wenn man eine enorme Selbstkontrolle beim Verfassen von Testmails hat (habe ich nicht) oder die Empfänger viel Humor haben (hatten sie erfreulicherweise).

Für diejenigen unter uns, die unter Windows entwickeln, gibt es zwei typische Tools, die man als lokale Mailserver verwendet: Mercury und Hamster - beide gut, aber mir hat Mercury immer besser gefallen als das Nagetier. Zukünftig brauche ich aber vielleicht doch einen Hamsterkäfig auf meinem Rechner, denn die Entwicklung und Verteilung von Mercury und dem zugehörigen Pegasus Mail wurden aus finanziellen Gründen eingestellt. Ich gebe zu, etwas traurig zu sein, denn Mercury war (wie erwähnt) mein liebster Windows-Mailserver und Pegasus… Ja, mit diesem Programm habe ich damals meine ersten Mails empfangen, bevor ich dann irgendwann mal die Kohle für eine Lizenz von AK-Mail (huch, das gibt es ja tatsächlich noch…) zusammen hatte. Ich verabschiede mich vorläufig mit einem Seufzen und hoffe, dass die Sourcen irgendwann mal open werden oder sich irgendwer findet, der die weitere Entwicklung von Pegasus und Mercury finanzieren mag.

Microsoft verschenkt ein XP mit MSIE 6

Wir alle haben uns auf den Internet Explorer 7 gefreut: Endlich ist alles besser, CSS könnte mit etwas Glück funktionieren und wir dürfen neue Hacks lernen, um unseren HTML-Kram kompatibel zu kriegen, weil die alten nicht mehr das tun, was sie einmal taten. Jucheissa, wir lieben die Herausforderung, deshalb jauchzen und frohlocken wir! Naja, außer natürlich, wenn plötzlich irgendwer anmerkt, dass unser Kram nicht mehr mit dem MSIE 6 funktioniert, der sicherlich noch eine ganze Weile brauchen wird, bis er endgültig ausstirbt. OK, dann starten wir halt den MSIE 6 und testen mit dem… Oder auch nicht, schließlich kriegt man den nicht parallel zum 7er installiert, sofern man nicht zu irgendwelchen merkwürdigen Standalone-Versionen dieses Browsers greift, die nur selten aus wirklich vertrauenswürdigen Quellen stammen.

Ob Microsoft selbst vertrauenswürdig ist, überlasse ich mal der Einschätzung meiner Leser, aber immerhin gibt es jetzt eine Lösung aus dieser Quelle. Wie CEhret mir nämlich zu berichten wusste, verschenkt Microsoft eine virtuelle Maschine mit Windows XP und MSIE 6, die immerhin bis April 2007 funktionieren wird. Lang genug also, damit man sich in der Zwischenzeit eine dieser komischen Standalone-Versionen des Internet Exploder 6 besorgen kann.

Die Dunkle Materie des Internet

Obwohl sich Webentwickler ständig über Browserkompatibilitätsfragen aufregen, gibt es eine ganz einfache Möglichkeit, nie wieder Stress mit solchen Problemen zu haben: Man lässt das Entwickeln sein und züchtet Schafe in Neuseeland. Das ist nicht nur weitaus entspannender als HTML-Gefrickel, nein, man hat auch immer hübsch warme Pullover und einen anständigen Braten am Sonntag. Problem gelöst, der nächste bitte.

Ach, Ihr hängt irgendwie an Eurem Job, obwohl Ihr Euch damit auseinandersetzen müsst, dass die dokumentierten Standards das Papier nicht wert sind, auf dem man sie sich nicht ausdruckt? Dann sieht’s natürlich arg düster aus. Kein Pullover, kein Braten und definitiv kein Stück Javascript-Code, das auf Anhieb überall funktioniert. Aber vielleicht kann ich wenigstens etwas Trost bieten, auch wenn das letztendlich nichts zum Gelingen der Stressprojekte beiträgt.

Ich bin nämlich über einen Blogpost gestolpert, in dem ein Opera-Entwickler beschreibt, warum seine Haare vorzeitig ergrauen und so mancher seiner Tage eher suboptimal ist. Der arme Kerl muss sich nämlich nicht nur mit Kompatibilität seines HTML-Zeugs zu den verschiedenen Browsern rumschlagen, nein, der muss auch noch einen Browser entwickeln, der all das zu vereinen versucht. Wenn Ihr also mal wieder über irgendeine Browsermacke flucht, zählt bis 10, denkt an den Typen und wisset, dass es noch viel schlimmer kommen könnte. Und viel schlimmer kommen wird, spätestens beim nächsten MSIE-Release.

Kostenloser 10-wöchiger AJAX-Onlineworkshop

Ein sauberes Netz dank Scheuermittel! AJAX FTW! Spätestens seit meinen durchaus positiven Erfahrungen bei der Einbindung von Kallistra in Website mit Hilfe dieses AJAX-Krams bin ich von der Technologie ja wirklich angetan, auch wenn ich zugeben muss, dass ich momentan eigentlich nur mit Libs rumspiele, ohne wirklich komplett zu verstehen, wie die Grundlagen funktionieren. OK, im Grunde ist das optional, aber ich bin halt einer von diesen neugierigen Typen… Etwas strukturierte Fortbildung wäre nicht übel.

Eventuell verschaffe ich mir diese Fortbildung ja in Form des kostenlosen Online-Workshops über AJAX, der am 4. August offiziell losgeht und mir von MHenze gemeldet wurde. Falls ich bis dahin nicht schon durch intensive Webrecherche und Ajaxifizierung aller greifbaren Applikationen, die SKYTEC jemals gebaut hat, zum totalen Putzmittelprofi geworden bin. Und falls mich das Thema bis dahin immer noch so interessiert - ich bin ja bekanntlich extrem sprunghaft, was meine Interessen angeht.

Verletzt Hibernate ein Patent?

Wenn man heutzutage eine etwas umfangreichere Java-Applikation baut, kommt man recht oft recht zügig an den Punkt, an dem man Hibernate einbindet - schließlich ist es kein Zeichen besonderer Männlichkeit mehr, wenn man seinen SQL-Code selber schreibt. Zumindest für amerikanische Entwickler könnte der Griff zum Einschläferer aber bald eine Sache werden, die ein komisches gefühl in der Magengegend provoziert, denn angeblich verletzt Hibernate ein Patent.

Mir fällt dazu offen gestanden nur eins ein, nämlich dass Softwarepatente der wohl krasseste Innovationskiller sind, den man sich vorstellen kann. OK, besonders neu ist die Erkenntnis nicht, aber an diesem Beispiel sieht man mal wieder ganz gut, wie schnell es jeden von uns treffen kann…