“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 …)
Tag Archive: Groovy
Pattern Matching – Java im Vergleich zu Perl
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 …)
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.
Ich 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.
codecentric @ TheServerSide Java Symposium
|
|
|
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 …
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?
Suchen
Podcast
Am meisten diskutiert
- FitNesse vs. Robot Framework – Agile Testing Tools
9 Kommentar(e) - Das Java Memory Architektur (1. Akt)
9 Kommentar(e) - Wer kommt zu spät zum Daily Scrum?
9 Kommentar(e) - Was ist der Unterschied zwischen Architektur und Design?
7 Kommentar(e) - Eclipse Galileo und SVN
5 Kommentar(e)
Kategorien
Kategorie:




