11.11.2011

Gulasch - Traditionelle Art

Die Basis für das Gulasch ist das Rezept aus der Kochschule von Witzigmann und Plachutta. Die meisten der Rezepte sind mit ein wenig Grundwissen nachzukochen und bieten Platz für eigene Kreativität.
Basis für das Gulasch bilden ein paar Metzgerzwiebeln, die fein gehackt werden.


Dazu kommt, ebenfalls fein gehackt, eine Portion Suppengemüse (bestehend aus Lauch, Petersilie, Möhren und Sellerie).


Das Gemüse darf in dem heißen Fett dünsten und Röstaromen aufnehmen.


In der Zwischenzeit wird das Fleisch in mundgerechte Stücke zerteilt. Ich habe hier den Rest meines Flanksteaks genommen, da dies vom Metzger wenig fachgerecht zugeschnitten wurde und für das direkte Grillen nicht mehr geeignet war. Für das Gulasch aber immer noch super!


Nach dem Portionieren des Fleisches hat die Gemüsebasis bereits genügend Röstaromen abbekommen und kann mit dem Zauberstab püriert werden.


Sieht zwar nicht lecker aus, bildet aber eine hervorragende Basis für ein sämiges Gulasch.


Die angerösteten Reste im Topf werden durch ein wenig Rotwein aufgekocht und vom Topf gelöst. Nächstes Mal auch ohne Kohlensäure...


Das Fleisch, die pürierte Gemüsebasis und die Flüssigkeit köcheln nun eine Weile (4h) vor sich hin, so dass das Fleisch schön mürbe wird.


Kurz vor Ende der Garzeit werden noch zwei Paprika fein gewürfelt und dem Gulasch untergemengt.


Nach ca. 4 bis 4,5h ist das Essen fertig und kann mit Kartoffeln angerichtet werden.


Als Nachtisch gab es einen selbst angesetzten Joghurt mit Honig und frischen Walnüssen!


Lecker war's!

08.11.2011

Futter für den Winter - Pike Secrets I & II

Die Jungs der Film Schmiede "Wide Open Outdoor Film" haben ein paar weitere feine Trailer veröffentlicht.




Wenn die DVDs nur halb so gut sind, wie es "The Fish and the Fly 1" und "The Fish and the Fly 2" waren, dann werden die Teile auf jeden Fall den Weg in das heimische DVD Regal finden. Die Qualität der Trailer lässt auf jeden Fall auf die DVD hoffen. Die Spielzeit liegt bei knapp über einer Stunde pro DVD.

Und falls es doch wieder Fliegenfischen sein sollte, dann lohnt es sich einen Blick auf den Trailer von "The Fish and the Fly 3" zu werfen.



Leider erscheint die DVD deutlich später als geplant. Ich hoffe aber, dass es Ende November den dritten Teil auch zu kaufen gibt. Fehlt noch in meiner Sammlung ;-)

Bezug dere DVDs über die Webseite des Herstellers oder über den Fachhandel.

03.11.2011

Perfomance - Zeitmessung mit Servletfiltern

Um die Performance einer Anwendung zu messen, kann die Abarbeitungszeit eines Requests gemessen werden. Dabei können unterschiedliche Verfahren zur Anwendung kommen.
Für Webanwendungen bietet sich die Nutzung eines Filters an, der die Ausführungzeit des Requests messen und loggen kann.

Servlet-Filter können genutzt werden um auf die Werte eines Requests (und auch der Response) zurückzugreifen, diese zu manipulieren und weitere Aktionen durchzuführen.  Durch Mappingregeln innerhalb der Deploymentdeskriptoren werden die Filter definiert und in ihrer Reihenfolge festgelegt.

In der Literatur dient in vielen Fällen das Messen der Ausführungszeit als Beispiel für die Implementierung eines Filters. Dabei können Ausführungszeiten, Zugriffszeiten auf Ressourcen oder weitere Flaschenhälse einer Anwendung geprüft werden.

Als Basis für das Beispiel wird eine per Maven erzeugte Beispielanwendung verwendet, die mit einem Filter zur statistischen Auswertung erweitert wird. Um die Komplexität des Beispiels nicht zu hoch zu setzen, wird eine Erstellung durch die Auswahl des entsprechenden Archetypes durchgeführt.


Danach steht eine rudimentäre Webanwendung mit einer einfachen "Hello World" Seite zur Verfügung. Damit diese gestartet werden kann, wird das Tomcat Plugin genutzt. Dieses muss in der pom.xml des Projektes hinzugefügt werden.


Danach sollte der Server ohne weitere Probleme durch das Goal tomcat:run gestartet und die Webanwendung aufgerufen werden können.

Vor der Implementierung des Filters sollte klar sein, wie Filter im Allgemeinen funktionieren. Die drei wesentlichen Klassen sind
Die FilterConfig ist der Teil, der sich innerhalb des Deployment Deskriptors wiederfindet und dort die Details eines Filters konfiguriert. Dabei werden die angegeben Einträge in einem Objekt vom Typ FilterConfig gekapselt und innerhalb der init Methode eines Filters zur Verfügung gestellt.
Die FilterChain ist die Kette der Filter, die durch das Framework abgearbeitet werden. Alle Filter zusammen bilden die Filterkette. In dem Interface FilterChain ist als einzige Methode die Methode doFilter(..) definiert, die für die weitere Verarbeitung der Filter verantwortlich ist. Mit Hilfe der Methode wird das nächste Element (Filter oder, falls kein Filter mehr vorhanden ist, die Ressource selbst) angesprochen.
Das Interface Filter ist das wesentliche Interface bei der Eigenentwicklung eines Filters. Jeder Filter muss das Interface implementieren, damit dieser innerhalb der Chain verarbeitet werden kann. Die verschiedenen Methoden bieten die Möglichkeit zur Interaktion mit dem Request oder auch der Response.

Der Filter für das statistische Loggen der Dauer eines Requests ist einfach gehalten um so wenig Overhead wie möglich zu produzieren. Für die Bereitsstellung der Logs wurden zwei Logger über die SLF4J Factory initialisiert und stehen im weiteren Verlauf zur Verfügung.


Die Wahl fiel an dieser Stelle bewusst auf zwei Logger, da diese unabhängig voneinander loggen können. Einmal wird auf die Konsole geloggt, so dass der Entwickler weiterhin einen guten Überblick über die Meldungen hat und zum anderen wird über einen RollingFileAppender statistische Daten in eine Datei geloggt, so dass diese später weiterverarbeitet werden können. Das Konfigurationsfile ist wie folgt aufgebaut:


Die Implementierung der Methode gestaltet sich ebenfalls nicht weiter schwierig, so dass auf größere Erklärungen verzichtet werden kann.


Im weiteren Schritt braucht der Filter nur noch in den Deployment Deskriptor eingetragen werden. Dafür werden in der web.xml das Filtermapping und auch der Filter an sich ergänzt. Für die Namensgebung und die Verweise innerhalb der web.xml gelten die gleichen Regeln, wie für das definieren von Servlets und Servletmappings.


Wichtig an dieser Stelle ist, dass die Reihenfolge durch die Einträge innerhalb des Deployment-Deskriptors definiert werden. Für die Bestimmung der Filterreihenfolge existieren zwei wesentliche Kriterien. Zum einen gilt, dass Filter, die mit einem URL Mapping definiert worden sind immer Vorrang vor den Filtern mit einem Servletmapping haben. In der jeweiligen Gruppe der Filter entscheidet dann, als zweites Kriterium, die Reihenfolge der Definitionen.

Sobald der Filter aktiviert ist und die Anwendung erneut gestartet wurde, können die Ausgaben auf der Konsole, als auch innerhalb der Datei gefunden werden.


Die statistische Auswertung kann dann anhand der Textdatei erfolgen. Dort hilft ein Import und eine Betrachtung mit Hilfe von Excel um die Ergebnisse grafisch auszuwerten.


Wobei an dieser Stelle noch mehr herauszuholen ist ;-)

Das gesamte Projekt ist wie gewohnt bei Cloudbees im Repository zu finden.

Programmierbücher - Kostenlose Liste von eBooks

Durch den Newsletter der JUG Ostfalen bin ich auf einen Post bei Stackoverflow aufmerksam geworden.

Dort wird eine Menge an frei verfügbaren Büchern (Online oder auch als eBook) aufgelistet auf die man ohne weitere Vorraussetzungen Zugriff hat.

Sollte also jemand Bedarf an unterschiedlicher Lektüre haben, einfach mal bei Stackoverflow vorbeischauen.

http://stackoverflow.com/questions/194812/list-of-freely-available-programming-books

02.11.2011

JavaEE 6 - Testing mit Hilfe des EJBContainers

Mit JavaEE 6 sind enige Neuerungen in die JavaEE Welt gekommen. Zum einen ist die Nutzung des Frameworks weiter vereinfacht worden und zum anderen wurden diverse Wünsche aus der Entwicklercommunity mit untergebracht.

In den meisten Fällen wurden die Konfigurations- möglichkeiten weiter vereinfacht und komplett auf Annotation umgestellt. Damit wurde die Linie bei der Entwicklung von J2EE 1.4 (schwergewichtig, stark XML lastig) zu Java EE 5 (POJOs, IoC, DI, Annotationen statt XML) konsequent weitergeführt.



Wesentliche Neuerungen sind:

  • Konfiguration von Servlets per Annotation (Servlet 3.0)
  • Integration von JSF 2.0 (ebenfalls Konfiguration per Annotation)
  • Wegfall der Interfaces für die Nutzung lokaler Beans
  • Singleton Scope für Beans (Annotation: @Singleton)
  • Erweiterung und Verbesserung der Timerfunktionalität
  • Unterstützung von asynchronen Methodenaufrufen in Session Beans
  • Integration von weiteren Mapping Optionen bei JPA 2.0
  • Bereitstellung eines EJBContainers für das Testen von EJB Anwendungen
Gerade der Wegfall der Interfaces ist ein wichtiger Punkt und kann kontrovers gesehen werden. Sicherlich ist somit eine Vereinfachung der Anwendung gegeben, aber gleichzeitig wird mit konkreten Implementierungen der Beans gearbeitet. Eine Entkopplung von Definition und konkreter Umsetzung fällt in diesem Fall unter den Tisch. Sicherlich ein Vorteil in unterschiedlichen Projekten, da der Overhead weiter dezimiert wird. Allerdings entscheidet man sich an dieser Stelle für die Nutzung der Implementierung innerhalb der weiteren Beans und somit gegen eine einfache Austauschbarkeit.

Ist kein Interface definiert, so stellt der Container ein Referenzobjekt zur Verfügung. Dieses Referenzobjekt beinhaltet alle öffentlichen Methoden der Bean selbst. Das Proxyobjekt ist eine von der ursprünglichen Bean abgeleitet Klasse und kann ganz normal in weiteren Beans genutzt werden. Diesen Umstand sollte der Entwickler unbedingt im Auge behalten.

Eine weitere spannende Neuerung ist der EJB Container (javax.ejb.embeddable.EJBContainer) , der für die Tests der entwickelten Beans bereit steht. Damit soll ein Test der erstellten Komponenten deutlich einfacher werden. Die Funktion ist an dieser Stelle reicht einfach zu erklären.

Der Container wird mit dem Aufruf EJBContainer.createEJBContainer() erstellt. Dabei werden alle EJBs die sich auf dem Classpath befinden als EJB im Container deployed und stehen in dem Test zur Verfügung. Dabei ist es egal, ob sich die EJBs verpackt in JAR Files befinden oder als Verzeichnis vorliegen. Sollte der Container nicht erfolgreich initialisiert werden können, wird eine EJBException geworfen.

Der Vorteil des Containers wird schnell an einem kleinen Beispiel klar. Als Basis dient eine kleine Anwendung, die die aktuellen Umrechnungskurse von der ECB bezieht, diese parst und einen einfachen Service für die Umrechnung von Euro in andere unterstützte Währungen bereithält.


Dabei spielt die Klasse EcbExchangeRateParser eine wichtige Rolle. Diese Klasse ist als Stateless Session Bean implementiert. Nach dem Erzeugen durch den Container werden die Daten der ECB abgerufen und mit Hilfe des EcbContentHandler geparst.


Mit Hilfe dieser Informationen werden später die Wechselkurse bestimmt, zu sehen in dem folgenden Snippet.


Diese Bean wird innerhalb des eigentlichen Währungsrechners für die Ermittlung des Wechselkurses genutzt.


Mit JavaEE 6 ist das durchführen von Integrationstests nun deutlich einfacher geworden. Die komplette Konfiguration und Nutzung von TestNG für einfache Tests entfällt als Beispiel. Dafür kann nun der bereits vorgestellte EJBContainer genutzt werden. Dieser wird in einer abstrakten Testklasse vor jedem Test erstellt und hochgefahren. Zusätzliche werden weitere Methoden bereitgestellt (Bean-Instanzen aus dem EJB-Kontext referenzieren und den Container nach den Tests ordnungsgemäß herunterfahren).


Beim Startup des Containers werden alle im Classpath befindlichen Beans geladen und deployed.

Bitte auf das Bild klicken um die Konsolenausgabe zu sehen
Dort sind dann auch die JNDI Namen für die Beans ersichtlich. Unter diesen JNDI Namen stehen die Beans für einen Lookup zur Verfügung.

Damit der Test funktioniert muss eine zusätzliche Dependency in die pom.xml eingetragen werden.


Diese Dependency sorgt für die Bereitstellung eines Embedded Glassfish der extra für das Testen entwickelt worden ist. Somit steht die gesamte Funktionalität des Glassfish innerhalb des Testcontainers zur Verfügung und ermöglicht ein einfaches implementieren der Tests.


Im Test selbst muss der Entwickler sich nicht mehr um DI oder die korrekte Instantiierung der Beans kümmern, da dies durch den EJBContainer abgewickelt wird.

Falls also wirklich die komplette Funktionalität zur Verfügung steht, ist dies sicherlich eine nette Alternative zu gängigen Frameworks.

Das Beispiel findet sich wie immer in meinem Repository unter https://svn-saschadoemer.forge.cloudbees.com/saschadoemerblogspotcom/EJB