Skytecs Entwicklerblog

Reiche Klienten mit Spring

Wenn man vor hat, sich eine traditionelle Standalone-Applikation (Neudeutsch: einen “Rich Client” oder auch “reichen Kunden”) zu basteln, statt seine Frontends nur ins Web zu pumpen, sollte man zusehen, dass man sich auf irgendein Framework stützt - sonst macht man sich einfach zuviel Arbeit, die nur dem dem Drumrum zu tun hat, ohne wirklich irgendwie zur Verbesserung der Welt oder der eigentlichen Anwendung beizutragen. Für Java-Coder heißt das typischerweise, sich ein Monster wie NetBeans oder Eclipse ans Bein zu binden, was eventuell für kleine Applikationen minimal überdimensioniert sein könnte.

OK, wir haben also ein Problem mit zu fetten Frameworks und Java, und wie heißt hier die typische Lösung? Kinder, sprecht mir nach: “Spring wird’s richten, Spring ist die Rettung und das Licht im Dunkel!” - etwas lauter bitte! Ja, so ist’s brav, das habe ich bis ins Büro gehört. Und natürlich war das nicht nur inhaltsleeres Dumpfgebrülle, wie man es in diesen Tagen des Oktoberfests in München sehr oft vernimmt, sondern die Wahrheit und nichts als die Wahrheit, so wahr mir James Gosling helfe.

Die Helden vom Spring-Projekt haben nämlich, wie ich leider erst jetzt erfahren habe, neben ihres sowieso schon geilen Webframeworks auch noch ein Framework für die Entwicklung von Java-Desktop-Anwendungen aus dem Boden gestampft, das recht schlank aussieht und optisch einen ziemlich guten Eindruck macht. Erfahrungen kann ich hier noch nicht beitragen, weil ich momentan keine Verwendung dafür habe, aber ich hoffe hier schon bald Kommentare zu lesen, die uns allen sagen, ob das Ding wirklich so gut ist, wie ich es mir von allem erwarte, wo Spring drauf steht.

Login mit AJAX und ACEGI

Wenn man schon Web 2.0 macht, dann bitte richtig, also komplett mit Venture Capital, einem total gestörten Businessplan und ganz viel Scheuerpulver für’s Web. Das Scheuerpulver wird dabei klassisch verwendet, um so ziemlich alle Aspekte der Oberfläche aufzupolieren - nur beim Login hat der normale Web-2-Bastler meist noch Schiss und verschickt einfach ein klassisches Formular. Igitt, wie 2002 sowas doch ist, das kann man doch nicht machen… Muss man auch nicht. Über Yigg.de habe ich nämlich ein Tutorial für ein AJAX-Login-Form, das auf dem Server mit ACEGI spricht, gefunden, mit dem kriegt man endlich seine ganze Website modern.

Irgendwie hip finde ich übrigens auch diese Zirkularverbloggung, bei der ich Sachen von Yigg hole, sie blogge und sie dann über das Wordpress-Plugin von Yigg in selbige Seite zurückstopfe. Irgendein armer Google-Rechner wird davon bestimmt ähnlich verwirrt wie die Banker, die dachten, sie hätten mit dem Dotcom-Tod die Sache mit den Krediten für hahnebücherne Geschäftsideen hinter sich gelassen. Finde ich irgendwie gut.

Buchtipps zur Entwicklung mit Design Patterns

Ich werde immer mal wieder von neuen Kollegen, die aus der PHP-Welt kommen, gefragt, wie sie am besten Java lernen können, weil das ja so eine Qualifikation ist, die sich heutzutage nicht schlecht macht, wenn man sich als Entwickler irgendwo bewirbt. Etwa so, wie es nicht schaden kann, wenn man als Türsteher einer Rockerkneipe Arme hat. Die Fragestellung hat meiner Meinung nach allerdings einen schweren Fehler: Java lernt man nicht, indem man Java lernt, sondern indem man sich an gewisse Strukturen gewöhnt - und die sind erfreulicherweise für jede OO-Sprache von C++ über Java bis C# praktisch gleich.

Was empfehle ich diesen Leuten also? Eine Klinikpackung Valium (die werden sie auf jeden Fall brauchen) und ein paar Bücher, die nichts mit Java, dafür aber viel mit der richtigen Denke zu tun haben. Das erste Buch, das man sich auf dem Weg vom Gehacke zu sauberem Code reinpfeifen sollte, wäre dabei “Applying UML and Patterns” von Craig Larman - das bringt einem flockig geschrieben und mit einem schönen Beispielprojekt bei, wie UML in den Grundzügen funktioniert und wie man ein paar typische Probleme löst. Als nächstes sollte man sich dann mit “Entwurfsmuster - Elemente wiederverwendbarer Software” von Gamma, Helm und Johnson aufs Klo verziehen, um noch ein paar gute Musterlösungen kennenzulernen, bevor man mit “Entwurfsmuster anwenden” von Vlissides in der Badewanne verschwindet.

Nach der Lektüre empfehle ich dann übrigens einen Kasten Bier. Nicht speziell deshalb, weil das gut zu OO-Entwicklung passen würde, sondern einfach nur aus Prinzip - ich bin schließlich Bayer, und da während der Entstehung dieser Zeilen gerade die Wiesn im Gange ist, denke ich relativ viel an deutsche Braukunst. Man vergebe mir bitte, ich bin auch nur sowas ähnliches wie ein Mensch.

GEZ-Gebühren für Arbeitsmaterial sind bäbä!

Ach ja, die GEZ… Über die kann man geteilter Meinung sein. Ich bin ja persönlich der Ansicht, dass es gar nicht so verkehrt ist, ein paar nicht-kommerzielle Sender mit Gebühren zu finanzieren - ob ich das Programm dann besonders toll finde oder nicht, spielt da keine Rolle. Abgesehen davon will ich über selbiges Programm gar nicht mal meckern, weil ich mir doch ganz gerne mal die Tagesschau, irgendwelche spacigen Arte-Programme oder Bob Ross auf Alpha gebe.

Irgendwo muss aber Schluss mit der Gebührensaugerei sein, und für mich ist der Punkt bei Arbeitsplatzrechnern und insbesondere bei Servern definitiv erreicht. Aus diesem Grund möchte ich hier, ohne mich damit dem populären GEZ-Hass aus Prinzip anzuschließen, auf eine Unterschriftenaktion gegen den GEZ-Zwang für Arbeitsmaterial verweisen:

Ich möchte dabei festhalten, dass die Unterstützung für diese Aktion in diesem Fall rein vom SKYTEC-Entwicklerblog, genaugenommen von mir persönlich, ausgeht. Es handelt sich nicht um eine offizielle Firmenangelegenheit, sondern nur um einen Blogbeitrag, der zwar möglicherweise, aber keineswegs garantiert, das ausdrückt, was Firmenleitung und Kollegen so denken.

Remoting mit PHP und XML-RPC

Remoting ist toll - Server sprechen miteinander, ohne, dass man ihnen helfen muss. Dumm ist nur, dass man sich, wenn man aktuellen Trends folgt, performancemäßig durchaus nach der Seife bücken muss. Ich bitte um etwas Applaus für mein Wortspiel, über das ich länger nachgedacht habe, als es eigentlich verdient hätte. Wer nicht applaudiert, erweckt den Eindruck, es nicht verstanden zu haben, also steht gefälligst auf und erzeugt klatschende Geräusche, liebe Freude!

Wir haben also gerade schon festgehalten, dass SOAP manchmal etwas arg dick erscheint, und wenn man PHP benutzt, kommt man sich mit dieser Art von Fettwanst-Kommunikation sowieso etwas komisch vor. Auf der Suche nach schlankeren Alternativen im Internet stößt man schnell auf Kate Moss, sofern man Google mit einer suboptimalen Suchanfrage befüttert, oder aber auf XML-RPC, wenn man seine Frage halbwegs korrekt gestellt hat. Zwischendurch fragt man sich, ob der Autor dieser Zeilen einen Clown gefrühstückt hat und ob er neuerdings von Java auf PHP umgestiegen ist, was in beiden Fällen verneint werden muss. Er ist nur heute guter Dinge und spielt in einem Team mit, das derzeit ein größeres PHP-Projekt realisiert.

Zurück zum Thema, welches “Remoting mit PHP und XML-RPC” lautet. LErler hat ein nettes Tutorial bezüglich der Verwendung von XML-RPC mit PHP gefunden, das ich sofort nach Eingang der Hinweismail für blogwürdig hielt und Euch deshalb nicht vorenthalten will. Im selben Atemzug mit der Empfehlung dieses Artikels möchte ich übrigens hinweisen, dass ich beim Testen des PEAR-Moduls “XML_RPC2” die Hälfte meiner Haare ausgerupft habe und feststellen durfte, dass die verbliebene Hälfte die Farbe gut ausgeglühter Asche angenommen hat - die Verwendung dieser Erweiterung empfehle ich also ausschließlich Entwicklern mit erhöhter Schmerzresistenz und sehr laschen Deadlines.

PRADO: Fast schon Tapestry für PHP

Mann, bin ich froh, dass das hier kein Videoblog ist. Es wäre kein schöner Anblick, mich hysterisch kichernd zu erleben, mit einem kleinen Speichelfaden… Ich erspare Euch die grausigen Details und erkläre vielleicht lieber, was mich so ruiniert und mein Weltbild in Hinblick auf PHP stark genug angekratzt hat, um mich tatsächlich mal wieder für diese Sprache zu interessieren. Wie immer, wenn ich komisch reagiere, war es natürlich ein Framework, das diese Wirkung hatte. Ich bin einfach zu empfänglich für Software, fürchte ich.

Gerade jetzt bin ich nämlich dabei, mich durch die Dokumentation eines PHP-Entwicklungsframeworks namens “PRADO” zu wühlen, das CNovak hier eingeschleppt hat. Zunächst hat der Java-Snob in mir nur müde gelächelt, aber spätestens zu dem Zeitpunkt, als mir klar wurde, dass ich gerade sowas ähnliches wie Tapestry für PHP vor mir habe, wich die Müdigkeit einer gewissen Begeisterung. Sollte man mit diesem Dingsbums etwa wirkliche Software in PHP entwickeln können? Software, die sich halbwegs warten lässt? Es scheint fast so, und das schockiert mich ein Bisschen.

Ich empfehle jedenfalls jedem, der sich mit größeren PHP-Projekten beschäftigen darf, soll oder muss, mal einen Blick auf das HelloWorld-Beispiel aus der Doku zu werfen - mit dem üblichen wilden Rumgehacke, das man sonst von PHP kennt, hat das nämlich wirklich erstaunlich wenig zu tun. Wenn es jetzt noch eine PHP-Entsprechung zu Servlets gäbe, so dass der ganze Ranz nicht ständig neu initialisiert werden müsste… OK, ich will mal auf dem Teppich bleiben. Ganz so weit sind wir dann halt doch noch nicht.

Benutzerverwaltung mit LiveUser

Im Moment qualmen bei uns die Tastaturen (und Köpfe) der Konzeptschreiber, weil wir eine ziemlich dicke Anwendung planen, die ausnahmsweise mal nicht in Java, sondern in PHP gebaut werden soll. Die Zeit ist, wie immer in der IT, mächtig knapp, und so versuchen wir natürlich, fertige Sachen zu verwenden, wo es nur irgendwie geht. Bei der Auswahl passender Tools sind wir auf etwas gestoßen, das ich hier mal erwähnen möchte, weil es mir wirklich gut gefallen hat: Das PEAR-Paket “LiveUser”, mit dem man wirklich ziemlich bequem reichlich komplexe Berechtigungssysteme und Benutzerverwaltungen umsetzen kann. Klar, sowas kann man auch selber bauen, nur muss man dann auch Tests und Doku schreiben - und wer würde schon von sich behaupten, dass er gerne für diese Tasks Überstunden schiebt?

Die Doku für das Teil ist zwar nicht gerade schlecht, aber bekanntlich gibt es immer noch irgendwas, was befriedigender als der Mitgelieferte Kram ist - in diesem Fall beispielsweise die ziemlich gute Einführung in LiveUser, die LErler im lauf der Recherche ausgegraben hat. Da steht alles nochmal schön übersichtlich drin, und Bilder gibt’s auch - als Startpunkt für die Einarbeitung dürfte das also wohl genau das Richtige sein.

Wissenswertes über Generics

Haare sind, da bin ich mit meinem Katerchen und seiner felligen Schwester völlig einer Meinung, eine ziemlich tolle Erfindung. Sie sind nicht nur durchaus kleidsam, nein - sie halten einem im Winter auch das Hirn warm, was ich bisher immer sehr zu schätzen wusste. Es ist diese Liebe zu meinen Haaren, wegen der ich bisher die Arbeit mit Java Generics doch lieber den Kollegen überlassen habe - erste Experimente zeigten mir nämlich, dass diese Spracherweiterung durchaus das Potenzial hat, zu heftigen Haarausrissaktionen zu führen.

Nun bin ich nicht der einzige, der seinen Schopf schätzt. Auch mein Kollege MHenze findet sein Fell total gut, und er kommt um Generics nicht herum. Aus diesem Grund hat er sich eine umfangreiche FAQ zu Java Generics gesucht, die seiner Aussage nach den kahlen Stellen am Kopf durchaus vorzubeugen vermag. Löblicherweise hat er nicht nur gesucht und gefunden, sondern auch gemeldet - und so kommt Ihr jetzt alle in den Genuss dieser Glatzenvorbeugung für Java-Entwickler. Als kleinen Nebeneffekt bekommen wir so übrigens auch eine Entspannung auf dem Arbeitsmarkt, weil wir nicht mit Horden marodierender Friseure ohne Betätigungsfeld rechnen müssen.

Monitoring von Spring-Applikationen

Woher komme ich? Wohin gehe ich? Und wie wirkt sich das auf meine dumme Webapplikation aus, die irgendwie nicht dahin geht, wo sie hingehen soll? Existenziellere Fragen kann es im Leben eines Webentwicklers kaum geben, daran ändert auch Spring, jene eierlegende Wollmilchsau des modernen Java-Alltags nicht viel. Gelegentlich hilft einem ja wenigstens der Debugger, aber wenn man keine Lust hat, sich durch 1000 Controller zu steppen, sorgt auch der oft eher für Frust.

Eine mögliche Lösung des Problems, zumindest aber ein nettes Spielzeug, dessen Nutzen man irgendwann schon genauer erkennen wird, dürfte der Spring-Monitor namens “Spring Dashboard” sein, von dem mir MHenze heute berichtet hat. Die Software wird einfach statt des normalen Dispatcher-Servlets in eine beliebige Spring-MVC-Anwendung eingeklemmt, schon sieht man ganz genau, was so vorgeht, und kann auch schöne Daten über das Applikationsverhalten sammeln. Komfortabler dürfte wohl nur ein Praktikant sein, dem man den Debugger aufs Auge drückt, während man sich selbst wichtigeren Aufgaben wie der Espresso-Maschine zuwendet.

Einfach Sourcen mit Highlights exportieren

Kollege ABraun hat heute ein wirklich feines Tool gefunden, nämlich einen Spezialeditor für das Highlighten von Sourcen und den Export der so verzierten Textdaten - wer schon mal versucht hat, für seine Dokumentation vernünftige Source-Listings in Microsoft Word und Konsorten zu bringen, wird an dieser Stelle erleichtert aufatmen und nie wieder von Hand formatieren…

Um den Featureumfang kurz zu umreißen: Man kann sich beliebige Highlighting-Lexer basteln und die Ergebnisse als HTML oder RTF exportieren. Alles andere ist nur Beiwerk, wie ich finde… Allerdings gebe ich zu, dass ich für alles, was mein IDEA erkennt, doch lieber das Copy-As-HTML-Feature jener besten Java-IDE aller Zeiten verwende.

Eine kurze Anmerkung für alle, die das Wort “Dokumentation” nicht in ihrem aktiven Wortschatz finden konnten: Das ist das, was man immer für seinen Code machen sollte, weil man sonst früher oder später Stress mit dem Kunden kriegt oder am eigenen Code verzweifelt. Will man ja nicht unbedingt, oder?