Tag Archive: Groovy

Pattern Matching – Java im Vergleich zu Perl

“Perl is born to pattern match.” – Ich denke das kann man ohne Übertreibung so schreiben. Perl löst dieses Problem einfach extrem effizient und elegant. Das folgende kleine Skript zeigt ein paar Beispiele für reguläre Ausdrücke und deren Anwendung in Perl. Wobei ich hoffe, dass mich nicht gleich ein Blitz erschlägt, da ich es wage Perl-Code in unseren Blog zu schreiben, der ja ansonsten eher von Java dominiert wird ;-) .
(weiterlesen …)

Thomas Jaspers

 

Devoxx 2009 – iCalendar Dateien für Outlook und Co

Auch in diesem Jahr wird codecentric wieder die Devoxx besuchen. Vom 18.-20. November sind wir mit insgesamt 8 Kollegen in Antwerpen, Belgien. Ich persönlich bin das erste mal dabei.

Ich freue mich auf das Event und habe damit begonnen, die für mich interessanten Sessions zu planen.

Andreas hatte eine sehr gute Idee und veröffentlichte in einem seiner Blogeinträge iCalendar Dateien für die Agile09. Die Idee habe ich übernommen und entsprechende Dateien für die Devoxx09 erstellt. Diese lassen sich in viele Kalender Programme wie iCal oder Outlook importieren. Zur Erstellung habe ich ein kleines Java-Programm geschrieben. Die Daten werden von der Devoxx Website mit Hilfe von Selenium-Remote-Control ausgelesen. Den Quelltext dazu gibt es hier. Die Logik dürft ihr selbstverständlich nach eurem Bedarf erweitern. Vielleicht könnte ihr ja eure Änderungen in den Kommentaren posten.
(weiterlesen …)

Daniel Reuter

 

Projekt Lombok – Cool, aber mit zu viel Magie?

Andreas gab mir kürzlich den Tipp eine nette Bibliothek anzusehen: lombok. Lombok erweitert den Java Kompilierungsvorgang, so daß bestimmte Klassen mit weniger unnötigem Code auskommen da dieser bei der Kompilierung erzeugt wird.

Project LombokIch bin total begeistert, so reicht es aus @Data an eine Klasse zu schreiben und schon werden die getters und setters, toString() und die hashCode() und equals() Methoden generiert. Im Prinzip funktioniert das so wie die magischen Methoden in Groovy. Ich mag das, da ich mich mehr auf die wichtigen Methoden kümmern kann ohne mich durch hunderte von unnötigen Zeilen scrollen zu müssen. Ich mag auch, daß so niemand Getter oder Setter für Seiteneffekte missbrauchen kann. Es passt auch in den agilen Prozess: Es beseitigt muda.

@SneakyThrows ist genial! Ich hasse die UnsupportedEncodingException auch wenn ich klar “UTF-8″ spezifiziere, welches garantiert immer vorhanden ist.

(weiterlesen …)

Fabian Lange

 

iCalender Dateiverarbeitung, Groovy!

Heute Nacht wollte ich eigentlich planen, welche Sessions ich auf der Agile 2009 besuchen möchte, die nächste Woche in Chicago stattfindet. I freue mich schon sehr auf die Konferenz und kann mich nur schwer zwischen den vielen Sessions entscheiden, weil ich so viele verpassen werde! Planung erfordert natürlich ein mindestmaß an Organisation. Auf der Homepage der Konferenz kann man sich durch das Importieren von iCalendar-Dateien die Termine der Sessions in den Kalender einpflegen. Eine großartige Idee … die leider nicht funktioniert, wenn man in einer anderen Zeitzone als Chicago lebt, oder Outlook als seinen Kalender benutzt. Meine Vermutung ist, dass eines der beiden Kriterien auf die meisten Benutzer zutrifft. Deshalb frage ich mich ernsthaft wie gut das Feature auf der Webseite getestet wurde. Naja, egal, mir hat es in den Fingern gekribbelt und ich habe einen Blick in dieSpezifikationen von iCalendar geworfen und ein kleines Groovy-Skript fabriziert, dass die bestehenden iCalendar-Dateien konvertiert.

>> Alle sessions sind konvertiert und können hier heruntergeladen werden. Fertig um in den Kalender importiert zu werden – auch nach Outlook.

Es gab mit den originären Dateien zwei Probleme. Hier ist eine Beispieldatei:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:Agile2009
METHOD:PUBLISH
CALSCALE:GREGORIAN
X-WR-CALNAME:Agile2009
X-WR-CALDESC:Agile2009
BEGIN:VEVENT
UID:1220
DTSTART:20090825T140000
DTEND:20090825T173000
SUMMARY:User Stories for Agile Requirements
LOCATION:Columbus IJ
URL;VALUE=URI:http://agile2009.agilealliance.org/node/1220
DTSTAMP:20090209T022940Z
LAST-UPDATED:20090723T173948Z
END:VEVENT
END:VCALENDAR

Zeitzonen

Die Start- und Endzeit beinhalten keine Information über die Zeitzone, also wird die lokale Zeit angenommen. iCalender spezifiziert, dass die Zeit UTC ist, wenn ein “Z” angehangen wird. Die Transformation ist also sehr einfach: fünf Stunden draufzählen um von Chicago zu UTC zukommen, und ein “Z” anhängen.

Outlook

Das zweite Problem wird offenbar, wenn man versucht mehr als eine Session in Outlook zu importieren. Beim ersten Mal erstellt Outlook automatisch einen neuen Kalender “Agile2009″. Cool. Bei der zweiten Session landet diese aber wieder in einem neuen Kalender “Agile2009 (1)”. Extrem uncool. Um das zu beheben, müssen die beiden Properties X-WR-CALNAME und X-WR-CALDESC entfernt werden. Dies scheint leider ein bekanntes Problem mit Outlook zu sein. Zum Glück lässt sich das ebenfalls einfach beheben.

Groovy

Um die Konvertierung zu automatisieren, habe ich ein kleines Groovy-Skript geschrieben, welches sich erst alle gültigen Session-IDs besorgt, dann die iCalendar-Dateien herunterlädt und die beiden Fehler behebt, und mir auch noch den Text ausgibt, den ich in unser WordPress kopieren muss. Das Skript kann mit Sicherheit noch verbessert werden, aber es tut erstmal seinen Job. Was ich wirklich liebe an Groovy, ist die Möglichkeit Strings wie ein Array zu zerschneiden, und dabei mit negativen Indexen auch von hinten zählen zu können, sowie die Möglichkeiten durch das regex-Handling, das macht Aufgaben wie diese um ein Vielfaches einfacher :)

public class ConvertCalendar{
 
private static final String VCAL_TIME_FMT = "yyyyMMdd'T'HHmmss";
 
public static void main(def args){
// use the smartphone page to get all valid session numbers
// http://agile2009.pairwith.us/sessions
InputStream sessionStream = new URL("http://agile2009.pairwith.us/sessions").openConnection().inputStream
 
String sessions = org.apache.commons.io.IOUtils.toString(sessionStream);
 
List calList = new ArrayList();
 
// href="/sessions/5107"
sessions.eachMatch(/href="\/sessions\/\d{1,4}"/) {
	InputStream calendarStream = new URL("http://agile2009.agilealliance.org/session_ical/" + it[16 .. -2]).openConnection().inputStream
	String calendar = org.apache.commons.io.IOUtils.toString(calendarStream);
 
	File calendarFile = new File("./cals/temp - calendar.ics");
	def calendarFileWriter = new FileWriter(calendarFile)
	def calendarFileName = "";
	calendar.eachLine {
		def vCalLine = it;
		if (vCalLine ==~ /^X-WR-CALNAME:.*/ || vCalLine ==~ /^X-WR-CALDESC:.*/) {
			// ignore that line
		} else if (vCalLine ==~ /^DTSTART:.*/ ) {
			def origDate = Date.parse(VCAL_TIME_FMT, vCalLine[-15..-1])
			vCalLine = vCalLine[0..-16] + DateUtils.addHours(origDate,5).format(VCAL_TIME_FMT) + "Z";
			calendarFileWriter.write("${vCalLine}\n")
			calendarFileName = origDate.format("yyyy-MM-dd'T'HHmm");
		} else if (vCalLine ==~ /^DTEND:.*/) {
			def origDate = Date.parse(VCAL_TIME_FMT, vCalLine[-15..-1])
			vCalLine = vCalLine[0..-16] + DateUtils.addHours(origDate,5).format(VCAL_TIME_FMT) + "Z";
			calendarFileWriter.write("${vCalLine}\n")
		} else if (vCalLine ==~ /^SUMMARY:.*/) {
			calendarFileName = calendarFileName + " " + vCalLine[8..-1].replaceAll("[^\\w\\s]", "")
			println "Processing " + calendarFileName
			calendarFileWriter.write("${vCalLine}\n")
		} else {
			calendarFileWriter.write("${vCalLine}\n")
		}
	}
	calendarFileWriter.close();
	calendarFile.renameTo(new File("./cals/"+calendarFileName+".ics"))
 
	calList.add(calendarFileName+".ics")
	calendarStream.close();
}
 
println "Text to paste into Wordpress after uploading: "
println "<ul>"
Collections.sort(calList)
calList.each {
	println "<li><a href="\">${it}</a></li>"
}
println "</ul>"
 
}}
Andreas Ebbert-Karroum

 

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

 

Vergleich von Java und PHP für Webanwendungen

Keine andere Sprache sorgt seit langer Zeit für so kontroverse Diskussionen wie PHP. Als auf Java spezialisierte Firma erreichen die codecentric GmbH auch Anfragen zur Migration von PHP Anwendungen.

Dabei geht die Frage, ob Java besser als PHP sei, an dem Hauptproblem vorbei. Sowohl in Java als auch in PHP gibt es Frameworks, welche speziell das Erstellen von Web Anwendungen unterstützen. Frameworks können natürlich Nachteile von Sprachen ausgleichen, aber auch Vorteile von Sprachen negieren.

Um den Vergleich von Java und PHP zu verstehen muss man in der Zeit bis etwa in das Jahr 2000 zurückgehen. Java bot damals mit Servlets und Struts erste Konzepte für Web Anwendungen, aber diese zu erstellen, zu konfigurieren und zu deployen war sehr kompliziert. Durch den Boom des Internets entstand eine neue Entwicklergemeinschaft welche schnell HTML lernte. Doch reines HTML begrenzt die Möglichkeit an Interaktion und CGI-Perl Skripte waren umständlich und schwierig. PHP bot hingegen eine elegante und einfache Möglichkeit, wollte man ein Datum in einer Webseite ausgeben, so nannte man die Webseite nicht “.html” sondern “.php” und baute an der gewünschten Stelle ein <?php echo date() ?> ein. Auf dem Webserver Apache, welcher bereits für PHP vorbereitet war, lief die neue Datei sofort.

Zwar gab es auch in JavaServer Pages die Möglichkeit Scriptlets zu verwenden, doch dies war als unsauber verpönt. Stattdessen propagierte die Java Community die Verwendung von Komponenten. Meiner Meinung nach, ein entscheidender Faktor für die Kategorisierung von Java als “Enterprise”.

Für Internetanwendungen ist ein schönes Design wichtiger als ein Funktionales, da es mehr Kunden anzieht. Während ein in Dreamweaver oder Frontpage vom Designer gebautes HTML von PHP Entwicklern einfach mit dynamischer Funktionalität erweiterbar war, konnten komponentenbasierte Java Frameworks nicht viel damit anfangen. PHP konnte Designs mit Funktionalität ausstatten. In Java musste man jedoch die Funktionalität verschönern.

Doch in den vergangenen Jahren entstand Einsicht auf beiden Seiten. Java reduzierte die Komplexität, Frameworks wie Tapestry oder GWT, erlaubten von Designern erstellte Templates. PHP erlernte mit Version 5 brauchbare Objektorientierung und Frameworks wie Zend oder symfony brachten den PHP Entwicklern Designkonzepte bei. Auch die ergänzenden Bibliotheken von Java fanden Entsprechungen auf PHP Seite. So gibt es zum Beispiel in PHP die ORMs Propel und Doctrine.

Vom heutigen Standpunkt aus betrachtet bieten also Java und PHP ähnliche Funktionalität. Dennoch bleiben weitere Aspekte zu betrachten:

  • Stabilität
    PHP hat hier meiner Meinung nach deutliche Schwächen. Die prozedurale Abwärtskompatibilität, kein echter Deprecationmechanismus, ein undurchschaubarer Wirrwarr an halboffiziellen Bibliotheken und plattformabhängiger Funktionalität sind nur einige der Problempunkte die PHP hat. PHP mangelt es an einem sauberen Schnitt, den das PHP Team mit Version 6 geplant hat.
    Java hingegen hat eine saubere Platformunabhängigkeit und eine recht klar definierte Anzahl an Kernbibliotheken mit entsprechenden Qualitätsstandards.
  • Performance
    Wurde früher Java oft als langsam bezeichnet, so sind heute die JVMs hochoptimiert, wohingegen die Skriptsprachen, auch PHP noch damit kämpfen. So gibt es erst in PHP 5.3 einen brauchbaren Garbage Collector. Auch andere Optimierungen fanden nur sehr zögerlich Einzug in die PHP Runtimes. Dies mag wohl daran liegen, daß PHP im Gegensatz zu Java nach jedem Request die VM neu startet, was weitere Performanceprobleme bedingt. So muss bei jedem Request die Session von Platte gelesen werden. Zwar gibt es dort auch Lösungen im PHP Bereich (MemCache, APC), jedoch sind diese zum Einen selten eingesetzt, zum Anderen auch noch stark in der Entwicklung.
    Interessanterweise macht dieser Nachteil die Skalierung von PHP Anwendungen recht einfach. Da Requests völlig separat verarbeitet werden können, wirkt sich zusätzliche Hardware relativ linear auf die Kapazitäten des Servers aus. Im Web liegt der Fokus auch eher auf der Anzahl der Requests, nicht direkt auf der genauen Dauer eines einzelnen Requests.
  • Auswahl
    Idealerweise erfindet man das Rad nicht neu. Selbst wenn man es noch runder machen könnte steht der Aufwand auf einer holperigen Straße nicht in Relation zum Nutzen. Von daher ist es sinnvoll bereits existierenden Lösungen zu verwenden. Sowohl in PHP, als auch in Java existiert viel modularer Software, teils mit freien, teils mit unfreien Lizenzen. Allerdings haben PHP Module wesentlich mehr Probleme als in Java geschriebene. So haben einige PHP Modulentwickler sich eigene Konzepte einfallen lassen (z.B. Zend nutzt Zend Loader als Ersatz für Packages) oder die Module sind nur auf ein Framework optimiert (symfony Plug-In).
    Java ist als Sprache, gerade durch die “komplizierten Konzepte” wie z.b. Classloading und Packages, besser auf Modularisierung vorbereitet. Auch durch die bessere Toolunterstützung (Ant/Maven, Javadoc, JUnit) besitzen Java Frameworks leichter zu installierende, besser dokumentierte und getestete Artefakte. Allerdings verbreiten sich PHP Tools für diese Aufgaben (pake/phing, PHPDocumentor, PHPUnit/lime).
  • Integration
    Integration ist sicherlich die Stärke von Java. Zum einen ist Java selbst fast “Industry Standard”, zum anderen gibt es für viele Standards Implementierungen in Java. Soll eine PHP Webanwendung auf einem bestimmten Protokoll kommunizieren ist die Auswahl in PHP relativ dünn. Selbst größere Implementierungen sind z.B. von Zend sind teilweise nur sehr rudimentär implementiert (z.B. OpenID). Dies mag aber auch daran liegen, daß Integrationen von PHP Anwendungen oft über Datenbanken laufen.
  • Entwickler Know-How
    Schon vor 20 Jahren hat Frederic Brooks nach der “Silver Bullet” gesucht und sie nicht gefunden. In seinem Artikel kommt er zu dem Schluss, daß Softwaredesign, Problemformulierung und die Fähigkeiten der Entwickler wesentlich wichtiger sind als die verwandten Tools oder Sprachen. Von daher ist es sicherlich sinnvoller bei der Umsetzung einer Webpräsenz durch einen Designer mit PHP Kenntnissen ein aktuelles PHP Framework einzusetzen. Soll nur das Web-Frontend für ein Java EE Backend entwickelt werden ist sicherlich Java die näherliegende Wahl.
    Allerdings sollte das Entwicklerknowledge nicht primär im Fokus stehen. Gewisse Technologische Hürden lassen sich nur mit bestimmten anderen Technologien und Sprachen sinnvoll lösen, und es ist mitunter sinnvoller einen Experten mit spezifischen Fähigkeiten einzukaufen als es mit ungeeigneten Tools selbst zu versuchen.

Als Fazit bleibt mir der Schluss, daß Java weiterhin die bessere Wahl für viele Projekte ist. Für kleinere isolierte Projekte können aber Scriptsprachen schneller zum Ziel führen. Als Kompromiss vielleicht Groovy mit Grails?

Fabian Lange