Dies ist die Heimat der Java User Group Nürnberg.


Dienstag, 1. Dezember 2009

[JUG] Treffen 10.12.2009 bei der KQV Nürnberg, 3 Themen

Hallo zusammen,

das nächste JUG-Treffen findet am 10.12.2009, 18:30-20h statt.

Ort:
KarstadtQuelle Versicherungen
Karl-Martell-Straße 60
90431 Nürnberg

Diesmal gibt es drei Vorträge:

Thema: GWT 2.0  (ca. 15 Minuten)
Referent: Alexander Willhaug

Thema: Unittest mit OpenEJB (ca. 30 Minuten)
Referent: Thorsten Wärte

Thema: Java 7 (Restliche Zeit :))
Referent: Oliver Szymanski

Anmeldung ist bis Dienstag, 2009-12-08 12:00 Uhr erforderlich. Bitte
dazu eine eMail an oliver.szymanski@source-knights.com senden (oder in
der Xing-Gruppe anmelden).

NEU: Ich habe auch eine Google-Wave zur JUG angelegt, wer dazu zum
Mittesten eingeladen werden will darf mich gern kontaktieren.

Beste Grüße,
Oliver


Um sich am Newsletter anzumelden bitte eine eMail mit dem Betreff
"subscribe JUG" an jug@source-knights.com senden.
Um sich am Newsletter abzumelden bitte eine eMail mit dem Betreff
"unsubscribe JUG" an jug@source-knights.com senden.

Mittwoch, 18. November 2009

FinalCountdown iPhone-App

FinalCountdown is the new iPhone app for watching the countdown to a chosen date/time in all timezones.

E.g. with FinalCountdown you can follow the New Year's Eve all over the world in different time zone. Or you can lookup where in the world your birthday can be celebrated first.

Very useful also if you want to launch something worldwide at a special date so you can watch when the next timezone is ready for your launch.

Dienstag, 3. November 2009

JSXP (Just Simple eXtensible Pages)


JSXP: Web-Applikationen entwickeln – wie es sein sollte
JSXP steht für Just Simple eXtensible Pages[1] und ist ein frisch veröffentlichtes Open Source Framework für Web-Applikationen in Java. Unter [2] findet  man einen Screencast, der zeigt, wie man eine Newsletter-Web-Applikationen mit JSXP implementiert.
Warum ein neues Web-Framework? Als David Tanzer und ich im Februar dieses Jahres bei den JSFDays[3] in Wien waren, haben wir mit Entwicklern der JSF-Technologie darüber gesprochen, dass JSF zu kompliziert ist. Immer noch, denn verbessert hat sich die Situation selbst mit JSF2 nicht.
Leider stieß diese Ansicht, die ich in unserer Branche bei den Entwicklern, die mit JSF oder anderen Technologien arbeiten (müssen), bei den Erschaffern der bestehenden Technologien nicht auf Gehör. Auf der Fahrt zurück diskutierten David und ich fleissig. Wir waren uns einig, dass Apache Wicket einige gute Ansätze hat, aber das es unserer Meinung nach immer noch nicht die Probleme bei der Web-Frontend-Entwicklung löst.
Wir wollten zum einen Compile-Time-Safety und eine striktere Trennung von Design und Code, als man dies bislang im Java-Bereich gesehen hat. Die Diskussion endete damit, dass es schön wäre einen Proof-Of-Concept zu haben. In der folgenden Nacht schrieb ich die erste Version des JSXP-Frameworks, von der heute in dieser Form wohl keine Code-Zeile mehr übrig ist. Aber der Weg war geebnet. Nach dem Feedback zur ersten Live-Demo von JSXP auf der Herbstcampus[4] und weiteren sehr positiven Kritiken aller, denen wir JSXP vorstellten, ist das Framework längst nicht mehr nur ein Proof-Of-Concepts. Es ist eine ernst zu nehmende Möglichkeit Webauftritte in Java zu realisieren.
Bleibt die Eingangs erwähnte Frage: Warum ein neues Web-Framework? Diese Frage musste ich mir in einer frühen Phase von JSXP von einem Entwickler der JSF-Technologie stellen lassen, als ich ihm unser Konzept vorstellte
. Er fügte hinzu, dass es unsinnig und verlorene Zeit sei etwas zu entwickeln, was es schon gibt. Meine Antwort darauf ist folgende: es ist bezeichnend, wenn Menschen etwas neu entwickeln müssen, obwohl es bereits einen Ansatz gibt.
Was kann und bietet JSXP?
JSXP hat als realisierte Ziele von Anfang an Einfachheit und Sicherheit in der Anwendung. Zwar ist es äußert flexibel und bietet alle Features, die man aus Technologien wie JSF kennt, aber bei der Gestaltung des JSXP-Frameworks wurde die API stets auf Nutzerfreundlichkeit optimiert.
Zentrale Bestandteile einer JSXP-Webanwendung sind Design-Views, View-Controller, Applikationsklasse und Context. Design-Views ist dabei die Bezeichnung für das Design (z.B. XHTML-Dateien), View-Controller sind Java-Klassen die den Code hinter dem Design implementieren. Jedes JSXP-Webprojekt hat eine Applikationsklasse, die grundlegende Einstellungen und Algorithmen für die Applikation vorgibt. Der Context ist ein überall im JSXP-Projekt verfügbares Objekt, in dem man u.a. Informationen über den aktuellen Requests, diverse Einstellungen, Benutzerinformationen findet.
JSXP-Webanwendungen sind Design-Driven. Designer liefern das Design. Per Default in Form von XHTML-Dateien, aber dank des realisierten Factory-Patterns ist es möglich, auch jede andere Art von Eingabe (z.B. aus der DB) und Form des Design (z.B. XAML von Silverlight, oder jedes beliebige Format) zu nutzen, wenn man die Schnittstellen dann entsprechend implementiert. Im Folgenden beschränken wir uns bei den Beispielen auf das vom Standard direkt unterstützte Design per XHTML.
Das gelieferte Design wird bei JSXP-Webanwendungen nicht mit Code verunstaltet, die XHTML-Dateien bleiben im Browser u.a. zum Preview nutzbar. JSXP hält sich dabei an die strikte Trennung von Design und Code. Dies ermöglicht, Design in den Softwareentwicklungsprozess erfolgreich zu integrieren. Ein Designer kann das Design iterativ anpassen, es entstehen keine Inkonsistenzen. Der Designer kann direkten Zugriff auf die Versionsverwaltung bekommen und Design dort einchecken und verändern.
Ein per Shell aufrufbarer Generator
 generiert zu den Design-Views (im Standard eine XHTML-Datei) einen View-Controller. Die generierte Klasse selbst wird nie editiert. Man kann von ihr ableiten und die Subklasse anpassen. Dies verhindert Probleme im iterativen Prozess bei erneuter Generierung. Die generierten Klassen enthalten spezielle get- und set-Methoden für den Zugriff auf das Design und ermöglichen Templating und das ersetzen/einfügen von Texten und Elementen. Dank der generierten Methoden/Eigenschaften kann bereits zur Compile-Zeit festgestellt werden, ob sich eine Design derart verändert hat, dass der selbst implementierte Code nachgebessert werden muss. Auf dieses Compile-Time-Safety Feature wird man nicht mehr verzichten wollen, wenn man nach einem Tippfehler im Design direkt auf den Fehler hingewiesen wird, und dies nicht erst zur Laufzeit „um die Ohren gehauen“ bekommt. Auch wenn im Code benötigte Elemente umbenannt oder gelöscht werden, bekommt man sofortiges Feedback.
Das Paar von Design-View und View-Controller bildet in JSXP eine View-Komponente. Im Normalfall gehört genau eine View-Controller-Klasse zu einem Design-View. Diese Komponenten können wiederverwendet werden und man kann aus den Komponenten andere Views zusammen bauen. Innerhalb eines View-Controllers kann man andere Komponenten importieren und nutzen. JSXP ist damit Komponenten-basiert. Das Definieren und der Zugriff auf Komponenten geschieht dabei im Java-Code, nicht im Design.
Zur Laufzeit löst das JSXP-Framework eine URL auf, um benötigte View-Controller zu finden (oder Resource-Dateien direkt auszuliefern). Die Applikationsklasse wird genutzt um zu prüfen, ob evtl. Weiterleitungen notwendig sind oder Sicherheitseinschränkungen vorliegen (Login notwendig, etc.). Beim Zugriff auf einen JSXP-View wird der zugehörige View-Controller initialisiert. Dieser unterliegt dann einem bestimmten Lebenszyklus auf dessen Phasen im View-Controller selbst durch Überschreiben von Methoden oder von beliebiger Stelle per Registrierung von Phase-Listenern reagiert werden kann. Ein Beispielablauf der Phasen ist: Vorbereiten, Initialisierung, Eingabe-Parameter setzen, Validierung der Eingabe-Parameter, Ausführung, Templating, Resourcen-Handling, Variablenersetzung, Rendering,
Wie funktioniert der Zugriff auf Design-Elemente bei Beachtung von Separierung von Code und Design? Gerade bei diesem Feature von JSXP wird man seine Vorteile in Bezug auf Apache Wicket spüren, denn JSXP verfolgt das Prinzip der Separierung weit strikter. In den XHTML-Dateien muss man Elementen lediglich eine JSXP-ID geben und entsprechende Methoden/Eigenschaften werden generiert. JSXP-IDs sind im XHTML Tag-Attribute aus einem bestimmten Namensraum. JSXP kennt dabei keine HTML-Tags, es kennt lediglich View-Elemente. Es weiss nicht, ob es sich z.B. dahinter um eine Liste handelt oder um strukturierte DIV-Blöcke. Es muss auch die Verschachtelung von Elementen nicht kennen, da die IDs eindeutig sind. Dies führt dazu, dass man folgenden Design-Ausschnitt ändern kann, ohne das JSXP falsch reagieren wird:
Beispiel: per JSXP-ID referenzierbare Design-Elemente im Design-View
<head>
<title>Hello World</title>
</head>
<body>
<div jsxp:id="Name">Name
<p jsxp:id="Address">Adresse</p>
</div>
</body>
</html>
Hier werden am entsprechenden View-Controller „getElementName“ und „getElementAddress“ als Methoden generiert, die jeweils generierte Elemente von „Name“ und „Address“ typsicher zurückgeben (man beachte, dass spezielle Elemente für diese IDs als Interfaces generiert werden, aber dass es DIV-Elemente sind braucht JSXP nicht zu wissen). Und am Element „Name“ wird eine Methode „getElementAddress“ generiert. 
Per Code kann man wie folgt auf die Elemente zugreifen:
Name nameElement = getElementName();
Address addressElement = getElementAddress();
Element sameAddressElement = getElementName().getElementAddress();
Name und Address sind Implementierungen des allgemeinen Interfaces „Element“. Im Beispiel sind „addressElement“ und „sameAddressElement“ identisch. Je nachdem ob man Zeile 2 oder Zeile 3 aus dem Beispiel benutzt, ist folgende Designänderung kompatibel oder erzeugt einen Compile-Zeit-Fehler:
Beispiel: Änderung der Verschachtelung im Design
<div jsxp:id="Address">Adresse
<p jsxp:id="Name">Name</p>
</div>
Nur in Fällen, wo eine Verschachtelung im Design wichtig für den Code ist, benutzt man in JSXP also den verschachtelten Zugriff.
Mit den JSXP-IDs kann man Elemente aus dem Design-View referenzieren. Man kann auch Variablen im Design nutzen, um komfortabel Inhalte auszutauschen. Dazu benutzt man die $(Variablenname)-Notation an beliebiger Stelle im Design. Variablen werden dabei stets zu dem nächsthöheren per JSXP-ID angegebenen Element generiert.
Beispiel: Variablen
<div jsxp:id="Name">$(firstName)$(lastName)
<p jsxp:id="Address">$(street)</p>
</div> 
In dem Variablen-Beispiel gibt es generierte Methoden zum Auslesen und Setzen der „firstName“ und „lastName“ Variablen am Element „Name“ und für die Variable „street“ am Element „Address“.
Beispiel: Methoden passend zu den Variablen
getElementAddress().setVariableStreet(String value);
getElementName().setVariableFirstName(String value); 
getElementName().setVariableLastName(String value);
Auf diese Weise kann man mit JSXP Variablen nutzen und ist dennoch Compile-Zeit-sicher. Bei der Angabe der Variablennamen in der $-Notation unterstützt JSXP wohlweislich keine Expression-Language. Eine Query-Language würde den JSXP-Richtlinien zur Typsicherheit und der Konsistenz von Design und Code widersprechen. Möchte man allerdings sicherstellen, dass eine Variable zu einem bestimmten Element gehört oder zum View-Controller direkt, kann man dies durch einen Punkt notieren.
Beispiel: Weitere Variablennotation
<div jsxp:id“customer“>
<div jsxp:id=“order“>
<div jsxp:id=“billingAddress“>$(customer.name) $(street)</div>
<div jsxp:id=“deliveryAddress“>$(customer.name) $(street)</div>
</div>
</div>
In diesem Beispiel gibt es jeweils eine Variable „street“ an den Elementen „billingAddress“ und „deliveryAddress“ und eine Variable „name“ am Element „customer“. Benutzt man nur „$(.name)“ wird die Variable direkt an dem View-Controller generiert und ist damit für die gesamte View gültig.
JSXP erlaubt es dem Designer voll funktionsfähige Designs zu liefern. Die XHTML-Dateien können navigierbar sein und bereits mit Daten aufgefüllte Listen zu Demonstrationszwecken haben. Der Entwickler muss diese Listen nicht in den Design-Dateien leeren. Er tut dies dort, wo man es von einem Java-Entwickler erwartet: im Java-Code. Dies hat zur Folge, dass die Anwendung direkt nach dem Einfügen der Design-Views funktioniert und Prototyping möglich macht. Dies sieht man auch in dem Video-Screencast [2]. Man integriert die Design-Dateien in sein Projekt und kann die Webanwendung direkt nutzen und iterativ den Code und somit die dynamische Funktionalität implementieren. Dies bedeutet, dass die Design-Dateien stets auch losgelöst vom Webserver im Browser angeschaut und Designer und Entwickler in einem iterativen Prozess an den gleichen Dateien arbeiten können.
Beispiel: vereinfachte Tabelle vom Designer (Ausschnitt aus XHTML-Datei)
<table>
<tr>
<td>12345</td><td>07.02.2009</td>
</tr>
<tr>
<td>45678</td><td>11.10.2009</td>
</tr>
</table>
Nehmen wir an, die oben angegebene Tabelle wurde vom Designer geliefert. Diese Tabelle kann der Entwickler im nächsten Schritt für JSXP anpassen, ohne das Design zu ändern oder die Beispieldaten zu entfernen.
Beispiel: Tabelle nach Anpassung durch Entwickler
<head>
<title>Hello World</title>
</head>
<body>
<table jsxp:id="orderList">
<tr>
<td>12345</td><td>07.02.2009</td>
</tr>
<tr>
<td>45678</td><td>11.10.2009</td>
</tr>
<tr jsxp:id="orderItem">
<td>$(orderNo)</td><td>$(orderDate)</td>
</tr>
</table>
</body>
</html>
Per Code leert der Entwickler nun die Liste aus dem Design und benutzt die hinzugefügte Zeile für Element-Templating. In JSXP kann man Elemente aus dem Design als Template verwenden und so wiederholt als Struktur einfügen.
Beispiel: Code des View-Controller zum Table-Beispiel
public class TableXhtmlController extends TableXhtmlControllerGenerated<Object> {
@Override
public void execute() throws Exception {
getElementOrderList().removeElements();
ElementTemplate<OrderItem> itemTemplate = 
getElementOrderItem().createTemplate();
List<Order> orderList = ...; /* Business-Logik */
for (Order order : orderList) {
OrderItem orderItem = itemTemplate.createElement(order);
getElementOrderList().addElement(orderItem);
}
}
}
Die „execute“-Methode aus dem Beispiel wird vom JSXP-Framework im Zuge des Lebenszyklus eines Request aufgerufen, wenn die „Table“-Komponente Teil des Views ist, der zu einem Request gerendert wird. Hier wird also erst die Liste aus dem Design geleert, womit die Beispielinhalte verfallen. Danach wird aus dem „orderItem“-Element ein Template erzeugt, dass genutzt wird um Orderobjekte für die View aufzubereiten. Die „createElement“-Methode erzeugt dabei innerhalb der Schleife das konkrete Element zu für die Antwort auf den eingehebenden Browserrequest. Übergibt man der „createElement“-Methode ein Objekt, wird automatisch mit den an dem Objekt vorhandenen Properties versucht, die Variablen des Elements zu setzen. Alternativ hätte man die Variablen auch manuell setzen können: 
orderItem.setVariableOrderNo(value);
orderItem.setVariableOrderDate(value);
Wichtig an dieser Stelle ist, dass man im Code nicht merkt, dass es sich im Design um eine Tabelle handelt. Ändert sich das Design und wird die Tabelle z.B. durch eine DIV-Struktur oder einfache Textzeilen ersetzt, ändert sich der Code nicht. Code und Design sind unabhängig. Fällt eine JSXP-ID bei Bearbeitung durch den Designer weg, gibt es einen Kompilierungsfehler. So wird man bereits in der IDE gewarnt.
Will man zu der Tabelle einen Pager einbauen, der erlaubt in der Liste zu Blättern, ist es möglich eine Pager-Komponente zu importieren und zu nutzen. Im vorherigen Beispiel können wir dies durch das Überschreiben der „init“-Methode des View-Controllers tun:
@Override
public void init(Importer importer) throws Exception {
PagerXhtmlController pager = new PagerXhtmlController();
pager.setPageSize(20);
importer.importView(pager);
getElementOrderList().addElement(pager.getElementSimplePager());
}
Auf diese Art lassen sich beliebige fertige oder selbst entwickelte View-Komponenten importieren und direkt integrieren oder per Templating-Mechanismen nutzen. Und im Gegensatz zu JSF sind hier die Schnittstellen der Komponenten in der Sprache der Entwickler hinterlegt: Java. Der Designer wird nicht mit zusätzlichen ihm unbekannten Konstrukten belästigt.
In JSXP sind URLs direkt lesezeichenfähig (Bookmarkable) und vom Menschen lesbar (Human-readable-URLs). Dies wird beides auch bei Redirects unterstützt. Die Unterstützung hierfür ist bei anderen Webframeworks recht dürftig oder nur sehr schwierig umsetzbar. Selbst in Zusammenhang mit Internationalisierung oder Resourcenhandling sind keine komplizierten URIs notwendig (wie in JSF2). I
Internationalisierung wird von Haus aus unterstützt. Dabei kann durch die Applikationsklasse angegeben werden, welche Locales die Anwendung unterstützt, und per Default ermittelt JSXP, welche der Locales am besten zum User passt. Danach werden zum einen entsprechende Locale-Verzeichnisse für Design und Code genutzt, als auch das Locale am Context gesetzt, so dass man es beim Resourcenhandling nutzen kann.
Mit Resourcenhandlung kann man Elemente aus der View an Resourcen binden und die Elemente dadurch unterschiedlich füllen als auch austauschen. Dies ist zum Beispiel für Texte innerhalb eines Views nützlich, der aus Java Resource-Bundles kommen soll, oder für Bilder oder Skripte die aus unterschiedlichen Quellen stammen, für die der Designer aber im Design einen statischen Pfad benötigt. Beim Resourcenhandling definiert man durch Überschreiben der Methode „getResources“ welche mit einer JSXP-ID versehen Elemente des Designs zu einer Resource gehören. Man kann dann ResourceHandler an der Applikation definieren (im Standard sind bereits einige vorgesehen) die das Element je nach Resourcen-Typ unterschiedlich für die Antwort zum Client rendern. Im folgenden Beispiel sieht man ein Element im Design, dessen Inhalt durch das Resourcehandling automatisch vom JSXP-Framework durch die Inhalte aus einer Java-Properties-Datei ausgetauscht werden.
Beispiel: Resourcenhandling Designausschnitt
<body>
<p jsxp:id="resourcebundle">
Hello <br/> $(name)
</p>
</body>
</html>
Beispiel: Resourcenhandling View-Controller
public class ResourceBundleXhtmlController extends ResourceBundleXhtmlControllerGenerated<Object> {
@Override
public void execute() {
getElementResourcebundle().setVariableName("Snoopy");
}
@Override
public List<Resource> getResources() {
List<Resource> resources = super.getResources();
resources.add(new Resource(
"ResourceBundlePropertiesFileURL",
"text/resourcebundle", getElementResourcebundle()));
return resources;
}
}
Beispiel: Resourcenhandling Properties-Datei
resourcebundle[]=Hallo|$(name)
Resourcenhandling kann auch dazu genutzt werden, Skripte oder CSS-Dateien immer aus einem bestimmten Verzeichnis oder aus der Datenbank zu laden. Mit Resourcehandling sind Elemente beliebig durch Resourcen ersetzbar. Wie dies dargestellt wird, entscheidet der zu einem bestimmten Resourcen-Typ (im Beispiel „text/resourcebundle“) registrierte ResourceHandler. Resource sind insbesondere für die Komponenten-basierte-Entwicklung wichtig. Gibt ein View-Controller so zum Beispiel an, dass er eine bestimmte JavaScript-Datei als Resource benötigt, wird diese Resource für den Client gerendert und an ihn geschickt, auch wenn nur Teile der View nach dem Komponentenimport genutzt werden.
JSXP erlaubt auf komfortable Weise Zustände auf dem Server zu sichern. Dazu unterstützt JSXP diverse Scopes, wie Application-Scope, Session-Scope, View-Scope, Flash-Scope, ViewFlow-Scope und Request-Scope. Alle diese Scopes und ihre Inhalte werden automatisch verwaltet und sind über das Context-Object als leicht zu nutzende Maps verfügbar, oder können durch Angabe von Annotationen an Properties des View-Controllers verwendet werden. JSXP prüft automatisch bei den verwendeten View-Controllern, ob das anlegen einer Session notwendig ist und kümmert sich um alles notwendige.
Mit JSXP View Flows kann man Mengen von View-Komponenten definieren, die ausgezeichnete Start- und Endpunkte haben. JSXP erlaubt dann automatisch den Aufruf dieser Views per Request vom Client nur, wenn als erstes der Start-View aufgerufen wurde. Der View Flow wird automatisch beendet, sobald ein End-View erreicht wird. Springt der User aus einem View Flow nach Start hinaus, wird der View Flow abgebrochen. Während eines View Flows ist der ViewFlow-Scope gültig. ViewFlows kann man dabei wie Formular-Wizards verstehen, mit der Abläufe über mehrere Requests verarbeitet werden können.
JSXP unterstützt AJAX. Dazu ist eine sehr leichtgewichtige AJAX-JavaScript-API integriert. Aber jede andere AJAX-Bibliothek kann mit JSXP genutzt werden.
Geschwindigkeit ist mit JSXP auch kein Problem. Ein Caching-Mechanismus sorgt dafür, dass Prototypen der Design-Views stehts auf Abruf bereit stehen. Sie werden automatisch neu geladen, wenn sich das jeweilige Design ändert.
Auch das automatische Setzen von Input-Parametern (die z.B. in HTTP-GET/POST vom Browser kommen) übernimmt JSXP für den Entwickler. Dazu muss ein Entwickler lediglich eine Bean mit Eigenschaften für erwartete Input-Parameter zur Verfügung stellen.  Input-Parameter können dabei auch an importierte Komponenten weitergereicht werden.
Zum Validieren von Input-Parametern sieht JSXP eine Phase im Lebenszyklus vor. Für die Validierung überschreibt man im View-Controller die „validate“-Methode. Innerhalb der Methode kann man beliebige Frameworks nutzen, um die Daten an der Input-Parameter-Bean zu validieren und bei Fehlern auf entsprechende andere Views weiterzuleiten und die Fehler anzuzeigen/zu melden. Benötigt man kein spezielles Framework kann man mit den JSXP-Validatoren die Daten prüfen, JSXP-Elemente auf der Ergebnisseite markieren und Meldungen anzeigen.
Generell ist JSXP nach dem Prinzip gestaltet: Vollständig aber leicht anpassbar. Jederzeit kann das Verhalten des Frameworks nach den besonderen Projektbedürfnissen angepasst werden. JSXP bietet dazu insbesondere mit der Applikationsklasse und dem Context die Möglichkeit Methoden zu überschreiben und damit das Verhalten von JSXP flexibel zu gestalten. Beispielsweise kann man die Art und Weise wie Elemente bei Fehlern markiert werden um dem Benutzer nach Validierung auf Eingabefehler hinzuweisen, oder wie der zu benutzende Locale ermittelt wird ändern. Aber auch weitreichende Änderungen wie das Parsen von Design-Dateien oder sind einfach möglich. Viele der im Standard genutzten Algorithmen kann man somit austauschen oder anpassen.
JSXP bietet eine Reihe an weiteren Features, wie Project-Stages, View-Templates (ein Template-Mechanismus auf View-Ebene wie man ihn u.a. von Apache Struts kennt), View-Aliases, Command-Pattern und einiges mehr. Des weiteren ist noch in für dieses Jahr geplant, JSXP vollständig portletfähig zu machen.
Momentan wird JSXP von der MATHEMA Software GmbH [5] und der Ciqua [6] unterstützt. Damit gibt es eine breite Basis an erfahrenen Entwicklern, Trainern und Beratern für JSXP. Gern dürfen sich natürlich weitere Freiwillige zu uns gesellen. Das JSXP-Framework steht unter der Apache License Version 2. Es gibt auch erste Referenzprojekte: sowohl der jsxp.org Webauftritt ist über das CMS-System CMSonal mit JSXP implementiert, als auch das JSXP-Wiki und die Internetplattform solacize.com [7].
Eine Implementierung Ihrer Web-Applikationen mit JSXP steht also nichts mehr im Weg. Warum?
  • Damit Design wieder mit den Applikationen stattfinden kann, die dafür gemacht wurden, und nicht in irgendwelchen schwer zu handhabenden Plugins.
  • Damit Design auch nach mehreren Monaten Projektlaufzeit leicht iterativ angepasst werden kann, ohne das ein Entwickler kostbare Zeit vergeudet.
  • Damit Entwickler ihrer Kernaufgabe nachkommen können: Geschäfts- und Prozesslogik in Java-Code umsetzen.
  • Damit Entwickler nicht verzweifelt lange Zeit für Nichtigkeiten vergeuden, die den Projektfortschritt stoppen.
  • Und sicher auch um stabilere Applikationen zu schaffen, die nicht unvorhersehbar zur Laufzeit auf extrem schwer zu findende Fehler laufen, weil sich bei der Entwicklung jemand nur vertippt hat.
[1] JSXP Website, http://www.jsxp.org
[3] JSFDays Website, http://jsfdays.irian.at
[4] Herbstcampus Website, http://www.herbstcampus.de
[5] MATHEMA Software GmbH, http://www.mathema.de
[6] Ciqua Pirringer & Tanzer OEG, http://www.ciqua.com
[7] solacize.com, http://www.solacize.com


Montag, 28. September 2009

ShortNotes for iPhone

The new iPhone and iPod Touch application ShortNotes is now in the app store.



English (scroll down for german/s.u. für deutschen Text):
-------

If you want to take notes anywhere in an easy and convenient way, ShortNotes is the right app for you. It is optimized for the fast creation of notes.

You can quickly take a textline as notes, i.e. when you are in a meeting. You can add additional text to the note for a better description and also add a picture from the camera or media library.

ShortNotes allows you to structure your notes in an hierarchical order to find and group them. You can reorder the hierarchical structure.

And with one click you can export any of your notes (and there child notes in the hierarchical structure) as email. E.g. you can send all the point of a meeting to the participant directly from the meeting.

You can see a video on the application web site.

Available in english and german.



Deutsch:
-------

Mit ShortNotes kann man auf einfache und sehr bedienungsfreundliche Weise Notizen anlegen und verwalten. ShortNotes is optimiert für die schnelle Eingabe von Notizen.

Notizen sind Textzeilen, die zusätzlichen langen Text als Beschreibung enthalten können. Durch die schnelle Eingabe kann man z.B. die besprochenen Punkte in einem Meeting direkt eingeben. Auch kann man Bilder von der Kamera oder der Medienbibliothek einer Notiz hinzufügen.

Notizen können in ShortNotes hierarchisch gruppiert werden. So kann man diese leicht finden und verwalten. Notizen können auch innerhalb der Hierarchie verschoben werden.

Mit einem Klick kann man Notizen (und ihre zugehörigen Notizen in der Hierarchie) als eMail exportieren. Z.B. kann man damit direkt nach einem Meeting allen Teilnehmern die Liste der Todos und besprochenen Punkte mailen.

Auf der Website der App ist ein Video, das die Arbeitsweise von ShortNotes zeigt.




Dienstag, 18. August 2009

Mac OS X - Snow Leopard

Am Donnerstag, 10.09.2009 ab 18:30 stellen wir im Rahmen der Java User Group ER-N das kommende Betriebssystem Mac OS X Snow Leopard vor.

Man darf sich auf praktische Neuerungen und einige Verbesserungen auch unter der Haube freuen. Gern mit anschließender Frage- und Diskussionsrunde.

Windows 7

Hi zusammen,

gestern war die .NET Gruppe aus Fürth bei uns zu Besuch und es gab einen regen Austausch und Demonstrationen von Windows 7. Jeder der Windows Vista benutzen muss, wird sich sicher auf einen Umstieg freuen. Ein paar neue graphische Gimmicks, die viele sicher der Geschwindigkeit halber abstellen, ein bischen weniger Sicherheitsabfragen, hoffentlich schneller (aber das weiss man wohl erst nach Monaten Laufzeit, ein frisch installiertes System sieht da ja meist toll aus) und viele Dinge die mich an ein anderes Konkurrenzbetriebssystem erinnern.

Alles in allem vielleicht nicht schlecht, aber sicher auch kein echter Evolutionssprung.


iMobile ;)

Ich laufe durch London und suche (natürlich erst nachdem ich einige Sehenswürdigkeiten wieder besucht habe) den Apple Store auf. Rein zufällig kam ich daran vorbei versteht sich. Hier schaue ich mir die zum Herumprobieren einladend aufgestellten elektronischen Spielereien an, nichts wirklich neues denke ich mir. Aber natürlich kann ich es nicht lassen mal an den iPhones vorbeizulaufen und meine Apps darin aufzurufen. Nach der letzten Kolumne gibt es nämlich einen Grund zu feiern. Nicht nur das eine damals erwähnte eBook als Applikation wurde freigegeben, sondern einige weitere. Mittlerweile habe ich 17 Applikationen für das iPhone. U.a. eine zur Ernährungsüberwachung. 17 ist zwar keine runde Zahl, aber für mich eine Gelegenheit Revue passieren zu lassen.

Ich denke, der mobile Markt wird in Zukunft immer stärker wachsen, und somit auch die Arbeit von uns als Entwicklern, Architekten und sonst wie in der Softwarebranche Arbeitenden prägen. Immerhin benutzt man mobile Geräte heute bereits weit häufiger als man einen fester installierten PC neben sich hat. Mobile Apps werden gekauft, nicht
zuletzt auch wegen den niedrigen Preisen von einigen Cents bis Euro. Potentielle Kunden entschließen sich somit weit häufiger zum Kauf als bei den PC-Softwarepaketen bei den ja gerade mal 50 Euro durchschnittlich als günstig angesehen werden können.

Wir haben es also mit wohl schnelleren Entwicklungszeiten, günstigen Endpreisen und gut durchdachten Vermarktungs- und Vertriebsplattformen zu tun. Wo wir gerade bei Vermarktung und Vertrieb sind: wer denkt Software im mobilen Bereich produzieren zu wollen kann sich gern bei mir melden. Nach der vorletzten Kolumne "Deutsch für Informatiker" spare ich mir an dieser Stelle den Smiley. Aber sie können ihn sich denken und mich dennoch gern für Beratung kontaktieren.

Warum diesmal übrigens keine Fußnoten vorhanden sind, auf die ich eigentlich soviel Wert lege, ist leicht zu erklären. Wie zu Beginn erwähnt schlendere ich wirklich durch London. Und auf diesen mobilen handlichen und in die Hose passenden Geräten ist die Eingabe dann doch nicht so komfortabel.

Das sollte auch die diesmalige Kürze der Kolumne entschuldigen (und den Lektoren besänftigen). Immerhin ist der Akku noch weit aufgeladen. Und das trotz des Schreibens nebst parallelem Musikhören, und der Nutzung von RememberMeal um aufzuzeichnen was ich so alles an geistiger Nahrung (hier auch Sweets genannt) zu mir genommen habe. Sowie der Trackingsoftware, die per GPS meinen zurückgelegten Weg protokolliert, so dass ich nachher wenigstens weiß wo ich überall gewesen bin. In dem Augenblick, in dem man vor einer Attraktion steht erkennt man das ja glücklicherweise auf Google Maps bzw. Earth. Und ein mobiler Blick in das Internet verrät einem, was man sehen würde, wenn man ein Gebäude betritt. Letztens habe ich in einem Restaurant im mobilen Browser nachgesehen, was auf der Tageskarte steht. Denn die
hing zu weit weg und war (auch deshalb) zu unleserlich. Wer weiß, vielleicht maile ich beim nächsten Besuch meine Bestellung vom Tisch aus.

Wahrscheinlich kommt irgendwann tatsächlich der Zeitpunkt, ab dem man statt seine Heimat zu verlassen einfach die GPS getrackten und mit Photos, Ton und Videos hinterlegten Wegspuren von anderen nachklickt. Man entschuldige meine weit schweifende Phantasie, es ist mittlerweile schon spät, selbst nach Greenwich-Zeit. Aber die mobile elektronische Welt schreitet ihren Weg voran, und ich fürchte das macht sie mit und ohne uns. Und irgendwie ist es ja auch schön, fern gewesen zu sein, trotzdem effizient ein wenig geschrieben zu haben und später die daheim Gebliebenen mit einer Vielzahl von multimedialen Details versorgen zu können.

Und sollten ein paar Photos fehlen, weil ich zwischendurch zu abgelenkt war, kann man bei all den in London installierten Kameras bestimmt im Internet sicher adäquaten Ersatz finden. Und mit einer wenig Suche vielleicht sogar mit der Sehenswürdigkeit und mir auf dem Bild.

Freitag, 17. Juli 2009

Eintrittskarten für Herbstcampus-Konferenz zu gewinnen

Unter http://www.mathema.de/quiz gibt es ein kurzes Gewinnspiel, bei dem man Freikarten für die Herbstcampus-Konferenz gewinnen kann.

David Tanzer und ich werden dort auch JSXP demonstrieren.

Viel Glück :)
Oliver

Donnerstag, 25. Juni 2009

JSXP (Just Simple eXtensible Pages)

Die existierenden Webframeworks in der Java-Welt bekommen Konkurrenz :-)

Nach einem Besuch der JSFDays haben sich David Tanzer und Oliver Szymanski Gedanken über die Schwachstellen von JSF 2.0 sowie bereits existierender Webframeworks gemacht. Daraus hat sich ein erster Konzeptentwurf und anschließend ein proof-of-concepts ergeben.

Damit war der Grundstein zu JSXP (Just Simple eXtensible Pages) geboren. Es liegt mittlerweile in der Version 0.3 als Open Source vor.

Die wesentlichen Features dieses Webframeworks sind:
  • Typsicherheit / Compile-Time Sicherheit
  • Änderungen im Design mit Nebenwirkungen werden vom Compiler angezeigt/bemängelt
  • strikte Trennung von Design und Implementierung (kein Codieren mehr in XML)
  • Komponenten (eigene Komponenten oder fertige zum Aufbauen komplexer Views)
  • View und Element-Templating
  • View Flows
  • Internationalisierung
  • lesbare URLs (unterstützt Bookmarking, Redirects)
  • Server Side States (unterstützt verschiedene Scopes: Flash, Session, Request, ...)
  • AJAX (inkl. leichtgewichtiger JavaScript-API aber auch beliebige möglich)
  • Resource-Management
  • Applikations-Konfiguration
  • Erweiterbarkeit

Insbesondere können zur Validierung oder für AJAX beliebige Frameworks eingesetzt werden. Hierzu sieht JSXP simple Anbindungsmöglichkeiten vor. JSXP liefert aber auch Default-Implementierungen.

Es gibt auch bereits zwei Projekte, welche mit JSXP realisiert wurden: das AJAX-basiertes Wiki-System namens Wikiron und das Content-Management-System CMSonal.

Mehr zum Thema:

Java User Group am 18.06.2009

Das letzte Treffen der Java User Group hatte "Software-Metriken" zum Thema. Thomas Haug von der MATHEMA Software GmbH war so freundlich, uns seine Erfahrungen in einem Vortrag mitzuteilen.

Die Präsentation findet sich auf der Homepage der JUG. (Download)

Hex and the City: Fehlersuche oder Kaugummipapier, 3,5“-Diskette und ein BIOS

Fehlersuche oder Kaugummipapier, 3,5“-Diskette und ein BIOS


Vor einigen Tagen hatte ein Notebook einen Defekt – es ging nur noch ohne Bild mit Piepsen an. Ohne auf die Details der Fehlersuche einzugehen, höchstwahrscheinlich ist die Grafikkarte defekt, oder aber das BIOS ist mit falschen Daten überschrieben. Die genauen Piepstöne beim Booten in Zusammenhang mit dem BIOS-Hersteller lassen diese beiden Möglichkeiten offen, alle anderen Anzeichen deuten auch darauf hin. Hätte ich zwei weitere Tage bis zur Artikelabgabe, könnte ich mich sicherlich auf eine der beiden Fehlerquellen festlegen, aber letztlich soll dies für uns an dieser Stelle nicht relevant sein.


Warum in zwei Tagen? So lange braucht das externe USB-Diskettenlaufwerk leider noch, bis es geliefert wird. Disketten? Ja, richtig gelesen. 3,5“ um genau zu sein1.


Da bei Notebooks die Grafikkarte OnBoard ist, lässt sie sich zur Fehleranalyse nicht austauschen. Somit habe ich mich dazu entschlossen, dass BIOS zuerst zu restaurieren. Einfach, denken Sie jetzt vielleicht, wenn Sie einer von denen sind, die schon des Häufigeren mit Hardwarebauteilen wie Puzzlestücken gespielt haben und den Unterschied von CMOS2 und BIOS kennen. Aber nicht so einfach, wenn man es mit der aktuellen Evolutionsstufe der Computerhardware zu tun hat. Woran man sehen kann, wozu Evolution gut ist – oder auch nicht.


Früher gab es zum Reset des Basic Input Output System – ja, genau das bedeutet BIOS – manchmal einen Jumper. Leider nicht bei diesem Notebook. Auch keine Batterie die man abklemmen kann (oder irgendwas in dem Sinne, dass Strom liefert, auch wenn der Computer nicht an das eigentliche Stromnetz angeschlossen ist). Somit sind vielleicht falsche Daten im BIOS, aber zurücksetzen geht nicht. Dies hat zur Konsequenz, falls es sich nicht doch um eine defekte Grafikkarte handelt, dass sich eine fehlerhafte Firmware des x86 eingeschlichen hat, die kaum zu entfernen ist. Da das BIOS direkt mit der Hauptplatine verbunden ist, lässt es sich auch nicht als Hardwarekomponente austauschen. Das, was vor dem Start des Betriebssystems dem Computer einen Hauch von Leben schenkt, ist damit erstmal außer Gefecht gesetzt. Bios bedeutet übrigens im griechischen Leben. Leider ist bei diesem Notebook davon nicht mehr viel zu spüren.


Warum jetzt also ein externes USB-Diskettenlaufwerk? Nun, es gibt eine letzte Chance ein BIOS zu retten, ohne das Mainboard auszutauschen. Letzteres ist ja auch nicht mehr so einfach, denn der Versuch ein Mainboard für ein wenige Jahre altes Notebook zu ergattern, muss nicht unbedingt von Erfolg gekrönt sein. Zur Rettung: ein Phoenix-BIOS hat seit 2001 einen speziellen Crisis Recovery Mode, den man während des Startens des Computers mit einem Tastenkombination aktivieren kann. Jetzt wird BIOS-Code von einem sogenannten Boot-Block ausgeführt, der Notfallinstruktionen enthält, die bei BIOS-Flashs nicht überschrieben werden. So weit so gut. Alternativ zur Tastenkombination gibt es auch Versionen, die einen Jumper zum Aktivieren haben, oder – ja, ehrlich – ein bestimmter Dongle3 muss am Parallel-Port stecken.


Wenn der Crisis Recovery Mode aktiviert ist, kann man neue Firmware ins BIOS flashen. Jetzt kommt das Diskettenlaufwerk ins Spiel. Denn der Boot-Block kann naturgemäß nicht besonders viele Instruktionen enthalten, somit musste man sich auf das Notwendigste beschränken und hat keine optionalen Treiber eingebaut. Es wird lediglich unterstützt, von einer Diskette zu booten. Eine bootfähige CD oder ein USB-Stick funktionieren nicht. Hat man sich also vorher eine solche Diskette erstellt (die entsprechende Firmware für das BIOS sollte man im Internet finden), kann man trotz fehlerhaften BIOS über den Boot-Block booten und mit der Diskette das Flashen einleiten. Super.


Vorbereit ist bereits alles, jetzt muss nur noch das Diskettenlaufwerk ankommen. Was kann man dadurch lernen?


Nichts ist einfacher geworden.


Verdient eine Firma auch an Reparaturen, macht sie es den Nutzern leider nicht immer leicht, Fehler selbst zu beheben.


Und ich wette, es ist die Grafikkarte. Murphys Gesetz.



[1] Wikipedia, Basis Input Output System, http://de.wikipedia.org/wiki/Basic_Input_Output_System, 27.05.2009

[2] How to fix a corrupted Phoenix BIOS using the Crisis Recovery Disk, http://crd.y1.cc, 27.05.2009

[3] Diskettenstifthalter selber bauen, http://www.expli.de/anleitung/disketten-stifthalter-selber-bauen-249, 27.05.2009

1So flache, beinahe zweidimensionale Datenspeicher, die aber etwas mehr Dreidimensionalität besitzen als ihr 5,25“* Verwandten. Wer sich nicht erinnern kann: es gibt schöne technische Museen im Umkreis fast aller zivilisierten Gebiete. Manchmal trifft man sie auch als Stifthalter an, siehe [3].

* Die man noch mit einem Locher, oder einer Schere, oder einem patentierten Dings beidseitig nutzbar machen konnte. Nostalgie pur.

2Beim CMOS handelt es sich eigentlich nur um SRAM das die BIOS-Einstellungen speichert. Der Begriff CMOS als Complementary Metal Oxide Semiconductor stammt aus der Elektronik und hat sich beim PC für den speziellen Anwendungsfall (teils fälschlicherweise) eingebürgert.

3Bzw. nimmt man bei der MacGyver-Methode einen normales Parallel-Port Druckerkabel, schneidet es durch und verbindet Pin 2 mit 15, 3 mit 13, 4 mit 11, 5 mit 12 und 6 mit 10. Nachdem ich früher schon Platinen mit Kaugummipapier überbrückt habe können Sie sich denken, wozu ich raten würde*

* Mein Rat ist, bestellen Sie ein neues Notebook

Hex and the City: Kaffeeklatsch... im Weitesten und im Speziellen

Kaffeeklatsch... im Weitesten und im Speziellen


Vor kurzem musste ich lesen, was einen Menschen ausmacht, der sich einen doppelten Espresso bestellt. Im Zeit Magazin [1] wird behauptet, dass man demnach eigentlich todmüde ist und arbeitstechnisch immer verfügbar sein muss. Und das die zwei Espressi vereint als doppelte Ladung ein Ersatz für stärkere Aufputschmittel sind.


Nachdem zumindest die Java-Gemeindemitglieder unter uns Informatikern sich ja stark auf der Kaffeeseite des Lebens befinden – nicht umsonst stammen viele Symbole bei Java aus der Kaffeewelt, wie die berühmte Java-Kaffee-Bohne – denke ich, ist es wert einen Blick auf die Analogien zu werfen. Ist Java ein Espresso? Nachdem das Bild von Informatikern in der Allgemeinheit ja gerne einmal Menschen zeigt, die spät nachts noch vor Bildschirmen hocken1 und wilde Wörter und kryptische Zeichenkombinationen eingeben, passt der Vergleich mit dem Espresso gegen die Müdigkeit. Wenn wir mit Java 2 den doppelten Espresso hatten, was haben wir dann heute?


Java 2 gab es ja nach Java. Das klingt trivial. Aber es geht ja weiter. Java 2 existierte vor Java 5. Mathematisch ohnehin korrekt. Verwirrend wird es erst, wenn man weiß, dass Java 3 oder 4 nie (bislang) existiert hat2. Java 2 heißt Java auch bereits seit der JDK 1.1. Das ging bis zur Version 1.4.x so. Danach erst kam der Begriff Java 5 auf – wer weiß, ob da nicht eine fünffache Version Espresso im Spiel war.


Aber da wo wir eine Zahl dazu bekommen haben, nämlich hinter Java, wurde sie uns im Enterprise-Umfeld, der Java Enterprise Edition, weggenommen. J2EE wurde parallel zu Java 5 zu JEE. Jetzt also ohne Nummer im Namen. Dafür gibt es jetzt die JEE Version 5, wenn man es genau nimmt.


Bei den Enterprise JavaBeans als Teil der JEE ist es simpler. Während EJB 1.0 im Jahre 1998 die Welt erblickte, kam mit J2EE auch EJB 2.0 und später 2.1. Dann aber hört die Vergleichbarkeit der Versionsnummern auch auf. EJB 3 ist Teil von JEE Version 5 und wozu die künftige Version EJB 3.1 gehören wird, steht wohl noch in den Sternen.


Und das waren jetzt nur die Versionsnummern von Basistechnologien, von den Abkürzungen selbst wollen wir mal besser gar nicht sprechen.


Wenn also Java 2 ein doppelter Espresso war – und das war es bei der Vielzahl an Verbesserungen mindestens, dann war die Zeit dafür nicht mehr als ein Espresso. Oder ein Espresso macchiato für Leute, die eine extra VM genutzt haben. Wieviel Koffein erwartet uns denn bei Java 7? Oder wird vielleicht nur mehr Milch hinein gegossen?


Wenn Milch als Extras zählt, dann haben wir eine große Zahl an möglichen Varianten bzgl. der Analogie in der Java-Historie.


Java 5 könnte ein Milchkaffee sein – für Leute die solide Basistechnologien lieben und keinen exotischen Kram. Wer es ein bisschen außergewöhnlicher mag, vielleicht ab und an einmal die J2ME (hier steht die 2 noch immer fest an ihrem Platz) als Mobile Edition nutzt, der nimmt vielleicht einen Café au Lait. Mit Java 5 kamen ja auch die Annotationen dazu, wer diese selbst verwendet hat, bestellt wohl am ehesten eine Latte macchiato3 und geht was die Milch anbelangt dann Richtung Java 6, besonders lecker auch mit Milchschaumhaube. Eine Latte macchiato wird auch schichtweise ausgeliefert – zumindest wenn sie gut gemacht ist. Auch das kennen wir in Java mittlerweile durch die Trennung in Standard, Enterprise und Mobile Edition.


Was ist dann Java 7? Was bleibt denn noch? Von den gängigen Begriffen könnte noch der Cappuccino als Symbol herhalten. Hier fehlt aber einiges an Milch im Vergleich zu einigen der vorher genannten Koffeingetränken. Macht ja nichts, weniger könnte ja auch mehr sein. Zum Beispiel durch Verzicht auf all die Sachen, die man durch ihren deprecated-Status ohnehin nicht nutzen kann. Aber das wäre wohl zu schön um wahr zu sein.


Ich bleibe nach wie vor bei meinem Lieblingsgetränk. Double mocca macchiato. Wieviel Milch und Schaum dabei ist, dass muss jeder selbst enträtseln. Aber es ist (subjektiv betrachtet) die perfekte Zusammenstellung an Effizienz, Effektivität und Genuss mit wertvollen Extras. Natürlich spreche ich von dem Getränk. Alles andere ist kalter Kaffee. Übrigens: Fußnoten sind der Kaffeesatz.







[1] Zeit Magazin, Nr. 18, 23.04.2009, S. 31, „Coffee to show“, Tillmann Prüfer



1 Unter Umständen ist es auch Tag, aber die Jalousien sind geschlossen. Licht bremst ja bekanntlich.

2 Vielleicht eine Hommage an die Leisure Suite Larry Spiele ursprünglich von Sierra On-Line (später Codemaster). Al Lowe, der Erschaffer dieser Adventure-Spiel-Reihe, hatte wohl zu früh versichert, dass nach Teil 3 kein vierter herauskommt. Somit hieß der Nachfolger direkt Leisure Suit Larry 5. Von Teil 4, auch als Leisure Suit Larry – The Missing Floppies bekannt, war niemals etwas gesehen. *

* Selbst Larry, der Hauptprotagonist des Spiel, kann sich in den Nachfolgeteilen nicht erinnern, was ihn im vierten Teil passiert sein mag. Das mag manchmal auch auf Entwickler zutreffen – hauptsächlich wenn man bei der Frage nach dem Grund der Implementierung hört: „Das ist historisch gewachsen“.

3 Oder einen Caffé e Latte in der fälschlichen Annahme, das dies dasselbe ist. Hier sind zwei Espressi statt nur einem drin und der tolle Milchschaum fehlt. Zumindest wenn der Verkäufer Ahnung hat, was er da zusammen brüht. Und ja, es heisst eine Latte, denn diese gefleckte Milch ist im italienischen weiblich. Aber ich sag es auch immer so, wie es gerade über die Zunge kommt.