ArtikelMärz 2009

meet the experts

Vordenker zu sein ist ein elementarer Wert von codecentric und ein sehr hoher Anspruch an jeden in unserem Team. Mit der Einführung der 4+1 Woche, also einem Tag pro Woche für Fort- und Weiterbildung, haben wir uns einen enormen Wettbewerbsvorteil erarbeitet und liegen mit über 30 Tagen Training je Mitarbeiter pro Jahr weit über dem Durchschnitt in Deutschland. Intern haben wir vor knapp einem Jahr die so genannten “Freitagsmeetings” eingeführt, um den Wissenstransfer innerhalb von codecentric zu fördern. Jeden letzten Freitag im Monat organisieren wir seit dem einen internen Workshop mit mindestens zwei Präsentationen. Die Vortragenden sind unsere internen Experten, aber auch externe Sprecher die wir zu diesen Events einladen. Diesen Freitag wird beispielsweise Herr Wittwer von oose einen Vortrag über Agiles Projektmanagement halten. Schwerpunkt der Vorträge sind Themen rund um Java, Open Source, Architektur, Agilität und Performance.

Der große Erfolg dieser Freitagsmeeting  liegt neben der Qualität der Vorträge auch an der offenen Diskussion und den Gesprächen die danach in gemütlicher Atmosphäre stattfinden. Auch Kunden, die schon an unseren Meetings teilgenommen haben waren begeistert von den Inhalten und der codecentric-typischen Atmosphäre. Wir haben uns in den letzten Wochen oft die selbe Frage gestellt: Sollen wir dieses Konzept nicht auch für die Öffentlichkeit anbieten?

Aus dieser Idee wurde “meet the experts” – eine professionelle Variante unserer Freitagsmeetings mit den selben Prinzipien. Alle drei Monate wollen wir zu einem speziellen Thema die besten Experten einladen, die insgesamt vier Vorträge von je einer Stunde halten. Nach den Vorträgen wird es dann ein Open Space geben. Das Prinzip von Open Spaces ist, dass jeder Teilnehmer Themen vorschlagen kann und sich so unterschiedliche Gruppen bilden, die sich zu Präsentationen oder Diskussionen zurückziehen. Dies ermöglicht den Teilnehmern von “meet the experts” eigene Ideen oder auch Probleme mit Experten zu diskutieren.

Neben dem einzigartigen Inhalt von “meet the experts” bietet der Event aber auch die Möglichkeit Netzwerke zu knüpfen und die Experten persönlich kennen zu lernen. Dafür werden wir unsere schönen Räumlichkeiten im “Alten Amtsgericht” Solingen bereitstellen und den ganzen Tag von einem Catering Team bis in den späten Abend begleiten lassen. In unserem Dachgeschoss haben wir viel Platz für Kreativität mit top ausgestatteter Bibliothek und vielen Flächen mit Whiteboards und Flipcharts.

Bibliothek im Dachgeschoss

Am 26.6.2009 starten wir “meet the experts” mit dem Thema Performance. Wir konnten dafür bereits Dr. Heinz Kabutz, den Java Specialist und Kirk Pepperdine von javaperformancetuning.com gewinnen. Zudem werden Alois Reitbauer von dynaTrace und ich je einen Vortrag halten. Mit Alois schreibe ich zusammen die Java Performance Antipatterns Kolumne im Java Magazin. Zudem hoffen wir, dass Performance Experten aus Projekten von unseren Kunden und anderen Firmen teilnehmen werden, so dass wir im Open Space und den Gesprächen am Abend viele Experten aus der Praxis haben mit denen wir  interessante Themen besprechen können.

meet the experts - performance

Wir hoffen viele von Euch auf dem Event begrüßen zu können und empfehle Euch eine schnelle Anmeldung, da wir die Plätze stark limitieren werden.

In diesem Jahr planen wir zwei weitere “meet the experts” – am 4.9.2009 zum Thema Agilität und am 13.11.2009 mit dem Schwerpunkt Architektur. Würde mich deshalb sehr über Feedback von Euch freuen, wir Ihr die Idee des “meet the experts” findet und welche Themen und Experten Ihr Euch für zukünftige Veranstaltungen wünschen würdet.

Mirko Novakovic

 

codecentric @ TheServerSide Java Symposium

tssjs1

tssjs2

TheServerSide ist eine der großen Konferenzen für Java Server Technologien. Auch dieses Jahr ist codecentric wieder vor Ort, um neueste Technologietrends mitzunehmen. Die Konferenz findet, wie auch letztes Jahr schon, im Caesars Palace Hotel in Las Vegas (Nevada, USA) statt – eine ziemlich beeindruckende Stadt.

Die in den einzelnen Sessions vorgestellten Technologien sind unerwartet unspektakulär und enthalten nicht viel Neues. Das meiste ist wohl bekannt und wurde schon auf vielen vorherigen Konferenzen vorgetragen. Trends sind weiterhin Scripting (Groovy, JavaScript inklusive GWT oder JSON),  Cloud-Computing und SOA. Beispielsweise enthält Spring 3.0 nicht viel revolutionäres. Viele Neuerungen betreffen vor allem das Spring-MVC Projekt und nicht den Spring-Kern. Große Neuerung ist hier die Möglichkeit einer programmatischen Konfiguration mithilfe neuer Annotationen wie @Configuration und @Bean. Für Details, siehe Jürgen Höllers Blog

Die neueste Nachricht, IBM habe Interesse an der Übernahme von Sun angekündigt, hat direkt zu einer spontanen Integration in die Keynote von Rod Johnson (SpringSource) geführt. Seiner Meinung nach hätte eine solche Übernahme keinen technologischen Einfluss.

In seinem weiteren Vortrag stellte er die Theorie vor, dass Softwarekomplexität mit der wirtschaftlichen Entwicklung einher geht. Es ist ebenso schon untersucht worden, dass auch die Rocklänge der Frauen abhängig von der wirtschaftlichen Entwickung ist. Je schlechter die wirtschaftliche Lage, desto kürzer die Röcke. Zitat: “… I don’t think this actual recession is real, when I look across the streets of Las Vegas …”. Die momentane Rezession ist ein positiver Zustand für OpenSource Entwicklungen. OpenSource ist günstiger und einfacher als poprietärer Code. Weiterhin seien komplexe traditionelle Applikationsserver vom Aussterben bedroht, da die momentanen Trends in Java Technologien stark in Vereinfachung von Strukturen und Konfigurationen zu sehen sind. Einfache Server, wie Tomcat werden noch populärer werden, als sie ohnehin schon sind.

Komplexität zu verringern ist das Gebot der Stunde …

Thomas Bosch

 

SVN Regel: Commite nicht auf einem Tag – es sei denn, es ist keiner!

Eine typische Situation: Nach einem langen Arbeitstag möchte man seine Arbeit in ein Subversion Repository einchecken, bekommt aber diese Meldung angezeigt:

svn-tag

Huch! Eigentlich wurden nur die richtigen Dateien verändert und auch die Subversion Meta Dateien sind nicht durcheinander.

Aber keine Panik, sehr wahrscheinlich spielt hier nur das Subversive Plug-in von eclipse verrückt. Vor kurzem haben wir die Entwicklungsumgebung für einen Kunden auf das aktuelle Ganymede Release von eclipse inkl. Subversive Plug-in ohne Probleme umgestellt. Die einzige Auffälligkeit war diese Meldung.

Wir haben uns die Sache dann etwas genauer angesehen und festgestellt, dass die Methode, welche prüft ob man auf einem Tag arbeitet, nicht so klug ist, wie man es erwarten würde. Jedes mal, wenn die Ressource, welche man committen möchte, den String “tags” im Pfad enthält, wird diese Meldung auftauchen. Wir nutzen aber einen Paketnamen für eigene JSP Tags, welcher eben diesen String enthält (com.acme.tags.FooTag). Jedes mal, wenn man hier eine Änderung einchecken möchte, taucht die Warnung auf.

Offensichtlich ist dies nichts Besorgniserregendes, man kann die Warnung einfach ignorieren und der Commit wird anstandslos durchgeführt. Im nächsten Abschnitt soll im Detail erklärt werden, warum es zu dem Fehlverhalten kommt.

Dieser Ausschnitt aus der CommitAction Klasse ist verantwortlich für die Meldung:

if (SVNUtility.isTagOperated(allResources)) {
	TagModifyWarningDialog dlg = new TagModifyWarningDialog(this.getShell());
	if (dlg.open() != 0) {
		return;
	}
}

SVNUtility.isTagOperated() prüft die Art (~kind) des “root”-Elements der Ressource, welche committed werden soll.

if (((IRepositoryRoot)SVNRemoteStorage.instance().asRepositoryResource(resources[i]).getRoot()).getKind() == IRepositoryRoot.KIND_TAGS) {
	return true;
}

Ich habe “root” in Anführungsstriche gesetzt, weil man sich darüber streiten kann, was die Wurzel tatsächlich sein soll. Man nehme einfach mal folgenden Pfad als Beispiel: “/usr/local/share/svn/trunk/com/acme/tags/FooTag.java”
Ich würde sagen, dass “/” oder “/usr/” aus Sicht des Dateisystems oder “/trunk/” aus der Sicht eines Repositories die Wurzel ist. Aber SVNRepositoryResource.getRoot() denkt da ganz anders:

public IRepositoryResource getRoot() {
	if (this.root == null) {
		IRepositoryResource parent = this;
		while (!(parent instanceof IRepositoryRoot)) {
			parent = parent.getParent();
		}
		this.root = (IRepositoryRoot)parent;
	}
	return this.root;
}

SVNRepositoryLocation.getParent() gibt auf Grund eines Subversion Schlüsselwortes ein entsprechendes Objekt zurück:

Path urlPath = new Path(url);
String name = urlPath.lastSegment();
 
if (location.isStructureEnabled()) {
	if (name.equals(location.getTrunkLocation())) {
		return new SVNRepositoryTrunk(location, url, SVNRevision.HEAD);
	}
	if (name.equals(location.getTagsLocation())) {
		return new SVNRepositoryTags(location, url, SVNRevision.HEAD);
	}
	if (name.equals(location.getBranchesLocation())) {
		return new SVNRepositoryBranches(location, url, SVNRevision.HEAD);
	}
}

Subversive behandelt dabei den ersten Treffer als die Wurzel: sobald ein Treffer auftaucht gibt die Methode ein entsprechendes Objekt zurück. Auf Grund des Paketnamens ist name.equals(location.getTagsLocation()) zutreffend und es wird ein SVNRepositoryTags Objekt zurück gegeben.

Nun ist die SVNRepositoryTags Klasse (welche natürlich von der Art her ein IRepositoryRoot.KIND_TAGS ist) eine Erweiterung von SVNRepositoryRootBase welche IRepositoryRoot implementiert. Hier ist der Knackpunkt, die Bedingung der while Schleife von getRoot() zieht nicht mehr an, also wird die aktuelle IRepositoryResource zurückgegeben, was dazu führt, dass SVNUtility.isTagOperated() einen positiven Test liefert – auch wenn wir uns gar nicht auf einem Tag befinden.

Dies ist natürlich nur ein kleineres Problem, da es sich hier nicht um einen Fehler, sondern nur um eine Warnung handelt. Meiner Meinung nach sollte der komplette urlPath betrachtet werden und die letzte vorkommende Instanz von IRepositoryRoot anstatt der ersten als Wurzel bzw. Indikator genutzt werden. Das würde dann auch für verschiedene Subversion Repository Layouts (Global vs. pro Projekt trunk/tags/branches) funktionieren. Die Subversion Implementierung sollte nicht vom Inhalt, in diesem Fall dem Paketnamen, abhängig sein, auch wenn Subversion Schlüsselwörter verwendet werden.

Nick Prosch