Skytecs Entwicklerblog

Komponentenfehler

Am Anfang war die Komponente, und der Entwickler wusste, dass sie ein Hammer war. Von da an sah alles in der Welt einem Nagel sehr ähnlich.

Der erste Satz beschreibt ein Problem bei der Arbeit mit Komponenten, also wiederverwendbaren, extern konfigurierbaren Dienstklassen, die lose an die Clients und anderen Komponenten gebunden werden, um möglichst wiederverwendbar zu sein. Spring-Beans, wenn man so will. Das Hammer-Nagel-Problem ist aber nicht die einzige Klippe, die es bei der Implementierung komponentenorientierter Architekturen zu umschiffen gilt.

Von OBlume habe ich einen Artikel über die 10 typischen Fehler bei der Verwendung von Komponenten zugeschickt bekommen, der so manchen Jünger des Komponentenbooms (und dazu zähle ich auch mich selbst) nachdenklich machen sollte. Schließlich dürfte jeder in der Zielgruppe mindestens 4 der Fehler schon selbst begangen haben, und damit werden die anderen 6 automatisch zu wertvollen Beispielen für Dinge, die man in der Zukunft besser unterlassen sollte.

Alternative XML-Verarbeitung mit VTD-XML

DOM und SAX sind als XML-APIs jetzt schon so lange an unserer Seite, dass man sich nur schwer vorstellen kann, dass es auch anders gehen könnte. Mit den Einschränkungen der Parsingmethoden hat man zu leben gelernt - DOM frisst nunmal Speicher wie amerikanische Protzkarren das Benzin, und wer sparen muss, muss halt unter von SAX zerfetzten Programmstrukturen leiden. Das ist Programmiererschicksal, und so wird es immer sein. Oder etwa nicht?

OBlume hat mich auf eine sehr interessante Alternativtechnologie für das Parsen von XML namens “VTD-XML” aufmerksam gemacht, die das Schicksal verändern könnte, falls sie hält, was sie verspricht. Der Trick ist dabei, dass die Dokumente nicht in viele kleine Objekte zergliedert werden, wie es bei SDOM der Fall ist, sondern zusammen mit einem Index unverändert im Speicher stehen. Vom Ansatz her kommt das näher an eine In-Memory-Datenbank für XML als an einen normalen Parser heran - und die Vorteile scheinen recht erheblich zu sein, wenn man dem verlinkten Artikel einfach mal Glauben schenkt.

Hauptnachteil von VTD-XML scheint mir derzeit zu sein, dass keine Schemavalidierung unterstützt wird. Dieses Feature ist zwar geplant, aber ich habe die Vermutung, dass viele Vorteile des Systems diese Erweiterung nicht oder nur eingeschränkt überleben werden. Dafür wird immerhin XPath unterstützt, was das Verfahren für viele Anwendungen, die ohne Validierungen auskommen, ausgesprochen nützlich erscheinen lässt. Insgesamt sollte man die Sache jedenfalls im Auge behalten.

Regulär ausgedrückt

Reguläre Ausdrücke sind nicht weniger als das schweizer Taschenmesser des Softwareentwicklers. Von der Prüfung von Eingaben bis hin zur Analyse von Logfiles gibt es nur wenige Aufgaben im Bereich der Stringverarbeitung, für die man diese für den Laien leicht kryptisch anmutenden Ausdrücke nicht sehr gut gebrauchen könnte. Der Umstand, dass diese Biester nicht wirklich gut lesbar sind, schreckt allerdings viele Entwickler erstmal ab - zu unrecht, wie ich finde.

Wenn man nämlich erstmal verstanden hat, wie die “RegExe” funktionieren, geht eigentlich alles ganz einfach, wenn man von gelegentlichen Knoten im Hirn absieht. Für genau dieses erste Verständnis sehr nützlich ist das umfangreiche Tutorial zur Verwendung regulärer Ausdrücke, das ich heute im Netz gefunden habe. Genau deshalb rufe ich zum Anlegen eines Bookmarks auf und weise zusätzlich darauf hin, dass es für die Freunde des gedruckten Wortes auch ein Pflichtbuch zum Thema gibt, das allerdings den offensichtlichen Nachteil hat, nicht kostenlos zu sein.

SWT, AWT und SWING

Wenn man GUI-Applikationen in Java schreibt, steht man bei der Wahl des GUI-Toolkits vor einer umfangreichen Auswahl von nicht weniger als 3 APIs, zwischen denen man sich entscheiden muss. In den meisten Standardfällen wird man wohl sofort zu SWING greifen, aber AWT und SWT gibt es ja auch noch - und es gibt Gründe, um nochmal über das gewählte Framework nachzudenken, bevor man mit der Codierung beginnt. Gründe, die einem normalerweise allerdings nicht spontan einfallen.

In solchen Entscheidungssituationen könnte der umfangreiche Vergleich der Features von AWT, SWT und SWING bei IBM, den ich gefunden habe, durchaus hilfreich sein. Immerhin bekommt man hier durch die Vergleichsmatrix eine kleine Checkliste geliefert, die man mal eben mit seinen Anforderungen abgleichen kann, um das gute Gefühl zu bekommen, dass man anhand von relevanten Fakten entschieden hat.

Falls man bei der Wahl der Waffen bei SWT gelandet sein sollte, kann man ja noch einen Blick auf den von MHenze aufgefundenen Artikel über die Nachteile von SWT werfen. Falls man danach immer noch bei seiner Wahl bleibt, kann man sich wenigstens sicher sein, alle potenziellen Probleme einmal angedacht zu haben.

Logausgaben über Instant Messaging

Instant Messaging ist als Kommunikationsmittel im privaten Bereich dank ICQ hinreichend etabliert und setzt sich dank freier Produkte wie Jabber langsam auch als Werkzeug zur Bürokommunikation durch. So ein Jabber-Server ist schließlich schnell installiert, und eine einfachere Möglichkeit um schnelle Fragen auszutauschen oder Sourcecodeschnipsel durch die Gegend zu schicken, gibt es praktisch nicht.

Jabber bzw. das zugrunde liegende XMP-Protokoll eignen sich aber auch für ganz andere Anwendungen als die reine Mensch-zu-Mensch-Kommunikation. Beispielsweise kann man sich automatisiert von einem Rechner über das Eintreten gewisser Ereignisse informieren lassen - und wie könnte man das besser tun, als wenn man Logausgaben des überwachten Systems über Jabber ausliefern lässt?

Bei IBm habe ich einen nicht wirklich neuen, dafür aber immer noch aktuellen Artikel über die Kopplung von log4j und Jabber gefunden, der genau diese Vorgehensweise beschreibt. Die Anwendungszwecke scheinen mir sehr weitreichend zu sein - von der Funktionsüberwachung diverser Webapplikationen bis hin zum automatisierten Melden von Problemen in Desktop-Anwendungen ist hier vieles denkbar. Wer mit Logging arbeitet (also jeder gute Entwickler) sollte mal einen Blick auf den Artikel geworfen haben.

Der pragmatische Weg zum Unit-Test

Unit-Tests sind ein guter Weg, um Software robust zu halten und eine zumindest für Entwickler brauchbare Dokumentation zu schaffen - da ein guter Test alle relevanten Funktionen und Annahmen einer Klasse prüft, stellt er automatisch ein geeignetes Sourcecodebeispiel dar, anhand dessen man die Funktion der getesten Klasse prüfen kann.

In diesem Artikel soll beschrieben werden, wie man Unit-Tests so ansetzen kann, dass sie tatsächlich einen Mehrwert bringen, dabei aber keine überproportionalen Aufwände erzeugen, die in einem regulären Projekt nicht tragbar wären.

Continue reading Der pragmatische Weg zum Unit-Test…

Kaffee und Kekse: Cookie-Handling in Java

Mit den Details der Cookieverwaltung schlägt man sich ja als Entwickler eher selten herum, sofern man nicht einen Webbrowser oder einen Application-Server schreibt. Manchmal passiert es aber doch, dass man sich selbst um die gefürchteten http-Header kümmern muss, und dann fehlt es oft an Informationen.

In so einem Fall wird man sich freuen, wenn man die Anleitung zum Umgang mit Cookies in Java in seinen Bookmarks wiederfindet, die PRogalinski mir geschickt hat. Sofern man das JDK 1.4 verwendet, wird man zusätzlich auch mit einem kleinen Hinweis auf die Benutzung von Proxies am Ende des Texts erfreut, der allerdings die neue (und weit komfortablere) Methode aus dem JDK 1.5 nicht erwähnt - macht aber nichts, die ist nämlich in der offiziellen Anleitung zum Proxy-Support bei Sun beschrieben.

Das V-Modell XT als neuer Standard für öffentliche Projektarbeit

Für den Staat zu entwickeln ist eine gute Sache - langfristig laufende Projekte und interessante Folgeaufträge sorgen für eine gewisse Beliebtheit solcher Entwicklungsjobs. Um an die Aufträge zu kommen, muss man sich allerdings mit ein paar Vorgaben auseinandersetzen, die vom Auftraggeber spezifiziert werden.

Eine solche Vorgabe ist das Vorgehensmodell, nach dem man arbeitet. Aktuell ist hier das “V-Modell XT”, das durch die Empfehlung der KBSt zum De-Facto-Standard für Aufträge im deutschen Behördenbereich geworden ist und somit das klassische V-Modell ablöst.

Alles, was man zum Modell wissen muss, findet man im Portal zum neuen V-Modell - auch Software wie den Projektassistenten und den Modell-Editor, die bei der Anwendung des Modells sehr hilfreich sind. Erfreulicherweise sind beide Tools als Open-Source-Software freigegeben, so dass man für den schnellen Einstieg keine Lizenzkosten einplanen muss.

Java und die Pixelbilder

Egal, ob man für den Server oder den Desktop programmiert - früher oder später wird man immer mit der Anforderung konfrontiert, dass man irgendwelche Bitmap-Bilder einlesen und verarbeiten muss. Bei manchen Formaten ist das nicht so wild, bei manchen kann die Aufgabe aber für graue Haare sorgen.

Um das vorzeitige Ergrauen der Kollegen zu verhindern, hat PRogalinski mir eine Liste mit Libraries zur Verarbeitung von Pixel-Bildformaten in Java geschickt, die sowohl den quelloffenen als auch den kommerziellen Bereich abdeckt und definitiv in die Bookmarks jedes Java-Entwicklers gehört.

Quickstart für ACEGI

Sobald eine Website einen gewissen Grad an Dynamik gewinnt, reicht die J2EE-Security meist nicht mehr aus - abgesehen davon ist die Implementierungen von JAAS-Plugins eine reichlich komplizierte Angelegenheit, die man gerne vermeidet, wenn es irgendwie geht. Für Websites, die auf Spring basieren, gibt es allerdings eine gute Alternative namens ACEGI - dabei handelt es sich um ein Framework, das so ziemlich alle Anforderungen abdeckt und eigentlich recht einfach zu handhaben ist.

“Eigentlich gut zu handhaben” soll bedeuten, dass das Framework zwar gut dokumentiert ist, man jedoch recht schwer einen Einstieg findet, wenn man sich nicht auskennt. Dieses Problem wird jedoch von dem Einsteigertutorial zu ACEGI, auf das mich PFuchs aufmerksam gemacht hat, recht gut gelöst. Wer sich mit Sicherheit in Spring-basierten Applikationen auseinandersetzen muss, sollte sich das Tutorial auf jeden Fall einmal angesehen haben, bevor er anfängt, Berechtigungen in der web.xml zu definieren oder sogar ein eigenes Framework zu stricken.