Anleitung für Performance und Java Runtime Monitoring

Auf den IBM Developerworks sind drei neue Artikel erschienen, in denen sich Nicholas Whitehead mit Java Performance und Java Runtime Monitoring auseinandersetzt.
Sehr spannend zu lesen mit einer Menge hilfreicher Tips.

* Teil 1, Run-time performance and availability monitoring for Java systems

* Teil 2, Post-compilation instrumentation and performance monitoring

* Teil 3, Monitoring performance and availability of an application ecosystem

Fünf Missverständnisse bei der Webanwendungsentwicklung

Web Application Development. Nichts leichter als dass und doch gibt es wenigstens fünf große Missverständnisse, über die man als Webentwickler stolpern kann. Eran Galperin, seit über 5 Jahren als Web Developer tätig, hat sie jetzt zusammengetragen:

* Objektorientierter Code ist weniger performant als prozeduraler Code.
* Das Backend ist das Wichtigste bei der Entwicklung
* Grafikdesigner sind auch gute Interfacedesigner
* Es gibt eine überlegene Programmiersprache
* XML ist ökonomischer als eine Datenbank

Dabei lässt Eran seine Punkte nicht als bloße Behauptungen im Raum stehen, sondern erklärt jedes Missverständnis anhand eines kurzen Beispiels und zeigt auf, worin der Irrglaube genau besteht.

(Quelle: Jaxenter)

und hier ist das Original

maven goal eclipse:rad und checkstyle

Ich muss gestehen, dass ich länger danach gesucht habe.
Nun bin ich fündig geworden.
Das Maven goal eclipse:rad erzeugt die IBM RAD spezifischen Konfigurationsdateien und macht damit aus einem einfachen eclipse-projekt ein echtes RAD Projekt.
Was fehlt nun noch zum richtigen Enterprise Software Projekt?
Natürlich die Softwarequalität.
Wenn man am maven-eclipse-plugin folgende zusätztliche Einstellungen vornimmt, dann wird direkt beim Build der IDE Konfiguration die entsprechende Checkstyle Einstellung gesetzt:


<plugin>
<groupid>org.apache.maven.plugins</groupid>
<artifactid>maven-eclipse-plugin</artifactid>
<configuration>
<additionalconfig>
<file>
<name>.checkstyle</name>
<url>http://some.place.org/path/to/file</url>
</file>
</additionalconfig>
</configuration>
</plugin>


Nachtrag:
Auf den ersten Blick könnte man meinen, dass es sich bei dem <file> um die checkstyle.xml handelt. Das ist leider nicht wahr.
Tatsächlich handelt es sich um den xml-Schnipsel, den Eclipse in der.checkstyle Datei erwartet. Erst darin befindet sich dann der Pfad zu einer externen oder internen Konfiguration.


<fileset-config file-format-version="1.2.0" simple-config="true">
<local-check-config name="ITP_Checks_for_ACM" location="/path/to/checks.xml" type="external" description="">
<additional-data name="protect-config-file" value="false"/>
</local-check-config>
<fileset name="Alle" enabled="true" check-config-name="ITP_Checks_for_ACM" local="true">
<file-match-pattern match-pattern="." include-pattern="true"/>
</fileset>
</fileset-config>


Maven Repository Manager Nexus

Kaum gibt es mal wieder ein verregnetes Wochenende, kann man sich auf die Suche nach Dingen begeben, die man schon immer haben wollte.
Und wie üblich, wird man im Netz fündig. Hab ich im letzten Post noch den Codebaus Maven Proxy als zentrales Repository empfohlen, kann ich heute mit einem neuen Fund aufwarten.
Der Nexus Repository Manager (http://nexus.sonatype.org/).
Ein schickes Stück Software.
Wer es bunt mag, mit einer komfortablen Oberfläche, der sollte einen Blick darauf werfen. Ich hab mich ürigens entschieden, bei dem Codehaus Proxy zu bleiben.
Gründe:
- Er ist offensichtlich schlanker
- Hat weniger Konfigurationsmöglichkeiten (damit auch weniger Fehlerquellen)
- Man kann ihm leichter Dinge "unterschieben" ;)

Nexus is a powerful and robust Maven repository manager, created to provide reliable access to artifacts required for development and provisioning. Maven's central repository has always served as a great convenience for users of Maven, but it has always been recommended to maintain your own repositories to ensure stability within your organization. Nexus greatly simplifies the maintenance of your own internal repositories and access to external repositories. With Nexus you can completely control access to, and deployment of, every artifact in your organization from a single location.

Maven Best Practices

Den Einsazt von maven als Experiment zu bezeichnen ist warscheinlich schlicht zu gewagt. Dafür existiert es schon zu lange und wird in vielen Projekten erfolgreich verwendet. In Summe ist es ein wirklich netter Ansatz um modulorientiert Software zu entwicklen und zu builden. Alles in Allem finde ich es nach den ersten Wochen des wirklich harten Projekteinsatzes durchaus charmant.

Ein paar Punkte fallen allerdings immer wieder unangenehm auf. Aus ihnen kann man schnell und einfach ein paar best practices ableiten:

• Keine Snapshot builds.
  
  Maven gibt nicht umsonst eine Warnung aus. Wenn es sich gar nicht vermeiden läßt, dann sollte man auf alle Fälle einen halbwegs getesteten Snapshot verwenden und den manuell im Repository bereitstellen.
  


• Grosse Teams brauchen einen Proxy.
  
  Je größer das Entwicklungsteam ist, desto eher sollte man über einen maven proxy nachdenken. Eine stabile und brauchbare Lösung kommt von Codehaus (http://maven-proxy.codehaus.org/). Nett ist, dass man diesen sowohl standalone als auch als WAR auf nahezu jedem beliebigen Appserver betreiben kann.
  


• Modulabhängigkeiten sind böse.
  
  Modulabhängigkeiten mit maven machen einfach keinen Spass. Vor allem dann nicht, wenn man aus maven heraus mit bspw. eclipse:eclipse auch die Entwicklungsumgebung und ihre Abhänigkeiten definiert. Bei jeder Änderung eines Moduls sind potentiell andere Module betroffen. Für das Neuanlegen/Updaten der Entwicklungsumgebungen geht ganz schön viel Zeit drauf. Allein das sollte Grund genug sein, die maven Module entlang den Softwarekomponenten zu schneiden. Damit macht man den Entwicklern auch das (ungewollte) Verweben der Komponenten schon beim Build sehr unangenehm. Es ist damit quasi ein pre-build-dependency check :)
  


• Maven ist nicht ant.
  
  Wer lange Jahre mit ant seine Projekte gebaut hat, der kommt mit maven erfahrungsgemäß nicht sofort klar. Die Dokumentation von maven ist sehr verstreut und die tatsächlichen Fähigkeiten muss man sich doch in der Praxis erarbeiten. Es empfiehlt sich, dass im Projekt ein Verantwortlicher mit maven Erfahrung regelmäßig überprüft, ob und wie man was besser machen kann.
  Darüber hinaus gibt es Dinge, die man mit maven einfach nicht machen kann. So kann man pro Modul bspw. nur ein Artefakt (*.jar, *.war, etc.) erzeugen. Benötigt man mehr, dann muss man tatsächlich auf ant zurückgreifen
  


• Maven und Opensource lieben sich.
  
  Abseits von Opensource Entwicklungsumgebungen wird der Einsatz von maven schnell unbequem. Setzt man beispielsweise auf WebSphere, Bea und Co, dann fehlen einem die gewohnt kompfortablen ant Targets zur Erstellung von Deployment Descriptoren und Ähnliches. Auch wenn es für den RAD schon ein goal im maven gibt. Hier muss man tatsächlich noch ein wenig investieren, damit auch auf weniger quelloffenen Umgebungen eine nahtlose Integration möglich ist.
  

Soviel für Heute. Mehr in den kommenden Woche, wenn Zeit bleibt.

ant oder maven oder wie man schnell und einfach ..

... Java Projekte kompliziert machen kann.
Ok. Ich geb es ja zu: Auch ich bin nicht immer auf der Höhe der Zeit, was die aktuellsten Hype-Tools oder Open Source Trends angeht. Einen hab ich bisher sicherlich verschlafen. Maven.
Auf mehr oder minder elegante Art und Weise wurde ich jetzt dann mit der Nase draufgedrückt. Frei nach dem Motto: Das Wasser ist blau und tief: Schwimm!
Mit ein paar Jahren Build und Ant Erfahrung bringt einen sowas nicht mehr um den Nachtschlaf und daher bin ich frohen Mutes drangegangen. Und ich muss gestehen, ich hatte es mir einfacher vorgestellt. Selten hab ich ein Werkzeug in der Hand gehabt, was derart eigenwillig war *g*
Mal kurz zum positiven: Das Modulkonzept und die Definition von Abhängigkeiten treibt einem vor lauter Freude das Wasser in die Augen. Einfach klasse. Damit kann man, wenn man es nicht ganz verbockt sich eine Menge Refactoring sparen. Man verlagert die Aufwände einfach in den Build und definiert sein Projekt sauber. Klasse!
Auch das automatische Herunterladen von abhängigen Open Source Bibliotheken ist einfach klasse. Aber dann geht es los: Der Kampf mit den Projektanforderungen.
- Wie sieht eine elegante Integration in Eclipse aus?
- Welche Bibliotheken gibt es in welchen Repositories und warum?
- Wie strukturiert man poms und super-poms?
- Welche Repositories braucht man neben maven 1 und 2 noch?
- Wann steigt mir die Netzwerktruppe auf den Hals, wenn ich mit 40 Entwicklern den ganzen Tag Bibliotheken aus dem Netz ziehe?
- Warum brauche ich wofür einen Maven Proxy?
- Was für Plugins gibt es?
- Warum brauche ich immer noch Ant?
- Soll Ant Maven oder Maven Ant aufrufen?
- Wann wird welche Einstellung von wo vererbt?
- Wieso gibt es keine brauchbare Visulaisierung von Abhängigkeiten?

Fragen über Fragen. Mal sehen, ob ich demnächst noch ein paar Antworten schreiben kann :)

EJB is dying!

Dass nenne ich mal einen Start in das Wochenende. Nach einer etwas längeren Zeit der Dienstreisen hab ich heute meinen Informationsbedarf mal wieder gestillt. Und prompt bin ich über einen Artikel über eine Keynote auf der JAX2008 gestolpert.

Zum Thema The Future of Enterprise Java referierte Rod Johnson (SpringSource). Den zugehörigen JAXenter Artikel verfasste Sebastian Meyen in seinem unverwechselbaren Stil :)

Aufregung galt Rods Einstellung: „EJB is dying“! Denn damit hat er ausgesprochen, was vielen von uns im Hinterkopf herumschwirrt und sich dennoch keiner zu sagen traut.
Aber was genau wird die Zukunft bringen? OSGi? Spring? Oder gar die bisher noch recht theoretische Agententechnologie?
Neugierig bleiben ist die Devise :) Und über die Agententechnologie werde ich im laufenden Jahr sicherlich noch das ein oder andere schreiben. Hoffentlich auch bald mal etwas konkreter :)

Ein Interview mit Adam Bien

Bin heute zufällig drüber gestolpert.
http://java.sun.com/developer/technicalArticles
/Interviews/community/bien_qa.html

Adam wurde im Rahmen einer Interviewreihe über "Java Champions" von java.sun.com interviewt.

Die Hauptaussagen:

• "It's kind of funny that developers still explore new frameworks and hope for magic solutions -- and forget about core problems."


• "The best advice I know is 'Don't distribute.'"


• "Large-scale IT projects are inherently inefficient. It's a misconception to even talk about a large-scale project."

Viel Spass beim Lesen ;)

You are now a Registered iPhone Developer

Bin bei einem technikbegeisterten Kollegen vorbeigegangen. Der hat schon eins. Grausam. Also wirklich. Es ist einfach traumhaft. Vollständig intuitiv zu bedienen und traumhaft schön im Design.
Jetzt endlich dann auch das SKD. Unter http://www.apple.com/iphone/ kann man sich zum SDK durchclicken.
Ein wenig komisch erscheint auf den ersten Blick, dass man sich registrieren soll. Und die Rede von 99$ ist.
Klar ist: Der Download des SDK ist frei. Mit einer bestehenden iTunes Apple ID kann man ohne weitere Probleme direkt auf Download klicken. Wer noch keine hat, der muss sich kostenlos als iPhone Developer registrieren.
Erst wenn man über den iTunes Shop seine Software auch vertreiben möchte, dann sind die 99$ fällig. In Summe bekommt Apple dann nochmal 30% von den Einnahmen der Software, die über den iTunes shop vertrieben wird.
Das iPhone entwickelt sich zu einer Gelddruckmaschine für Apple.

Eins steht fest: Wenn die ersten G3 fähigen Geräte auf den Markt kommmen, dann hab ich auch eins :) Bis dahin lerne ich schonmal ein wenig für das iPhone zu programmieren.

Hier schonmal ein paar spannende Links:

• http://developer.apple.com/iphone/


• http://developer.apple.com/webapps/
• 
  
• http://www.applephoneinfo.de/


• Develop iPhone Web applications with Eclipse

Eigenwerbung :) Artikel in iX 03/2008 (heise Verlag)

Heute muss ich einfach mal ein wenig Eigenwerbung posten.
Ein neuer Artikel ist in der aktuell iX (03/2008, heise verlag) erschienen.

Softwareentwicklung
Mit .Net auch für JEE entwicklen
Ein integrativer Ansatz im heterogenen Umfeld stellt für Softwareentwicklung große Herausforderungen dar. Will man eine .Net-Entwicklung mit relativ wenig Aufwand unter einer Java Enterprise Edition zum Laufen bringen, sind schon beim Projektdesign Entscheidungen zu fällen, denn mehrere Wege führen ein Stück in Richtung Palo Alto.

Darin hab ich mir ein paar Wege angeschaut, die einem die Entwicklung auf einer Sourcecode-Basis für beide Welten .NET und Java/JEE erlauben. Die Recherchen haben erstaunlich lange gedauert aber ich habe auch eine Menge dabei gelernt.
Das Highlight dabei war sicherlich die Installation des aktuellen Visual Studios :)

Apache Geronimo v2.1 Released

Seit gestern ist die neue Apache Geronimo Version verfügbar. Damit ist erstmalig eine von Sun zertifizierte JEE5 Version von Geronimo verfügbar.
Die 2.1 ist als Download für Unix/Linux/MaxOS und Windows verfügbar.
Im Package ist entweder ein Tomcat oder ein Jetty Webcontainer enthalten. Die Wahl hat man beim Download. In Summe wurden 235 Bugs behoben.

Mehr über Geronimo gibts auch zu lesen in meinem iX Artikel.

MyFaces Portlet Bridge - Version 1.0.0-alpha

Das Apache Projekt MyFaces hat die Verfügbarkeit der Alpha-Version von Apache MyFaces Portlet-Bridge 1.0.0 bekannt gegeben.

Release-Notes

msg systems und Whitestein Technologies vereinbaren strategische Partnerschaft

Zusammenarbeit in den Bereichen Prozessmanagement und Autonomic Computing

München, 15. Februar 2008. Die msg systems ag, eines der 10 größten IT-Beratungs- und Systemintegrationsunternehmen in Deutschland mit Sitz in Ismaning bei München, und das Schweizer Unternehmen Whitestein Technologies AG, führender Anbieter von Softwaretechnologien und -lösungen für autonome Systeme, starten ab sofort eine strategische Zusammenarbeit im Bereich des zielorientierten Business Process Modelling.
[...]

Die komplette Pressemeldung findet man auf msg-systems.com

Mehr zur Firma Whitestein gibts unter http://www.whitestein.com/.

Genug Einführung ;) Was steckt dahinter? Also: Hinter "zielorientiertem Business Process Modelling"?
Ein neuer Weg um agentenbasierte Systeme in die Praxis zu bringen. Aktuell muss ich leider noch auf die Webseiten des Herstellers verweisen. Dort findet man schon ein paar Whitepaper zum Einlesen. Aber es bleibt spannend. Und in den kommenden Wochen und Monaten gibt es sicherlich den ein oder anderen Blogeintrag zum Thema.

Best Practices für EAR Files

Ein Posting auf beas dev2dev Seiten hat meine Aufmerksamkeit erregt. Ein recht umfassender Beitrag zum produktionsgerechten Packaging von EAR (Enterprise Application Archives) Files. In Summe finden sich 15 Hinweise und Vorgehensweisen zum optimalen Packagen für Produktionsumgebungen.
Mit Ausnahme einiger Weniger, sind diese Hinweise "state-of-the-art" und werden sicherlich von jedem berücksichtigt.
Erstaunt war ich über den dritten Hinweis: PS003: JSPs, unprocessed/uncompiled annotations and source files must not be included in the EAR. Genauer: über die JSP Seiten. Dass Java Sourcen nicht in eine Produktivumgebung gehören ist klar.
Wenn die JSP Seiten unter WEB-INF/jsp abgelegt sind, dann ist ein unberechtigter Zugriff auf die Sourcen von extern gar nicht möglich.
Und verglichen mit dem Umstand, dass JSPClassServlet einrichten zu müssen ist dieser "Schutz" vergleichsweise einfach zu erreichen.
JSP Sourcen gehören m.E. nicht in ein Produkt. Aber im Kontext eine klassischen Individualentwicklung, welche auf einer separaten Instanz betrieben wird, ist dieser Aufwand m.E. überflüssig. Trotz allem sollte man allerdings den jspc nicht vergessen. Grad bei großen Webprojekten unter Last ist ein Precompilen der JSP Seiten unabdingbar.

arc42 - die endgültige Antwort in Version 3.2

Die news des Tages: Auf dem Blog von Dr. Gernot Starke steht, dass die bekannte
Arch42 Seite einem Update unterzogen wurde. Neben dem offensichtlich neuen Layout ist die Version komplett überarbeitet worden.

Was ist arc42?
Zitat von der Website: Das ist ARC 42

Wir stellen Software- und Systemarchitekten, Designern, Produktlinienverantwortlichen, Qualitätssicherern und anderen Beteiligten von IT-Projekten Informationen, Hilfsmittel, Muster und Dienstleistungen zur Verfügung, um zu besseren Software- und Systemarchitekturen zu gelangen.

ARC42 ist ein umfassender Rahmen, der eine Sammlung von Architekturhilfsmitteln, Prozessbeschreibungen, Dienstleistungsangebote und Schulungen beinhaltet. Seit seiner Einführung haben schon zahlreiche Unternehmen diese Ressourcen genutzt.

[...]

Mit dem ARC42-Prozess erhalten Sie eine detaillierte Einführung in die Entwicklung effektiver Software-Architekturen. Der Prozess und das ARC42- Template passen zu den existierenden UML-Werkzeugen und Methoden. Er erstand aus der jahrzehntelangen Erfahrung weltweiter Architekturprojekte und wird ständig durch das Feedback unserer Anwender verbessert.

ICEFaces and Spring

Ein kleiner Tipp zum Lesen für das Wochenende:
Erschienen auf theserverside.com

ICEFaces is a JSF component library that adds a unique approach to AJAX: it renders a DOM (Document Object Model) on the serverside, and delivers changes to that DOM to a client via AJAX push. What this means is that data can be updated from one client, and the updates can be reflected almost immediately – with no client intervention – on other clients.

Den kompletten Artikel finden Sie hier

Top 5 Java Technologies for 2008

Es ist immer wieder spannend zu sehen, wie sich die Definition von "Top Technologie" im laufe der Zeit ändert. Zu beginn des Jahres taucht eine brandneue Liste mit den fünf angesagtesten Java Technologien in 2008 auf. Geschrieben hat sie Carlos Perez. Den kompletten Artikel findet man in seinem Blog.

Für ihn sind das:

* OSGi (Dynamische Module in Java)
* Java Content Repository API
* Google Web Toolkit
* Groovy
* Cloud computing (Ein Konzept zum verteilten rechnen ohne EJBs)

Alles Dinge, die der interessierte Entwickler schon seit längerem kennt (vielleicht mit Ausnahme des letzten Punktes). Sicherlich ist das ein Indikator dafür, dass sich die Ansätze mittlerweile etablieren und stabil geworden sind.

Meine persönliche Liste für 2008 sieht ein wenig anders aus, auch wenn ich gestehen muss, dass ich ein paar Punkte ebenfalls auf der Liste habe:

* JSF und Ajax
* Agent Based Computing (Agile Business Process Management)
* JEE6
* Groovy
* AOP, IoC (mit Spring) im Unternehmenseinsatz

Ich bin gespannt, zu was ich alles komme.

Neue Gesichter gesucht!

Wer auf der Suche nach einem Job im Umfeld von Softwareentwicklung und IT-Beratung ist, dem kann ich einen Blick auf die Homepage von meinem Arbeitgeber empfehlen.
Die msg-systems ag stellt ein. Aktuell werden allein für die Niederlassung in Passau mehr als 30 neue Mitarbeiter gesucht.
Einen schnellen Überblick bekommt man mit der Stellenmatrix. Neben der Softwareentwicklung und IT-Beratung werden auch für die Branchenschwerpunkte Versicherungen, Finanzdienstleistungen und Automotive Fachberater gesucht.

codebeamer 5.0 comming

Final ist er noch nicht. Aber man kann bereits einen ersten Eindruck von den neuen Funktionen unter http://www.codebeamer.com bekommen.
Die Registrierung ist kostenlos und es gibt bereits eine 15 user Testlizenz zum download (allerdings noch Version 4.2).
Sobald der neue Codebeamer verfügbar ist, werde ich mich in einem Artikel den neuen Features widmen. Wer möchte kann mit der 4.2er Testversion meine Codebeamer Plugins ausprobieren.