Die digitale Transformation ist passé

sechs-disziplinen

„Die digitale Transformation ist passé, wir sind in der digitalen Realität.“. Bogdan Sutter von PWC beginnt seine Präsentation mit einigen statistischen und demographischen Fakten (die wir gut in seiner Präsentation nachlesen können). So beispielsweise mit einem Reifemodell unserer Kunden. Den … Weiterlesen

Weckruf von Tim Renner

„13.15 Uhr, Weckruf am Smart Business Day – die stehen ja so früh auf wie die Musikindustrie“. Mit Bezug auf sein Thema steigt Tim Renner gleich auf unserer Beliebtheitsskala (wir fühlten uns alle wieder in der Schule).

Die Musikindustrie hat es versucht, die Kunden rechtlich dinghaft zu machen, die das getan haben, was die Kunden von der Musikindustrie wollten… Ohne seine Mixtapes, so seine Erläuterung, wäre sein Erfolg bei Frauen nie so gut gewesen. Seine Frau ist noch heute im Besitz dieser – aus Sicht der Industrie illegalen – Wunderwerke (aka Kassetten mit Musik drauf).

Als die Musik digital wurde, handelte die Industrie weiterhin extrem kundenunfreundlich: Mit Kopierschutz und mangelhaftem Angebot. Waren die Leute dort so ignorant und idiotisch? Nein.

Kernbotschaft:

Ein Geschäft, welches auf Kontrolle funktioniert, hat in einer digitalen Welt keine Chance.

Das alte Geschäftsmodell war genial. Der Kunde wollte ein Lied, musste aber zwölf kaufen (die Schallplatte). Und als CDs kamen, verkaufte die Industrie dasselbe Bundle nochmals. All dies verknüpft mit einer sehr präzisen Kontrolle des Timing und des Preises.

Was mit der Digitalisierung geschehen ist, war kein technisches Phänomen. Es war ein Ruf nach Freiheit: Eine Revolution. Als Mittel dagegen gibt es nur Gewalt oder Androhung von Gewalt.

Die Grundbotschaft, welche er noch mit der katholischen Kirche und dem französichen Hadopi-Gesetz (three strike), ist der Verlust über die Kontrolle der Kunden.

Wenn es etwas illegal gibt, so gibt es den Kundenwunsch. Die Aufgabe der Firmen ist es, diesen Wunsch anzubieten. Eigentlich ganz einfach. Als Beispiel wo dies geschehen ist, nennt Tim das Angebot von Spotify, welches Auslöser für ein erneutes Marktwachstum ist. Die Konversion des Gratisangebotes mit Werbung zum Bezahlmodell sei übrigens 25%. Hier hat die Industrie gelernt loszulassen.

Anhang von seiner Tochter Victoria schliesst der seinen spannenden Beitrag mit dem schwierigen Augenblick, an welchem es zu entscheiden galt mit Angebot oder mit Repression zu reagieren.

GWT Blog-Serie – Die Vorteile für Entwickler (4/4)

Zum Abschluss meiner Blog-Serie will ich nun noch die Vorteile für Entwickler von GWT Anwendungen aufzeigen. In den Vorherigen Blogposts habe ich bereits erklärt was GWT ist, wie GWT die Performance der Browser optimal ausnutzt und dass sich GWT auf dem mobilen Markt mit jQuery Mobile und Sencha Touch messen kann.

GWT aus Entwicklersicht

Aus Entwicklersicht geht GWT einen komplett anderen Ansatz als andere Web Developer Frameworks. Normalerweise programmiert man in einem Web Developer Framework clientseitigen Code in JavaScript und serverseitigen Code in einer anderen Sprache wie z.B. Java, C# oder PHP.

Bei GWT wird der client- und der serverseitige Code in Java programmiert. Ein GWT Entwickler brauch theoretisch keine HTML Kenntnisse um eine Top Anwendung zu entwickeln. Praktisch gibt es jedoch viele Vorteile wenn man über diese verfügt, spätestens wenn man eigene Widgets programmieren möchte.

Quelle: The Future of GWT Report, 2012, Vaadin

Quelle: The Future of GWT Report, 2012, Vaadin

Vorteile von GWT

Als Entwickler bieten sich durch die Nutzung von Java als Frontend-Sprache diverse Vorteile. Aus einer Umfrage von Vaadin, haben sich die Entwickler für folgende Vorteile ausgesprochen:

Quelle: The Future of GWT Report, 2012, Vaadin

Quelle: The Future of GWT Report, 2012, Vaadin

Debugging

Aus meiner Erfahrung mit JavaScript Frontend Projekten, weiss ich, dass es nicht immer simpel ist JavaScript Code zu debuggen. Vor allem wenn ein Fehler in einer externen Library auftritt, kann das Debuggen sehr aufwändig werden. Clientseitiger Code kann mit GWT direkt in der IDE gedebuggt werden, als wäre es eine normale Java Anwendung, was eine grosse Erleichterung mit sich bringt.

Refactoring

Es können alle Refactoring Funktionen der IDE genutzt werden.

Community

Hinter GWT steht eine grosse Community. Bei Fragen zu GWT findet man z.B. auf Stackoverflow zu fast allen eine Antwort.

Testing

Automatisches Testen von clientseitigem Code ist immer schwierig in Web Anwendungen. Dank der strikten Trennung zwischen Logik und Layout kann auch der clientseitige Code mit allen bekannten Tools aus der Java Welt getestet werden. So können Tools wie JUnit, Test NG, JMock oder andere Mocking-Libraries eingesetzt werden.

Stateless Server

Dank der Stateless Servers lässt sich GWT sehr gut skalieren.

Back-Button Support

GWT verfügt über einem eingebauten Browser-Back-Button Support trotz der ausgiebigen Nutzung von AJAX-Requests. Als Entwickler muss man sich nicht selber darum kümmern.

Schnelles Entwickeln

Wenn man das Konzept von GWT verstanden hat, ist man extrem schnell im Entwickeln mit GWT.

Google App Engine Integration

GWT bietet volle Integration in Google App Engine. Als Entwickler kann man so schnell eine funktionierende App zusammenstellen und veröffentlichen ohne sich grosse Gedanken über den Backend-Server zu machen.

Nachteile von GWT

In der Umfrage von Vaadin wurde auch gefragt, wo die Nachteile von GWT liegen. Hier bin ich nicht mit allen Punkten gleicher Meinung.

Quelle: The Future of GWT Report, 2012, Vaadin

Quelle: The Future of GWT Report, 2012, Vaadin

Widgets

Es stimmt zwar, dass nicht genügend gute Widgets vorhanden sind. Aber ich empfinde das nicht als Nachteil. Denn eigene Widgets sind schnell programmiert. Wer eine coole Web Anwendung programmieren will, der muss so oder so die Widgets anpassen, damit sie seinen Ansprüchen entsprechen. Es gibt ausserdem viele Libraries wie z.B. Smart-GWT, welche besser Widgets anbieten.

Dev-Mode Refresh Time

Dies ist tatsächlich so, dass es etwas lange dauert, bis man seinen Code testen kann. Aber GWT hat den Super Dev Mode eingeführt, womit sich client code ohne neues Kompilieren schnell testen lässt. Für mich persönlich reichte der normale Dev Mode bis anhin. Den Super Dev Mode habe ich noch nicht ausprobiert.

Getting started with GWT is difficult

Weil der Ansatz wie man Webanwendungen entwickelt von GWT ganz anders ist als bei anderen Web Development Frameworks, braucht es einer ernsthaften Einarbeitung, bis man alle Konzepte verstanden hat. So können in clientseitigem Code zum Beispiel nicht alle Features von Java verwendet werden (z.B. kein Reflection).

Viele Wege führen nach Rom

Es werden immer wieder neue Konzepte eingeführt, welche dann ältere ablösen. Das bringt Vor- und Nachteile. So gibt es z.B. verschiedene Ansätze für die Kommunikation zwischen Server und Client oder verschiedene Möglichkeiten wie man Events behandelten kann. Bei der Entwicklung von GWT Anwendungen sollten sich die Entwickler am Anfang auf eine Technik einigen, wenn die entsprechenden Problemstellungen zur Anwendung kommen.

Persönliche Erfahrung mit GWT

Ich startet im Zuge meiner Bachelor Arbeit an der ZHAW in Winterthur mit dem Programmieren in GWT (2012).

Die Aufgabe bestand darin, ein Framework zu entwickeln, womit sich mobile Apps im Baukastenformat erstellen lassen. Der Benutzer der Anwendung sollte die Möglichkeit haben, verschiedene Module auszuwählen und diese dann als App zu publizieren. Der ganze Inhalt sollte im Web verwaltet werden können, wie in einem CMS. Die Entwickler sollten ausserdem die Möglichkeit haben, dass Framework individuell mit neuen Bausteinen zu erweitern, ohne den Core zu bearbeiten. Ein weiteres Key-Feature sollte die Skalierbarkeit sein. Es sollte möglich sein, das App-CMS auf einem Server zu betreiben und damit tausende Apps zu verwalten.

Architektur

Ich habe mich dann für GWT mit MVP-Architektur  für das Frontend und Google App Engine für das Backend entschieden. Alles wird in Java programmiert. Für die Persistenz wurde JDO verwendet.

Somit konnte ich das Framework losgelöst von den App-Bausteinen programmieren. Jeder Baustein konnte dann im Anschluss wiederum für sich entwickelt werden.

MVP-Archtiektur

Die MVP-Architektur ähnelt sehr der MVC-Architektur. MVP heisst Model-View-Presenter.

Ein Baustein besteht aus Client- und Serverklassen. Auf Serverseite bestehen hauptsächlich Model-Klassen. Die Clientklassen werden unterteilt in View-,Presenter- und Eventklassen sowie Proxy-Interfaces für die Servermodels.

MVP Klassendiagramm

MVP Klassendiagramm, Quelle: http://www.gwtproject.org/articles/mvp-architecture.html

AppController

Als Einstiegspunkt des Bausteins steht auf Clientseite der AppController. Dieser ist für die Logik verantwortlich, welche nicht in einem Presenter behandelt werden kann. So lädt dieser zum Beispiel die notwendigen Presenter-Klassen, welche dann für den Rest verantwortlich sind.

Model

Ein Model stellt eine Businessentität dar. Mit Hilfe von JDO-Annotationen werden diese Klassen auf dem Server persistiert. Der Client greift auf ein Proxy-Objekt zu und kann so direkt mit dem Server kommunizieren.

View

Eine View enthält alle UI Komponenten für diesen Baustein. In einer View werden alle Elemente angeordnet und mittels CSS designt. Ein View weiss nicht, welcher Inhalt in die Felder kommt, sondern nur, dass z.B. drei Labels und ein Bild dargestellt werden müssen.

Presenter

Im Presenter wird die ganze Logik abgebildet. Der Presenter lädt die Daten vom Server und bestimmt welche Daten durch die View dargestellt werden. Ausserdem ist er für das EventHandling der UI Komponenten und das History Management verantwortlich.

Um die Kommunikation zwischen View und Presenter zu gewährleisten, werden im Presenter Display-Interfaces definiert, welche von der View implementiert werden.

Struktur
MVP Struktur

MVP Struktur, Quelle: http://www.gwtproject.org/articles/mvp-architecture.html

Entwickeln mit GWT

Wer jetzt auf den Geschmack gekommen ist und mit GWT entwickeln möchte, der Informiert sich am besten unter gwtproject.org. Dort gibt es einige gute Tutorials. Pflicht für jeden Einsteiger ist das MVP Tutorial:

http://www.gwtproject.org/articles/mvp-architecture.html

http://www.gwtproject.org/articles/mvp-architecture-2.html

Wer diese zwei Artikel intensiv durchexerziert wird sehr schnell Spass am Entwickeln mit GWT finden und schnell die Vorteile erkennen gegenüber anderer Frontend Frameworks.

The gap between PhoneGap and Apache Cordova

Im Zuge von Mobile Apps wird oft von WebApps, native Apps und hybriden Apps gesprochen. Dabei fallen auch immer öfters die Stichworte PhoneGap oder Apache Cordova. In diesem Blogpost will ich die Begriffe PhoneGap und Apache Cordova erklären.

phonegap-cordova-logo

 

Was ist der Unterschied zwischen PhoneGap und Apache Cordova?

(more…)

GWT Blog-Serie – GWT im Vergleich zu jQuery Mobile und Sencha Touch (3/4)

mgwt

Quelle: https://code.google.com/p/mgwt/

Wer gegenwärtig ein mobile App entwickelt, der sollte sich vor der Konzeption entscheiden, ob er die App nativ oder als Web-App implementieren will. Die Entscheidung hängt oft davon ab auf welchen Plattformen die App zugänglich sein soll.

Soll die App nur auf einer Plattform verfügbar sein, dann ist die beste Lösung fast immer, die App nativ zu Entwickeln. Soll sie auf mehreren Plattformen erscheinen, dann wird der Kostenfaktor meist zum treibenden Argument gegen eine plattformspezifische Entwicklung, auch wenn die Performance von Animationen und Benutzerinteraktionen nicht das Niveau von nativen Apps erreichen.

Kommen die Entscheidungsträger zu diesem Punkt, fällt die Entscheidung oft auf eine Web-App mit jQuery Mobile. Doch es gibt noch andere Frameworks auf dem Markt, welche mobile Optimierung anbieten. So zum Beispiel Sencha Touch oder MGWT.

Als Mobile-Entwickler bei Namics und während des Studiums habe ich meine Erfahrungen mit all den erwähnten Technologien gesammelt. Ich arbeitete an nativen Apps für iOS und Android sowie plattformunabhängigen Apps mit Sencha Touch, jQuery Mobile und GWT.

Im vorherigen Blogpost ging ich auf die Performance-Optimierung von GWT ein. In diesem Teil meiner Blog-Serie will ich diese drei Frameworks vergleichen und vertieft auf die Performance von MGWT eingehen.

(more…)

Endnutzer und Redakteur – Wer pflegt die Web-Site?

Je mehr Benutzerdaten und Interaktion auf einer Web-Site verarbeitet werden, desto gefragter werden Web-Applikationen, die in ihren Datenbanktabellen Benutzerbeiträge (auch bekannt als User-Generated-Content UGC) speichern und die Web-Site lebendiger machen. Weiterhin bildet jedoch das Content-Management-System (CMS) des Unternehmens die Grundlage für den darzustellenden Content der Web-Site, sowie dessen Struktur. Redakteure und Endnutzer erstellen nun gemeinsam die Inhalte. Wie können die Vorteile von beiden Welten auf den jeweiligen Web-Seiten vereint werden?

Die Redakteure legen die Content-Struktur im CMS an und verfügen über Seitenvorlagen (auch Templates genannt). Die Seitenvorlagen beinhalten ein Layout und ggf. spezielle technische Funktionen. Die Seitenvorlagen sind somit als Teil der CMS-Lösung bereitgestellt und können meist nur durch technische Implementierung erweitert werden. Durch Anlage einer CMS-Seite, basierend auf einer der Seitenvorlagen, kann der Redakteur nun beliebige Seiten erstellen, Inhalte pflegen und deren Anordnung bestimmen. Die verschiedenen Inhaltstypen, die als Block platziert werden können, nennen wir Komponenten. Für statische Seiten, wie z.B. ein Impressum, sind diese Mittel auch ausreichend.

”"

Mit dem User-Generated-Content erhält man nun eine starke Vervielfachung, da die vielen Endnutzer auch entsprechend viele Beiträge über Web-Applikationen erfassen können. Um nicht für jeden Beitrag eine CMS-Seite anlegen zu müssen, möchte man die Beiträge einbetten, so dass eine CMS-Seite wieder als eine Art Vorlage für viele (dynamische) Web-Seiten dienen kann. Dies erreicht man über individuell angefertigte Komponenten, welche den passenden User-Generated-Content für die zu erzeugende Web-Seite darstellen. Um die richtigen Datensätze auswählen zu können, braucht die CMS-Seite zusätzliche Parameter, die in der URL enthalten sein sollten. Dies kann ein Query-String sein wie „?id=00012324“ oder auch ein Bestandteil des URL-Pfades „/immobilienanzeige/Das+Haus+am+See“. Durch die Definition entsprechender URL-Muster und –Regeln können aus der angefragten URL die CMS-Seite und mögliche Parameter hergeleitet werden.

Mit diesem Ansatz können Redakteure und Endnutzer die Web-Site gemeinsam bereichern.

 

GWT Blog-Serie – Wie GWT die maximale Leistung des Browser nutzt (2/4)

Im ersten Teil meiner Serie ging ich auf eine Umfrage über die Zukunft von GWT ein und beschrieb in Kürze, was GWT ist.
Ab 100 Zeilen JavaScript Code soll GWT besser optimiert sein, als würde man den Code selber schreiben. In diesem Teil der Serie, werde ich dieser Aussage auf den Grund gehen.

Performance von GWT dank Compiler

Sobald eine Web Anwendung gebaut wird, welche mehr als 100 Zeilen JavaScript Code verwendet, kann man davon ausgehen, dass GWT den besseren Code auswirft als würde man den Code selber in JavaScript schreiben. Verblüffende Aussage nicht wahr? Ich würde von mir behaupten, dass ich in der Lage sei, bei einem JavaScript von lediglich 100 Zeilen Code, ein Script zu schreiben, welches keine Performance-Leaks umfasst. Doch warum sollte ein von GWT optimiertes JavaScript performanter sein? Der Grund liegt im Java-zu-JavaScript Compiler. Dieser Compiler beschränkt sich nicht darin, den Code perfekt zu minifizieren und zu strukturieren, er offeriert noch einiges mehr.

Features des GWT Compilers:

  • Compile per Browser/Device
  • Dead Code Removal
  • Inlining
  • Renaming
  • Zipping
  • Secure caching

Compile per Browser/Device

Damit die Performanceoptimierung für jeden Benutzer ausgereizt werden kann, wird das JavaScript für jeden unterstützten Browser kompiliert. Dieser kompilierte Code enthält dann alle verwendeten JavaScript und CSS Ressourcen, welche genau für diesen Browser notwendig sind.

browsers

Quelle: http://diminiinc.blogspot.ch/2013/08/windows-browsers-comparison-august-2013.html

(more…)

Die Open-Data-Schatzkiste wurde geöffnet

Daten sind wertvoll

Daten sind das neue Gold. Das lässt sich durch den Datenhunger von Google, Facebook und der gesamten Werbe-Branche bestätigen. Nützliche, aus den Daten gewonnen Informationen sind Wissen und Wissen ist bekanntlich Macht.

Daten haben sich bereits in extremer Menge angehäuft und das Wachstum ist weiterhin exponential. Leider sind zu viele Informationen, welche für die Öffentlichkeit interessant sein könnten, aber unzugänglich. Das gilt vor allem auch für Daten von Behörden mit einem öffentlichen Interesse, beispielsweise von statistischen oder geographischen Ämtern. Für diese Daten hat der Steuerzahler bereits bezahlt und er hat ein Recht darauf diese zu nutzen. Oft sind diese Daten leider nur über Hürden und Umwege erhältlich. Entweder liegen sie in staubigen Aktenverzeichnisse oder sie sind als Download in einem nicht weiter verarbeitbarem Datenformat abrufbar oder die Nutzung ist gesetzlich nicht erlaubt. Open Data soll das ändern.

Open Data

Bei Open Data geht es darum Daten, welche vorher nicht zugänglich waren, sei es wegen der Form, dem fehlenden Zugang zu diesen Daten oder eines rechtlichen Verbotes, öffentlich zu machen. Ein Ordner mit statistischen Daten in einem Aktenschrank ist für die Öffentlichkeit unbrauchbar. Erst wenn die statistische Daten als Download bereitgestellt werden, kann Jedermann davon profitieren. Noch besser ist es, wenn ein Datenformat gewählt wird, der die Weiterverarbeitung erlaubt.

“Open data is data that can be freely used, shared and built-on by anyone, anywhere, for any purpose.”

Quelle: Laura James, CEO Open Knowledge Foundation, 3.10.2013

Vorteile der offenen Daten

Open Data schafft:

  • Transparenz
  • Innovation
  • Kosteneinsparungen
Quelle: Die Vorteile aus dem schweizerischen Open Data Manifest

Durch die erhöhte Transparenz kommt man eher zu neuen Erkenntnissen und Fehler werden schneller aufgedeckt. Die gewonnen Erkenntnisse schaffen Platz für Innovation und zum Teil massiven Kosteneinsparungen, wie ein Beispiel aus England zeigt.

“This is an exceptional example of Open Data being transformed into knowledge for everyone. It gives patients and GPs the tools they need to help realise big savings for the NHS – which is ultimately value for everyone.”

Quelle: Millions of Pounds in Prescription Savings Identified in Open Data by Innovative Startups

Grosse Datenmengen sind wie Goldminen mit versteckten Schätzen, die gefunden werden wollen. Mit den Daten lassen sich Visualisierungen erstellen, welche die Aussagekraft und Verständlichkeit der Daten erhöht (siehe Many Eyes von IBM oder die Visualisierung des Berner Budgets).

Wann sind Daten “offen”?

Daten gelten als offen wenn sie die Voraussetzungen der Definition des offenen Wissen erfüllen. Die Voraussetzungen bestehen aus elf Punkten welche den Zugang, die Nutzung und Integrität von Open Data beschreiben.

Open Data flower diagram

Bildquelle: Dr. Hans Rosling nutze dieses Bild in seinem TED Talk, und Tim Berners-Lee in seinen Slides

Daten ausgraben

Die technischen Vorraussetzungen (Punkt 4) von Open Data verlangen, dass Daten in einem offenen (im Gegensatz zu herstellerabhängigen / proprietären) Format als Download veröffentlicht werden. Beispiele für offene Datenformate sind JSON, XML und CSV. Bei CSV handelt es sich streng genommen nicht um einen Standard. Dies erklärt weshalb häufig unterschiedliche Trennzeichen für CSV-Attribute verwendet werden. Den Parsern zur Liebe sollte man sich auf Kommas einigen, schliesslich steht CSV für “Comma-Separated Values”.

Open-Data-Formate lassen sich mit einem Text-Editor öffnen und lesen. Word-Dokumente, Excel-Spreadsheets und PDFs sind ungeeignete Formate, da sie nicht wirklich offene Standards sind oder mit einem Texteditor öffnen lassen.

Tabellarische Daten auf seiner Website sollten auch als JSON, XML oder CSV (oder alle) verfügbar sein. Die Weiterverwendung der Daten sollte einfach gemacht werden.

Open Data können hürdenfrei, also ohne Authentifizierung, geographischer oder zeitlicher Einschränkung heruntergeladen werden.

Die Schweizerische Schatzkammer

Der Tagesanzeiger berichtete am 3. September 2013 über die Lancierung des Open-Data-Internetportals vom Bund. Endlich hat auch die Schweiz ein solches Datenportal. Staaten wie USA, Grossbritannien und Kenia praktizieren schon länger Open Data und habe bereits Datenportale. Bei den offenen Daten vom Staat, spricht man auch von Open Government Data (OGD). Mit diesen Daten lässt sich vieles machen, besonders in Kombination untereinander oder mit anderen Datenquellen.

Prominente Unterstützung

Die Open-Data-Bewegung kann auf prominente Unterstützung zählen. Sir Tim Berners Lee, der Erfinder des World Wide Webs beschreibt in seinem Artikel “Linked Data” und “Linked Open Data” und stellt eine Bewertungs-Schema für die Offenheit von Daten vor. Daten im Web sollen auch verlinkt werden können, genau wie Dokumente mit Hyperlinks verknüpft sind. Die notwendigen Schritte zu Open Data und Linked Open Data können von der 5-Sterne-Bewertung entnommen werden.

“This is for everyone #london2012 #oneweb #openingceremony @webfoundation @w3c”

Quelle: Tim Berners-Lee, Olympiade 2012 in London
5 star Linked Open Data on mug
Bildquelle

Fazit

Open Data lohnt sich. Für alle.

“You can give your data away now – and generate revenue and jobs, and even save money from the better information and decisions that will flow.”

Quelle: Neelie Kroes, Vize-Präsidentin der europäischen Kommission verantwortlich für die digitale Agenda, 12.12.2011

Diesen Monat und im November finden die von Open Data Zürich und OpenData.ch organisierten Open Data Zürich Hacknights 2013 statt. Als Open Data Enthusiast freue ich mich schon darauf.

Weblinks

GWT Blog-Serie – 88.84 Prozent würden Google Web Toolkit wieder einsetzen… (1/4)

Die Firma Vaadin lancierte 2012 eine Umfrage in der GWT Community zum Thema “Zukunft von GWT”. Aus den Antworten von über 1300 Teilnehmern entstand ein 32-seitiger Bericht darüber, wer GWT benutzt, in welchem Umfeld GWT eingesetzt wird, wo die Stärken und Schwächen von GWT liegen und wo der Weg von GWT hinführt.

Back_to_the_Future_gwt

Im ersten Teil meiner Serie gehe ich auf Details dieses Reports ein und beschreibe kurz und knapp was GWT ist.

(more…)

Drupal auf dem 10-Meter-Brett

Die drei Tage voller Sessions der Drupalcon 2013 sind gestern in Prag zu Ende gegangen. Was für uns bleibt ist gespannte Vorfreude auf nächstes Jahr und Ungeduld alle neu gelernten Tricks und Methoden in der Praxis auszuprobieren.

Die Konferenz selbst zeichnete sich wie üblich durch eine breite Vielfalt an Talks von Frontend bis CMS-Kern über Business zu Support aus. Insbesondere die technischen Talks befassten sich in der Mehrheit mit dem noch nicht veröffentlichten Release Drupal 8.

jump1
Bild: Creative Commons BY von Therme Loipersdorf

Das Brett

Drupal 8? Wer noch nichts von der kommenden Version gehört hat dürfte überrascht sein was alles im achten Release des Drupal-Kerns drinsteckt: Grosse Teile wurden durch Komponenten aus anderen Systemen ersetzt, so dass viele Komponenten nun auf dem PHP-Framework Symfony2 aufsetzen. Weitere integrierte Fremdtechnologien sind die Templating-Abstraktion mit Twig, PHPUnit, BackboneJS und YAML, um die wichtigsten zu nennen.

Der technologische Wandel, das Sprungbrett, ist definitiv der grösste Abstand, den es bisher zwischen zwei Versionen gab und es teilt die Community in gewisser Weise. Es verwundert nicht, dass innerhalb dieses Klimas auch ein Fork zum Stand vor Symfony geschah. Zumindest an der Drupalcon war die Atmosphäre wie wir sie erlebten diesem Wandel grösstenteils positiv gegenübergestellt. Es fehlte nicht an Talks, die versuchten bisher in Drupal nicht verwendete Methoden und Strategien der Softwareentwicklung näherzubringen.

Gründer Dries sagte in seiner Keynote, dass Drupal 8 kommt “when it’s ready” und das soll Frühjahr 2014 sein. Das macht etwas ungeduldig, weil produktiver Einsatz dann frühestens im Sommer möglich sein wird, wenn genügend Contrib-Module nachgezogen haben, was im einfacheren Sprung auf Drupal 7 auch eine signifikante Zeit dauerte.

drupalcon_grouphoto
Bild: Creative Commons BY-SA von Michael Schmid

Der Sprung

Gelingt der Sprung mit Fokus auf Objektorientierung, Erhalt von Flexibilität und die Behebung struktureller technischer Mängel auf dem Grossteil der Codebasis der Community (und nicht nur im Kern) dürfte Drupal ein gänzlich anderes Projekt sein als noch vor wenigen Jahren, aber ein umso spannenderes aus Techniksicht wie auch in der Breite der Einsatzgebiete für den Kunden.

Was wir sehen durften, was Drupal 8 jetzt kann, wie Probleme im Page-Caching, der Mehrsprachigkeit, der Konfiguration und vielen weiteren Aspekten gelöst sind, wird Drupal einen klaren Schritt attraktiver zum Enterprise-Einsatz und hebt sich umso mehr von anderen Content-Management-Lösungen im PHP-Bereich ab. Die Lücke zu etablierten kommerziellen Produkten wird im Kernbereich Content kleiner.

Nur das mit dem ganzen Singen auf der Drupalcon werden wir wohl nie verstehen.

Page 10 of 198« First...89101112...203040...Last »