Die Idee ist fixiert, die Entwicklung beginnt, es folgen die bekannten Aufgaben: Layout von Logik trennen, eine passende Datenbank finden und die Browser-Unabhängigkeit gewährleisten. Doch das Rad rollt bereits, warum also neu erfinden? Und die angebotenen Frameworks und Tools sind keineswegs überladene Alleskönner. Vielmehr tendieren die Hersteller zu spezialisierten Lösungen, die keine Leistungseinbußen durch zuviel Funktionalität mit sich bringen. Es gilt daher die Devise: Je spezifischer die Anforderung, desto passender das Framework. Der Vielzahl der Angebote entsprechend erhebt dieser Rundgang keinen Anspruch auf Vollständigkeit, sondern liefert auf den folgenden Seiten und in der anschließenden Tabelle einen Überblick der wichtigsten Vertreter.

CSS und HTML

Gerade bei der Browser-Unabhängigkeit gibt es viel zu tun. Da verwundert es kaum, dass gerade auf diesem Gebiet zahlreiche Bibliotheken um die Gunst der Entwickler buhlen. Etwa, um das Design zu vereinheitlichen. Darum kümmern sich CSS-Frameworks wie „960 Grid System“. Das Framework teilt eine 960 Pixel breite Seite in zwölf oder sechzehn Spalten ein. Über CSS-Klassen werden HTML-Blockelemente dann auf die Spalten verteilt, um ein stets einheitlich ausgerichtetes Gerüst zu erhalten.

Eher Geschmackssache sind CSS-Frameworks, die für ein typografisch einheitliches Bild sorgen oder Formulare „verschönern“. Um entsprechend Einfluss nehmen zu können, enthalten manche solcher Bibliotheken HTML-Templates. Sie sorgen zudem für optimierte Tabellen, W3C-konforme HTML-Mails oder bringen mit „Hacks“ technologisch humpelnde Browser wieder auf die Beine.

In eine gänzlich andere Kerbe schlagen „less“ und „Sass“: Sie erlauben den Einsatz von Funktionen, Variablen und Verschachtelungen in eigenem CSS-Code [1]. Das erleichtert etwa den Umgang mit Farbcodes oder mehrfach eingesetzten Effekten.

JavaScript

Ebenfalls der Browser-Unabhängigkeit geschuldet sind JavaScript-Frameworks. Sie verkürzen und vereinheitlichen Standard-Befehle der Skriptsprache, etwa den mühseligen Zugriff auf einzelne HTML-Elemente via „document.getElementById('id').style.display = 'none'“. Die Bibliothek „Prototype“ macht daraus ein simples „$('id').hide()“. Natürlich unabhängig vom verwendeten Browser und inklusive diverser Abfragen, ob das Element überhaupt existiert.

Neben derartiger Entwickler-Freiheit liegt die Stärke der JavaScript-Frameworks vor allem in der Usability: Tabellen sortieren, Inhalte verstecken und Formular-Eingaben auf ihre Richtigkeit prüfen funktioniert ohne Server-seitigen Code und mittels weniger Zeilen JavaScript. Auch AJAX, die portionierbare Server-Kommunikation durch die Hintertür, Drag and Drop und diverse Animationen sind mit den Bibliotheken möglich.

Rich Internet Applications (RIA)

Von einer Rich Internet Application ist die Rede, wenn der Nutzer mit der Seite interagieren kann, als befände er sich in einer Desktop-Anwendung. In die Klasse der „RIAs“ rutschen also sämtliche Frameworks, die das Erstellen solcher Applikationen unterstützen. Dass in dieser Kategorie mit „jQuery UI“ ein Namensvetter des JavaScript-Frameworks „jQuery“ auftaucht, ist also nur mitnichten Zufall: Die RIA-Version der Bibliothek enthält neben CSS- und JavaScript-Bibliothek ordnerweise Bilder und Symbole, die je nach Farbschema der eigenen Seite eingebunden werden.

Doch nicht nur mit HTML, CSS und JavaScript sind Anwendungen realisierbar, auch über Browser-Plugins wie Flash oder Silverlight ist ein beinahe natives Erlebnis möglich. Entsprechend warten Adobe und Microsoft mit Frameworks auf, um die Entwicklung solcher Applikationen zu erleichtern. Vorraussetzungen dafür sind neben einem entsprechend motivierten Benutzer vor allem ein Betriebssystem und ein Browser, die das Plugin auch zulassen. Was nach einem lächerlichen Apple-Adobe-Streit klingt, erlangt durch die stetig steigende Zahl mobiler Geräte neue Bedeutung.

Die Entwicklung kann dabei auf verschiedene Arten erfolgen: Entweder entwickelt man eine Web-App programmatisch und hat die volle Kontrolle über den Quellcode. Oder man verwendet Frameworks, die durch ihre vordefinierten Templates und Funktionen die Entwicklung erheblich erleichtern (können).

Web-App in Handarbeit

Ein Vorteil der Web-App-Programmierung ist der einfache Einstieg für Web-Entwickler, da sie keine neue Programmiersprache erlernen müssen, sondern ihr bisheriges Wissen in die Entwicklung einer mobilen Website einfließen lassen können. So sieht eine einfache App, die ein Bild und eine Überschrift anzeigt, kaum anders aus als eine herkömmliche HTML-Seite. Allerdings wird diese später auch offline verfügbar sein.

Only for iPhone

Ruft man diese Website mit dem iPhone (ab iOS 3.0) auf, so wird, während die Inhalte der Startseite geladen werden, ein so genannter Splashscreen, also ein Lade-Bild, angezeigt („apple-touch-startup-image“). Das Meta-Tag „viewport“ legt die Auflösung fest, mit der die Seite vom Browser gerendert werden soll. Im Beispiel soll die Auflösung des Geräts verwendet werden. Zusätzlich wird die initiale Skalierung der Seite festgelegt und ob der Inhalt der Seite durch den User skaliert werden darf (etwa durch „Pinch to Zoom“).

<?xml version=„1.0“ encoding=„utf-8“?>
<!DOCTYPE html>
<html manifest=„config/cache.manifest“>
<head>
 <title>A simple Web-App</title>
 <meta name=„viewport“ content=„width=device-width, initial-scale=1.0, user-scalable=no“ />
 <meta name=„apple-mobile-web-app-capable“ content=„yes“ />
 <meta name=„apple-mobile-web-app-status-bar-style“ content=„black“ />
 <link rel=„apple-touch-icon“ href=„images/icon.png“ />
 <link rel=„apple-touch-startup-image“ href=„images/splashscreen.png“ />
 <link rel=„stylesheet“ href=„css/simple.css“ type=„text/css“ media=„screen,mobile“ />
 <script type=„text/javascript“ xsrc=„js/simple.js“></script>
</head>
<body>
 <header>
 <h1>Eine einfache Web-App</h1>
 </header>
 <section id=„content“>
 <img xsrc=„images/picture.jpg“ />
 </section>
</body>
</html>

Die drei Meta-Tags in Listing 1 werden derzeit nur von iOS interpretiert. Alle anderen mobilen Betriebssysteme ignorieren diese Tags, sodass sich keine Komplikationen dadurch ergeben.

Setzt man das Attribut „content“ beim Meta-Tag „apple-mobile-web-app-capable“ auf „yes“, so wird die Web-App nach dem Aufruf über den Homescreen im Vollbild-Modus ohne Browser-Leiste angezeigt. „apple-mobile-web-app-status-bar-style“ definiert das Aussehen der Status-Leiste und kann einen der folgenden Werte annehmen:

• default (grau)
• black (schwarz)
• black-translucent (schwarz, transparent)

App-Icon

Um die Web-App mit dem Homescreen des iPhones zu verknüpfen, wird ein Icon in der Größe 114x114 Pixel im Format PNG benötigt. An dieser Stelle besteht die Möglichkeit, mehrere „apple-touch-icons“ mit unterschiedlichen Größen anzugeben. Für das Beispiel wird die Icon-Größe des iPhone 4 verwendet, da die älteren iPhones dieses Icon in einer akzeptablen Qualität herunterrechnen können.

Android unterstützt App-Icons ab Version 2.1, das passende Tag heißt „apple-touch-icon-precomposed“. Wird ausschließlich dieses Tag verwendet, stellt das iPhone das App-Icon allerdings ohne die Standard-Effekte wie abgerundete Ecken, Schattierungen und Reflexionen dar; das Icon gilt dann als „precomposed“.

<link rel=„apple-touch-icon-precomposed“ href=„icon_android.png“ />

Offline arbeiten

Eine wichtige Eigenschaft von Web-Apps ist es, Inhalte auch offline verfügbar machen zu können. HTML5 stellt Webseiten dafür einen sogenannten Application Cache zur Verfügung, mit dessen Hilfe Inhalte auch ohne Netzverbindung verwendet werden können. Die Einbindung dieses Caches ist recht einfach, da es sich hierbei um ein Manifest handelt, das in Form einer Textdatei vorliegen muss.

CACHE MANIFEST
# 2011-10-26 Version 1.0

CACHE:
index.html
css/simple.css
js/simple.js
images/splashscreen.png
images/picture.jpg

NETWORK:

FALLBACK:
*.html /offline.html

Im CACHE-Bereich des Manifests werden alle Ressourcen angegeben, die vom Browser zwischengespeichert werden sollen. Unter NETWORK werden alle Ressourcen aufgelistet, die nicht speicherbar sind. Dazu zählen etwa Schnittstellen wie jene der Twitter-API. Sollten bestimmte Resourcen nicht verfügbar sein, so können im FALLBACK-Bereich Alternativen festgelegt werden. Im Beispiel wird festgelegt, dass für jede nicht vorhandene HTML-Seite die Datei „offline.html“ angezeigt werden soll.

Der Application Cache wird durch das Attribut „manifest“, das den Pfad zum Manifest enthält, im HTML-Tag aktiviert. Damit der Browser das Cache-Manifest interpretieren kann, muss dieses mit dem MIME-Type „text/cache-manifest“ vom Server ausgeliefert werden.

Cache aktualisieren

Um den Cache einer Web-App zu aktualisieren, leert der Benutzer entweder den Browser-Cache oder der Inhalt des Cache-Manifests ändert sich. Es reicht also nicht aus, dass sich der Inhalt einer Datei ändert. Im Beispiel-Manifest wird deshalb ein Datum und eine Versionsnummer in Form eines Kommentars verwendet. Ändert sich eine Datei, reicht es, im Manifest das Datum und die Version anzupassen, um der Web-App Änderungen mitzuteilen.

Design, Layout und UX

Um der Web-App einen nativen App-Look zu verpassen, kommen diverse CSS3-Eigenschaften zum Einsatz. CSS3 erfährt eine breite Unterstützung unter den mobilen Browsern, daher stellt es für Web-App-Entwickler ein äußerst nützliches Werkzeug dar. Einige der Eigenschaften im Überblick:

• Eigene Schriftarten in eine Webseite zu integrieren ist eigentlich kein neues Feature von CSS3, denn „@font-face“ wurde bereits mit CSS2 eingeführt. In der neuen Version unterstützt „@font-face“ jedoch beliebige TrueType- oder OpenType-Schriftarten.

@font-face {
 font-family: Monospace;
 src: url('fonts/own_monospace.otf');
}

• Dank CSS3 können Texte und Boxen mit einem Schatten versehen werden, ohne dafür spezielle Grafiken laden zu müssen. Das Rendering der Schatten ist allerdings sehr rechenintensiv, daher sollte sparsam mit diesen optischen Elementen umgegangen werden.

/* Die erzeugten Schatten sind nach oben und rechts je zwei Pixel breit. Der dritte
* Parameter bestimmt den Blur-Effekt, der letzte die Farbe des Schattens. */
box-shadow: 2px 2px 2px #000;
text-shadow: 2px 2px 2px #000;

• Auch abgerundete Kanten und Verläufe können mit CSS3-Bordmitteln realisiert werden. Aufgrund der neuen Tags sind auch hier die Grafiken überflüssig, was die Performance verbessert und damit die Ladezeit verkürzt.

/* Vier Angaben im Uhrzeigersinn für jede Ecke */
border-radius: 5px 5px 5px 5px;

/* Zwei Angaben, wodurch die untere linke Ecke den Wert der oberen linken und die
* rechte untere Ecke den Wert der rechten oberen Ecke übernimmt */
border-radius: 5px 5px;

/* Eine Angabe für alle vier Ecken */
border-radius: 5px;

/* Parameter eins legt fest, ob der Verlauf linear oder radial verläuft.
* X- und Y-Koordinaten legen den Start- und Endpunkt (2. und 3. Parameter) fest.
* Die beiden letzten Parameter schließlich definieren die beteiligten Farben. */
-webkit-gradient(linear, 0 0, 0 100%, from(#FFFFFF), to(#0000FF);

Das Anforderungsprofil einer Webseite kann man schnell auf einen Nenner bringen: Der Anwender sollte eine Seite jederzeit erreichen und benutzen können – egal ob am großen Bildschirm daheim, am Laptop im Café oder auf dem Smartphone in der U-Bahn. Es geht darum, Inhalte bereitzustellen, die der User ohne Mühe immer und überall konsumieren kann.

Das ist auch im Sinne eines jeden Webseitenbetreibers, denn schließlich möchte man keinen Besucher ausschließen, nur weil dieser zufällig gerade per Smartphone im Web unterwegs ist. Betrachtet man die Desktop-Version für große Monitore als gesetzt, hat ein Webentwickler drei Möglichkeiten, eine mobile Variante bereitzustellen:

• Er liefert die Webseite eins zu eins mit der vollen Gesamtbreite (gewöhnlich ab 900 oder gar 1100 Pixel) auch an Smartphones aus. Der Benutzer muss bei dieser Variante oft zoomen, um Texte lesen zu können, Bilder anzuschauen oder um einen Überblick zu erhalten, welche Bereiche der Webseite er sich näher ansehen möchte.
• Der Webentwickler liefert zusätzlich zur Desktop-Version eine mobile Variante einer Webseite aus – mit eigenem Design und möglicherweise sogar eigenen Inhalten. Der Benutzer erhält eine grafisch reduzierte Variante, kann schnell durch die Inhalte surfen, hat aber auch keinen Zugriff auf die Inhalte der Desktop-Version.
• Die Webseite passt sich automatisch der Darstellungsgröße des Browsers an. Bei großen Bildschirmen geizt man nicht mit Platz und die Inhaltselemente zeigen eine große Typographie und viel Whitespace. Bei kleinen Bildschirmen arrangieren sich die Elemente der Webseite hingegen so, dass die Darstellung auch bei Platzmangel überzeugen kann – ohne dass der Benutzer zoomen muss.

Letzteres klingt doch mal richtig gut, oder? Responsive Web Design macht es möglich. Mit den neuen Möglichkeiten von HTML5, CSS3 und JavaScript können Webentwickler vorgeben, wie sich die Webseite der Darstellungsgröße anpasst und nicht, wie sich der Benutzer an die Webseite anpassen muss, um die Inhalte zu konsumieren. Das funktioniert unter anderen dank CSS3-Mediaqueries.

CSS3-Mediaqueries

Mit den CSS3-Mediaqueries kann man ein HTML-Element je nach Eigenschaft des darzustellenden Browsers ein anderes Aussehen verpassen. So könnte man die Seite auf einem Desktop-Rechner mit großem Bildschirm mehrspaltig nebeneinander zeigen. Neben der breiten Inhaltsspalte hätten dann noch zwei oder sogar drei Randspalten mit Zusatzinformationen Platz. Auf Smartphones hingegen müsste man den Inhalt linear, also unter- und nacheinander aufreihen, damit der Anwender den Inhalt einfacher lesen kann. Bei identischem HTML können Webentwickler so ein wenig mit CSS nachhelfen. Ein Konstrukt mit Mediaqueries könnte so aussehen:

Mediaqueries innerhalb einer CSS-Datei

@media screen and (max-width: 768px) and (orientation: portrait) {
	.meinElement {
		background-color: #c22;
	}
}

Zur Erklärung: Man gibt dem Element mit der CSS-Klasse „meinElement“ eine rote Hintergrundfarbe, wenn der Bildschirm eine Breite von 768 Pixeln nicht überschreitet und im Falle eines mobilen Gerätes im Hochformat gehalten wird.

Ein knappes Dutzend Eigenschaften [1] wie width/height, device-width/device-height oder sogar device-aspect-ratio kann man mit den Mediaqueries zwar nicht ausgeben, aber sich je nach Unterstützung durch den jeweiligen Browser zur Nutze machen.

So kann man also zuvor definierte Eigenschaften eines HTML-Elements in CSS für Auflösungen unter einer bestimmten Breite (max-width für den Browser und max-device-width für das Gerät insgesamt) oder über einer bestimmten Breite (min-width/min-device-width) überschreiben.

Die Mediaqueries kann man auf unterschiedliche Art und Weise einbinden, um sie zu nutzen. Als gesonderte Stylesheet im HTML:

<link rel="stylesheet" href="bigscreen.css" media="screen and (min-width: 1024px)">

als @import-Regel innerhalb eines Stylesheets:

@import url("bigscreen.css") screen and (min-width: 1024px);

oder eben auch als Block um CSS-Definition, wie im oberen Beispiel zu „.meinElement“.

Damit die Mediaqueries überhaupt greifen, und da das ständige rein- und rauszoomen den Lesefluss schnell trüben kann, gilt es, die Verkleinerung zu unterbinden. Vom iPhone kennt man dieses Verhalten: Der Browser zeigt eine große Webseite verkleinert auf dem Display an, mit einem Doppeltip auf das Display oder einer Wischgeste kann man einen Bereich vergrößern. Dazu hat Apple ein HTML-Meta-Element für den <head> einer Seite eingeführt, das sich mittlerweile zum de-facto-Standard gemausert hat:

<meta name="viewport" content="initial-scale=1.0, width=device-width">

Mit ihm setzt man den Zoom-Level auf 1.0 (100%) und gibt an, dass der Darstellungsbereich des Browsers genau so breit sein soll wie die Bildschirmbreite. Dass ist wichtig, denn auch ein iPhone mit der Bildschirmbreite von 768 Pixeln soll genau 768 Pixel darstellen. Das verhindert – Unterstütztung des Browsers vorausgesetzt – das Rein- und Rauszoomen und damit die lästige Arbeit beim Surfen.

Im Jahr 2011 war das Thema Sicherheit im Internet medial präsenter denn je. Nicht nur in den einschlägigen Kreisen, sondern auch in den klassischen Massenmedien Radio, Fernsehen und Zeitung wurde viel darüber berichtet. Hacker-Gruppierungen wie „LulzSec“ oder „Anonymous“ haben anhand prominenter Beispiele gezeigt, dass sogar die „großen“ Firmen offensichtlich nicht genug in die Absicherung ihrer eigenen Systeme investieren. Ob nun die GEMA, Sony oder gar die CIA – Hacker sind in ihre Systeme eingedrungen und haben sich entweder geheime Informationen angeeignet oder aber die Websites lahmgelegt. Das zeigt auch, dass auf diesem Gebiet aktuell sowohl Wissensmangel als auch Handlungsbedarf besteht.

Dem Kompromittieren (Hacken) einer Website liegen unterschiedliche Motivationen zugrunde. Es können Freizeit-Spaß, Ruhm und (Hacker-)Ehre oder aber schlicht finanzielle Interessen sein. Denn dem finanziell motivierten Hacker kommt die Kaninchenzüchter-Website gerade recht, wenn er dort ohne viel Aufwand ein paar Links zu dubiosen pharmazeutischen Händlern unterbringen kann. Wer eine Internetseite betreibt, sollte deshalb grundsätzlich damit rechnen, Angriffsversuchen ausgesetzt zu sein. Dabei ist es egal, ob für die Website WordPress, Drupal, TYPO3 oder einfache HTML-Seiten im Einsatz sind. Im Folgenden wird generell auf die Problematik eingegangen, wobei TYPO3 an einigen Stellen als Beispiel dient.

Was ist eine sichere Internetseite?

Allgemein gesprochen gilt etwas als sicher, wenn die Integrität, Erreichbarkeit und Vertraulichkeit gewährleistet ist. Eine Website ist unsicher, wenn unerwünschte Inhalte untergebracht werden können, sie gar keine Inhalte mehr liefert oder der Zugriff auf vertrauliche Informationen möglich ist. Eine Internetseite sicher zu betreiben bedeutet also, eben dies zu verhindern. Was einfach klingt, kann aber durchaus eine komplexe und aufwändige Angelegenheit sein. Grundsätzlich gilt: Je größer der Schaden sein kann, desto mehr Aufwand muss man in die Absicherung investieren. Die CIA wird hier zwar sicher mehr Budget haben als die Kaninchenzüchter, trotzdem können beide Seiten ausreichend abgesichert werden. Handlungsbedarf besteht aber nicht nur, nachdem eine Website kompromittiert wurde, sondern schon vorher. Und dafür gibt es vier überlebenswichtige Grundregeln.

1. Updates

Es ist unerlässlich, die eingesetzte Software auf dem Server (bspw. TYPO3), aber auch den eigenen PC, der ja zur Administration der Website verwendet wird, aktuell zu halten. Dadurch werden zumindest bekannt gewordene Sicherheitslücken geschlossen. Für Software auf dem PC wird man in den meisten Fällen benachrichtigt, sobald Updates vorhanden sind. Für Benachrichtigungen über Aktualisierungen der eingesetzten Software auf Server-Seite abonniert man am besten die entsprechenden Newsletter, Mailinglisten oder RSS-Feeds. Im Falle von TYPO3 ist das etwa die Mailing-Liste [1]. Ebenfalls eine gute Anlaufstelle ist Heise Security [2], die über alle bekannt gewordenen Sicherheitsprobleme berichten.

2. Backups

Die Nützlichkeit und Notwendigkeit, ein regelmäßiges Backup anzufertigen, liegt auf der Hand. Allein um das Sicherheits-Kriterium der Erreichbarkeit gewährleisten zu können, wenn es zu Datenverlust durch Fehlbedienung oder Fehlfunktion kommt. Ebenso unabdingbar ist die Verfügbarkeit eines Backups, wenn eine Website nach einem erfolgreichen Agriff kompromittiert und verändert wurde.

Die OpenID-Foundation [1] hat Single Sign-On sicherlich nicht erfunden, aber sie hat es, zumindest in Entwicklerkreisen, populär gemacht. Während die wenigsten Netizens etwas mit den Begriffen SAML, Information Card oder Shibboleth anfangen können, sind die meisten doch auf irgendeine Art mit OpenID in Berührung gekommen.

Denn die Mission der OpenID-Foundation ist die Entwicklung eines Standards zum sicheren, schnellen und einfachen Login. Trotz großer Partner wie Google, Yahoo, MySpace und AOL hat OpenID aber ironischerweise genau das Gegenteil bewirkt.

Um den Ansprüchen von Google und Yahoo gerecht zu werden, wurde OpenID um etliche, teilweise optionale, Funktionen erweitert [2]. Da aber nicht jede Plattform die gleichen Anforderungen an einen Identity-Provider hat oder die Ressourcen zur Umsetzung fehlen, gibt es heute eine Vielzahl von OpenID-Servern, die sich technisch so sehr unterscheiden wie Facebooks Connect von „Sign in with Twitter“.

Auf der anderen Seite stehen eben jene gerade Erwähnten, Twitter und Facebook, die sich, unter anderem wegen der enormen Komplexität, bewusst gegen OpenID und für OAuth entschieden haben.

Doch nicht nur auf technischer Seite wurden Fehler begangen. Bis heute sind die Themen OpenID und Single Sign-On keine Themen für die breite Masse. Statt an der Usabitity [3] oder einer einheitlichen Oberfläche zu arbeiten, sorgte noch mehr Technik für noch weniger Akzeptanz. Nutzer mussten den Begriff OpenID kennen, URLs als Identifier akzeptieren und verstehen, warum ein Google-Login für einen Login an anderer Stelle wichtig ist.

Nach Angaben der OpenID-Foundation sind derzeit knapp eine Milliarde Nutzerkonten als OpenID nutzbar [4] ; das macht den Standard wohl zu „The Web's Most Successful Failure“ [5]. Letztes Jahr hat die OpenID-Foundation eine Menge ähnlicher Kritiken einstecken müssen. Bekannte Firmen wie 37signal entschlossen sich im Laufe der Zeit dafür, sich von dem offenen Standard zu distanzieren.

Die OpenID-Foundation scheint diese Vorwürfe und Abgänge aber ernst zu nehmen und arbeitet an diversen Projekten, um die bisher begangen Fehler in den Griff zu bekommen. Doch auch andere Organisationen und Firmen arbeiten an möglichen Alternativen.

Google Identity Toolkit

Durch das Chaos der unterschiedlichen OpenID-Implementierungen und der vielen alternativen Identity-Provider wie Facebook und Twitter ist ein ganz neues Geschäftsmodell entstanden. Unternehmen wie Janrain, Ping-Identity oder Gigya verdienen ihr Geld mit Login-Mechanismen „as a Service“. Der jüngste Dienstleister in diesem Sektor ist Google mit seinem Identity Toolkit [6].

Das Toolkit lässt sich über eine relativ simple JavaScript-API implementieren und übernimmt die komplette Logik des Anmeldeprozesses. Damit schaffen Google und Janrain das, was OpenID eigentlich leisten wollte: Sie implementieren einen einfachen und standardisierten Single-Sign-On-Weg. Das Identity Toolkit ist aber vor allem deshalb interessant, weil es als erster Service den, von der OpenID-Foundation entwickelten, Account Chooser anbietet.

Fluid-Snippets in Netbeans

Mag. Artikel Heft 24

Bei der Arbeit mit Fluid fallen zwei Dinge sofort auf: Es ist sehr viel Code nötig, und durch die zunächst ungewöhnliche Notation entstehen immer wieder Fehler, die man schwer findet. Da wäre eine Art Snippet-Verzeichnis praktisch, mit dem man oft benötigte Code-Fragmente auf Knopfdruck einfügen kann. Zumindest für die beliebte IDE Netbeans [1] gibt es nun etwas Derartiges – so genannte Code Templates [2]. Eine überarbeitete und erweiterte Version der Datei findet sich außerdem bei Typovision [3].

Nach dem Download lassen sich die Templates in Netbeans über „Einstellungen, Import“ laden. In den Import-Optionen reicht ein „All“ und „OK“. Nach einem Neustart stehen die Code-Templates zur Verfügung. Um nun ein Code-Template zu verwenden, reicht in einer Fluid-Datei (Typ: HTML) ein Code-Schnipsel aus der abgedruckten Tabelle. Ein anschließender Klick auf Tab fügt das zugehörige Fragment ein.

String-Vergleiche in Fluid

Im If-ViewHelper von Fluid kann man über die Eigenschaft „condition“ nahezu alles vergleichen – Zahlen (kleiner, größer, gleich), Booleans (TRUE, FALSE) etc. – nicht jedoch auf Gleichheit mit einem String. Einem Bugtracker-Eintrag zufolge sei das schwierig zu implementieren.

Aber gerade eine solche Abfrage braucht man in der Praxis relativ oft. Man kann nun anfangen, über den Alias-ViewHelper eben einen Alias für den abzufragenden String zu erstellen und gegen diesen zu prüfen. Das bringt allerdings zwei Nachteile mit sich: Für jeden abzufragenden String müsste der in Frage kommende Programmteil mit einem Alias-ViewHelper ummantelt werden. Außerdem wird der Code unübersichtlich, da an der Stelle der Überprüfung nun nicht mehr der Prüfstring selbst, sondern der Alias verwendet wird – beides also suboptimal. Auch das Schreiben eines eigenen ViewHelper scheint nicht adäquat.

Aber es geht auch einfacher: Die beiden Operatoren müssen dazu lediglich in ein Array verwandelt werden und schon funktioniert der Vergleich wie gewünscht.

<f:if condition="{0:blog.title} == {0:'Testtitel'}">
	Funktioniert: Der Titel lautet 'Testtitel'.
</f:if>

Kommentare im ViewHelper

Um im anfänglichen Code-Gewusel der Views den Überblick nicht zu verlieren, eignen sich Kommentare zur Strukturierung. Da man sich aber letztlich in HTML befindet, ist es eben nur möglich, HTML-Kommentare zu verwenden. Diese allerdings sind im Quellcode selbst sichtbar.

Eine andere Lösung muss also her. Hier bietet es sich an, einen eigenen ViewHelper zu erstellen, der nichts anderes macht, als Kommentare nicht anzuzeigen: Nach der Installation der Extension „efempty“ – diese enthält ein Extbase/Fluid-Grundgerüst – wird der ViewHelper um eine Klasse erweitert. Im Verzeichnis Classes/ViewHelpers/ genügt dafür eine Datei CommentViewHelper.php mit folgendem Inhalt:

<?php
class Tx_Efempty_ViewHelpers_CommentViewHelper extends Tx_Fluid_Core_ViewHelper_AbstractViewHelper {
	public function render() {
		return '';
	}
}
?>

Anschließend reicht überall dort, wo der ViewHelper verwendet wird, eine Namespace-Anweisung am Anfang der Datei.

{namespace tv = Tx_Efempty_ViewHelpers}
...
<tv:comment> Hier können Sie nun beliebig kommentieren. Sie können sogar andere ViewHelper auskommentieren! :-)</tv:comment>

Übersetzte Fehlermeldungen

Wer mittels „<f:form.errors>{error.propertyName} {error.message} {error.code}</f:form.errors>“ Fehlermeldungen ausgibt, wird schnell feststellen, dass diese lediglich in englischer Sprache erscheinen. Übersetzen lassen sich die Ausgaben nicht, denn bislang sind sie hart kodiert (dies soll sich zukünftig ändern).

Um dieses Problem zu lösen, ist etwas Fantasie nötig: Für jeden Fehler gibt es einen eindeutigen Code. Dieser besteht laut Vereinbarung aus dem Timestamp, an dem der Fehler „erfunden“ wurde. Daher kann davon ausgegangen werden, dass es in einem System nur einen Fehler mit eben dieser Meldung gibt. Somit kann über den Translate-ViewHelper und den Code als Schlüssel die Fehlermeldung übersetzt werden.

<languageKey index="de" type="array">
	<label index="1221560718">Der Wert ist leer!</label>
</languageKey>

<f:translate key="{error.code}" />

Kanban [1] ist ein relativ neues, schlankes Vorgehensmodell zum einfachen Verwalten von Entwicklungsprozessen. Man hat sich dabei die Grundprinzipien der – ursprünglich von Toyota für die Automobilindustrie entwickelten – „Lean Production“ zum Vorbild genommen und versucht, diese Prinzipien auf die Software-Entwicklung zu übertragen. Die wichtigsten Ideen daraus:

• Es soll eine gleichmäßige Arbeitsbelastung geschaffen werden. Engpässe und Lastspitzen sind zu vermeiden, da sie den gesamten Prozess verlangsamen. Alles ist „im Fluss“.
• Produktionsfaktoren und Mitarbeiter müssen aus-, aber nicht überlastet sein. So lässt sich die Produktivität erhalten.
• Nur der Nachschub wird extern organisiert („push“), in ihrem Aufgabenbereich arbeiten die Teams jedoch eigenverantwortlich und weisen sich Aufgaben selbst zu („pull“).

Einsatzgebiet

Sobald ein Projekt ausgeliefert wurde, beginnt dessen Nachbetreuung, also die Support- und Maintenance-Phase. Diese ist gekennzeichnet durch viele kleine, kurz getaktete, oftmals unzusammenhängende Arbeitspakete von unterschiedlicher Priorität und Dauer. Aufgaben werden gern per Bugtracker-Ticket, Mail oder schlimmstenfalls mündlich zugewiesen.

Typischerweise befinden sich außerdem noch weitere Projekte in dieser Phase. Eine unübersichtliche Situation also, die sich kaum effektiv organisieren oder zumindest kontrollieren lässt. Und weder Scrum noch das alte Wasserfallmodell helfen hier weiter, da der Overhead beider Methoden einfach zu groß ist. Allein die Planungsdauer einer Sprintphase kann bereits den Umfang eines Arbeitspakets überschreiten. Hier nun liegen die Stärken von Kanban.

Funktionsweise

Das zentrale Element in Kanban ist das so genannte Kanban-Board, ein Whiteboard, auf das alle Mitarbeiter Zugriff haben. Das Board ist in verschiedene, frei definierbare Spalten aufgeteilt, die den Workflow des Entwicklerteams visualisieren. In diesen Spalten landen anschließend Arbeitspakete, die auf Karten notiert und priorisiert werden. Das Entwicklungsteam bedient sich anschließend selbst („Pull“ statt „Push“) und arbeitet so Paket für Paket ab. Ist eine Aufgabe erledigt, wandert das Paket eine Spalte weiter.

Was ein Paket ist, bestimmt das Team. Ebenso die Hürden, um von einer Spalte in die nächste zu kommen: Wichtig sind einheitliche Kriterien. So kann ein Paket alles sein, was länger als zwei Stunden und weniger als zwei Tage zur Umsetzung benötigt. Und als erledigt gilt ein Paket womöglich dann, wenn es tatsächlich ins Produktivsystem gespielt wurde. Auf diese Art lässt sich auch ein großes Arbeitspaket von mehreren Tagen Aufwand ganzheitlich nachverfolgen – von der Analyse bis zum Rollout.

Trotz geringer Reglementierung – ein Grundsatz Kanbans muss immer gelten: Jede Spalte hat ein eigenes „Work in Progress“-Limit (WiP-Limit), das nicht überschritten werden darf. Das WiP-Limit legt fest, wie viele Arbeitspakete sich gleichzeitig in einem Prozessschritt befinden dürfen. Es bestimmt sich somit aus der Entwicklungskapazität des Teams und verhindert damit dessen Überlastung. Auch Engpässe im Prozess fallen sofort auf. Ein Arbeitspaket, das partout nicht abgenommen wird, sorgt demnach für Stau in den vorhergehenden Schritten – in der Lehre des Kanban, die alles „im Fluss“ halten und gleichmäßig bewegen will, stellt das ein Problem dar, dem man sich umgehend annehmen muss.

Messtechnik

Kanban bietet vielfältige Metriken, um die Leistung eines Teams zu messen oder Flaschenhälse im Prozess aufzuspüren. So lässt sich etwa feststellen, wie lange ein Arbeitspaket braucht, um den gesamten Workflow zu durchlaufen („Cycle Time“). Diese Zahl stellt im Durchschnitt und auf alle Pakete gerechnet nichts anderes als die Entwicklungsgeschwindigkeit des Teams dar.

Ein „Cumulative Flow“-Diagramm hingegen deckt auf, in welchem Prozessschritt Engpässe auftreten und sich Arbeitspakete stauen. Dazu wird die Summe aller Pakete pro Prozessschritt in Abhängigkeit der Zeit gemessen. So kann man gezielt gegensteuern, indem man etwa das Abnahme/Testing-Team aufstockt, falls es bei der Abnahme immer wieder zu Verzögerungen kommt.

Das Verwalten mehrerer Projekte ist ebenfalls problemlos zu bewerkstelligen, ohne für jedes Projekt ein neues Whiteboard aufstellen zu müssen. Dazu gibt es zwei unterschiedliche Ansätze: Ergänzt man das Board um weitere Zeilen („Swimlanes“), lassen sich diese jeweils einem bestimmten Projekt zuordnen. Alternativ sind Kanban-Karten in verschiedenen Farben gebräuchlich.

Auch online lässt sich das Kanban-Modell visualisieren. Entsprechende Werkzeuge wie Greenhopper [2] oder das Kanban-Tool [3] sind aufgrund des zeit- und ortsunabhängigen Zugangs besonders bei verteilten Teams an unterschiedlichen Standorten sinnvoll.

Fazit

Nach einem Jahr Kanban-Nutzung in der Wartungsphase fällt das Urteil des Autors durchwegs positiv aus: Denn so simpel das Prinzip auch ist, in der Praxis zeigen sich verblüffende Effekte, sobald sich das Team darauf eingestellt hat. Durch die zentrale Bündelung aller Aufgaben am Kanban-Board gerät nichts in Vergessenheit.

Arbeitspakete werden nicht mehr per Mail oder gar auf Zuruf verteilt, sondern strukturiert erfasst und im Kontext der anderen Projekte betrachtet, was die Koordination der verschiedenen Aufgaben erheblich verbessert. Entwickler können sich endlich wieder auf die Entwicklung konzentrieren, anstatt ihre anstehenden Aufgaben verwalten zu müssen. Die WiP-Limits vermeiden indes eine Überlastung und störende Kontextwechsel zwischen verschiedenen Aufgaben. All das hat für erheblich mehr Ruhe und Konzentration im sonst hektischen Entwickleralltag gesorgt.

Aber auch das Projektmanagement profitiert von Kanban: Ein einziger Blick auf das Board sorgt für Transparenz und bringt einen schnellen Überblick. Wie hoch ist die Auslastung? Wer arbeitet gerade an welcher Aufgabe? Was steht als nächstes an? Aufwändige Status-Meetings und Nachfragen reduzieren sich von selbst auf ein kurzes, tägliches Stand-Up-Meeting vor dem Board. Die Arbeitsplanung und umständliche Lokalisierung freier Entwicklerkapazitäten wird vereinfacht, da letztlich nur noch Karten ans Board gepinnt werden müssen

Unterm Strich sorgt Kanban damit für eine höhere Mitarbeiterzufriedenheit und Produktivität, obschon das System (fast) ohne Regeln auskommt. Henrik Kniberg, Kanban-Evangelist, bemerkt dazu lapidar: „Just inches from „Do whatever“, but still surprisingly powerful“ [4]. Recht hat er.

Der Autor

Daniel Haller studierte in Darmstadt Media System Design, wo er 2009 diplomierte. Seitdem arbeitet er als Technischer Manager und Entwickler bei der Frankfurter Agentur BlueMars.

Ob Furzkissen-App oder die fünfundzwanzigste Taschenlampen-App, die Sinnhaftigkeit solcher Applikationen stellen nicht nur Entwickler, sondern mehr und mehr vor allem die Nutzer in Frage. Für jene, die ernsthafte Apps entwickeln, gilt: innovativ und neu, nutz- und gewinnbringend müssen sie sein. Bei über 300.000 Applikationen im iPhone App-Store machen Mehrwert, Nutzen genauso wie Usability den Erfolg künftiger Apps aus.

Dasselbe Spiel, eine andere Liga

Unabhängig von Idee und Plattform sind die Bedienbarkeit und damit die Akzeptanz der Nutzer entscheidend für den Erfolg einer App. Hierfür muss man sich von klassischen Webkonzepten lösen. Mobile Endgeräte stehen im Vergleich zu Desktop-Computern in einem völlig anderen Nutzungskontext. Wechselnde Lichtverhältnisse, akustische Beeinträchtigungen, Ablenkungen durch ein hektisches Umfeld sowie eine eventuell suboptimale Netzabdeckung sind da nur einige Faktoren, die man bei der Entwicklung mobiler Applikationen berücksichtigen muss. Aufgrund ihrer geringen Bildschirmgröße bieten Smartphones außerdem nur wenig Platz für Content und Bedienelemente. Diese veränderten Rahmenbedingungen diktieren die Anforderungen an das Konzept und die damit verbundene Usability einer mobilen Anwendung.

Groovende Apps

Setzt das Konzept auf bereits erlernte Interaktionsprinzipien und -elemente, mit denen der Nutzer durch sein jeweiliges Betriebssystem schon vertraut ist, findet er sich besser zurecht. Dadurch erleichtert man ihm den Einstieg schon ab der ersten Nutzung erheblich. Einen realen Mehrwert schafft das Einbeziehen von Funktionalitäten der Endgeräte. In der App-Gestaltung sollte man daher die gestenbasierte Steuerung auf Multi-Touch-Displays berücksichtigen.

Dazu zählen unter anderem doppeltes Antippen („Double-Tap“) oder Zoomen mit zwei Fingern („Pinching“). Die lagesensitive Steuerung ermöglicht dem Nutzer, sein Gerät vertikal oder horizontal zu halten, Inhalte passen sich entsprechend an. Ebenso birgt der Neigungssensor weitere ungeahnte Möglichkeiten. Die automatische Standortermittlung findet ihren Einsatz beim Auffinden von Personen, Orten oder Ereignissen in der Nähe.

Jedes Pixel zählt

Den geringen Platz richtig nutzen – eine Vorgabe, die durch die kleineren Bildschirmgrößen von mobilen Endgeräten eine Grundvoraussetzung für erfolgreiche Applikationen ist. Das heißt konkret, sich auf die essenziellen Funktionen zu konzentrieren und Inhalte zu reduzieren. Dabei kann der Einsatz eines Layouts mit nur einer Spalte helfen, das die gesamte Bildschirmbreite ausnutzt.

Obwohl Icons „small-screen-freundlich“ sind, da sie weniger Platz als Beschriftungen verbrauchen, ist es von entscheidender Bedeutung, dass die Nutzer diese auch verstehen. Um das Verständnis von Symbolen sicherzustellen, können kleine Textbeschreibungen unter dem Symbol stehen, speziell innerhalb einer Navigation. Dieser Kompromiss unterstützt unerfahrenere Nutzer, die mit dem Symbol weniger vertraut sind. Experten, die das Icon bereits kennen, werden dadurch jedoch nicht behindert. Ziel ist es, dass der Nutzer die App herunterlädt, öffnet und nutzt – ohne Erklärungen und ohne ein Herantasten. Applikationen für mobile Endgeräte müssen als „walk-up-and-use-system“ an den Markt gehen.

Finger sind keine Mauszeiger

Konzepter müssen allerdings nicht nur eine Sichtbarkeit der Buttons und Links auf dem Touchscreen gewährleisten, sondern auch die Bedienung mit dem Finger optimal ermöglichen. Daher muss man bei der Konzeption die Bedienelemente in einer entsprechenden Größe und mit ausreichend Raum platzieren. Nur so minimiert man die Wahrscheinlichkeit einer falschen Berührung.

Everything as simple as possible

Auch die beste Tastatur eines Smartphones kann einer Computertastatur mit entsprechender Größe nicht das Wasser reichen. Anwender machen auf dem mobilen Endgerät weit mehr Fehler und sind langsamer beim Tippen. Daher sollte man Texteingaben innerhalb einer Applikation so häufig wie möglich vermeiden. Lösungen hierfür sind zum Beispiel, den Nutzern den Zugriff auf bereits gespeicherte Daten zu erlauben oder eine PIN statt eines Passworts zu verwenden. Eine innovative Form für den Input von Informationen besteht in der Verwendung von QR-Codes – sie sind nützlich und machen Spaß.

Gib mir Feedback

Direktes Feedback ist wichtiger als je zuvor. Nach einer Interaktion zwischen Nutzer und Applikation muss der Nutzer Feedback darüber bekommen, was gerade passiert beziehungsweise was bereits geschehen ist. Das fängt bei Ladevorgängen an und hört beim Tap auf eine Interaktionsfläche auf. Je nach mobilem Nutzungskontext ist die Internetanbindung nicht mit gleicher Qualität gewährleistet. Ein Ladekreisel unterstützt den User dabei zu verstehen, dass die Anwendung gerade im Hintergrund arbeitet. Die farbliche Veränderung bei Berührung einer Schaltfläche verdeutlicht, dass diese tatsächlich aktiviert wurde. Speziell bei Touchscreen-Geräten ist dieses Feedback von Bedeutung. Zusätzlich zur visuellen Rückmeldung eignen sich auch die gerätespezifischen Funktionalitäten, wie die Vibration. Diese Features sprechen gleich mehrere Sinne des Users an.

Nützliche Werkzeuge für erfolgreiche Konzepte

Die Anforderungen der Zielgruppen sind das A und O für den Erfolg einer Anwendung. Diverse Werkzeuge helfen dabei, sich den Anforderungen der Nutzer anzunähern und diese gleichzeitig dem Kunden zu vermitteln. Der Einsatz von Rollenmodellen (Personas) und Nutzungsszenarien (Use Cases) unterstützen dabei, sich in den Nutzer hineinzuversetzen und ihn greifbar zu machen. Für die Auswahl der konzeptionellen Tools gibt es kein Nonplusultra. Individuelles Eingehen auf Projekt und Auftraggeber ist unabdingbar. Die Auswahl ist abhängig von Abstraktionsfähigkeit und technischem sowie gestalterischem Background des Kunden. Ebenso ist der zeitliche Rahmen des Projekts ein Auswahlkriterium für die Art des zu liefernden konzeptionellen Ergebnisses.

Beim Bau einer CSS-Datei kommt es nicht selten vor, dass man für verschiedene Elemente ähnliche oder gar redundante Anweisungen vornimmt. Bestes Beispiel hierfür sind Farbangaben. Aber auch Angaben für Formatierungen, Abstände oder Größen weisen häufig Abhängigkeiten innerhalb einer oder mehrerer CSS-Dateien auf. Ein Programmierer würde hier wiederkehrende Elemente zentral definieren, Vorlagen verwenden und den eigentlichen CSS-Quellcode anschließend generieren lassen. Genau das ist der Ansatz von Syntactically Awesome Stylsheets (SASS) [1]. CSS-Stylesheets werden um Möglichkeiten erweitert, die Zusammenhänge zwischen verschiedenen Angaben in Form einer eigenen „Sprache“ notieren.

Eines der Ziele bei der Entwicklung der nächsten TYPO3-Generation 5.x (Codename „Phoenix“) war es, wo möglich auf Grafiken zu verzichten und gestalterische Elemente durch die reine Verwendung von HTML und CSS abzubilden. Dies erleichtert dann auch die einfache und zentrale Anpassbarkeit. Entsprechend verwundert es wenig, dass sich die Entwickler entschieden, die CSS-Angaben mit Hilfe von SASS aus zentralen Layout-Definitionen zu generieren.

Bei SASS existieren zwei verschiedene Syntax-Varianten. Die klassische Syntax (Dateiendung .sass) verzichtet auf Klammern und setzt stattdessen auf Einrückungen zur Gliederung von Elementen. Die ab SASS3 unterstützte „SCSS“-Syntax („Sassy CSS“, dt.: freches CSS, Dateiendung .scss) hingegen setzt auf CSS3, verwendet also Klammern und erweitert CSS um zusätzliche Möglichkeiten. Innerhalb eines Projekts ist es auch möglich, SASS- und SCSS-Syntax zu mischen. Je Datei findet aber jeweils nur eine Syntax Anwendung. Im Folgenden liegt der Fokus auf der SCSS-Syntax.

Erste Schritte

Das Werkzeug zur Umwandlung von SCSS/SASS-Code in CSS-Code selbst ist in Ruby geschrieben. Aber keine Angst: Wer das Tool nicht im Kern erweitern, sondern einfach nur nutzen möchte, benötigt keine Ruby-Kenntnisse. Nach Installation des Ruby-Gems „haml“ per „gem install haml“ ist das SASS-Tool auch schon für den ersten Einsatz bereit. Wer ein HAML-Paket seiner Linux-Distribution nutzen möchte, sollte beachten, dass dies die SCSS-Syntax erst ab Version 3.0 unterstützt.

Mit „sass style.scss:style.css“ ist die Konvertierung einer einzelnen Datei möglich. Alternativ können hier auch Quell- und Zielverzeichnis angegeben werden, die dann rekursiv abgearbeitet werden. Mit „sass --watch style.scss:style.css“ ist es außerdem möglich, einen Live-Modus zu aktivieren, bei dem die Quelldateien auf Änderungen beobachtet und die Zieldateien automatisch neu generiert werden.

Wie die Ausgabe aussieht, bestimmt das „--style“-Attribut. Standardmäßig aktiv ist „nested“; Einrückungen also, die die CSS-Hierarchie leserlich darstellen. Alternativ lassen sich die Angaben über „compressed“ auf das Nötigste reduzieren oder mittels „compact“ auf eine Zeile komprimieren.

Variablen

Jede gültige CSS3-Datei ist automatisch auch eine gültige SCSS-Datei. Ein zu Beginn häufig verwendetes Beispiel ist die zentrale Definition von Farben und Größenangaben mit Hilfe von Variablen. Diese werden in der Form „$variablenname“ angegeben, gefolgt von einem Doppelpunkt sowie dem gewünschten Wert, der selbst eine gültige CSS-Angabe ist. Auch ist es möglich, einfache mathematische Konstrukte wie Additionen oder Multiplikationen zu nutzen. Für diverse andere Anwendungen stehen sogar Funktionen bereit, etwa zur Berechnung von Farbwerten.

$dark-white: #f1f1f1;
$grey: lighten(#000000, 20%);
$light-grey: #9e9e9e;
$small-radius: 3px;
$mid-radius: 5px;

a.link-help {
	color: $light-grey;
}

div.button {
	width: 20px - 2*$small-radius;
}

Wiederkehrende Angaben lassen sich auch per „mixin“ auslagern und dann über „include“ an verschiedenen Stellen nutzen. Dabei ist die Angabe von optionalen Parametern möglich – ganz im Stil programmierter Funktionen.

@mixin rounded-corners-middle-right {
	-moz-border-radius: 0 $mid-radius $mid-radius 0;
	-webkit-border-radius: $mid-radius;
}

@mixin spacing($margin: 5px) {
	margin-right: $margin;
}

.errorMessages {
	@include rounded-corners-middle;
	@include spacing(10px);
	border: 1px solid #000000;
}

Verschachteln

Besonders hilfsreich ist die Verwendung von verschachtelten Angaben. Sie erleichtern den Überblick, geben den Definitionen klare Strukturen und ermöglichen auf einfache Weise beispielsweise die Umbenennung einer class-Angabe.

table.menu {
	background-color: blue;
	td.active {
		font-weight: bold;
		label {
			margin-left:10px;
		}
	}
}

div.headline {
	font: {
		weight: bold;
		size: 1.2em;
	}
}

table.menu { background-color: blue; }
table.menu td.active { font-weight: bold; }
table.menu td.active label { margin-left: 10px; }
div.headline { font-weight: bold; font-size: 1.2em; }

Vererben

.important {
	font-weight:bold;
}
.headline {
	font-size:1.2em;
}
.importantErrorheadline {
	@extend .important;
	@extend .headline;
	color: red;
}

Durch die Vererbung von einem oder mehreren Selektoren ist es möglich, selbst komplizierte Abhängigkeiten einfach und strukturiert abzubilden. Auch ist die Vererbung entlang einer Kette von Selektoren ist möglich.

.important, .importantErrorheadline { font-weight: bold; }
.headline, .importantErrorheadline { font-size: 1.2em; }
.importantErrorheadline { color: red; }

Auslagern und Einbinden

Wiederkehrende Werte und Definitionen werden bestenfalls bereits zu Beginn ausgelagert. Dies ermöglicht es, die im weiteren Verlauf eines Projekts üblicherweise stetig steigende Komplexität der CSS-Angaben auf ein überschaubares Maß zu reduzieren. Auch lassen sich so Module in verschiedenen CSS-Dateien zentral und einfach wiederverwenden. Dank mathematischer Ausdrücke und Funktionen lassen sich so Ursprungswerte wie die zu verwendende Bildschirmbreite zentral ändern und abhängige Werte automatisch neu berechnen.

@include „Dateiname“;

Beginnt der Dateiname mit einem Unterstrich, signalisiert dies SASS übrigens, dass die Datei nicht in eine eigenständige CSS-Datei zu konvertieren ist. Sie wird stattdessen lediglich als Modul innerhalb anderer Dateien genutzt.

Fazit

Die Möglichkeit beispielsweise Längen, Abstände und Farben zentral zu definieren erhöht die Übersichtlichkeit bereits enorm [2]. Verbunden mit mathematischen Operationen, Funktionen und wiederverwendbaren Blöcken wird es auf flexible Weise möglich, mit CSS-Angaben zu „programmieren“. Der Funktionsumfang lässt sich zudem durch andere Bibliotheken, etwa Compass [3], erweitern – sie bringen fertige Mixins, Vorlagen und eine wachsende Community. Durch die Generierung von standard-konformem CSS3 lässt sich SASS/SCSS außerdem ohne Anpassung mit allen Browsern nutzen.

Der Autor

Stefan Neufeind arbeitet als Experte für Webentwicklung und -administration bei der SpeedPartner GmbH in Neuss. Er ist Mitglied im TYPO3 Certification Team und engagiert sich in verschiedenen Open-Source-Projekten von PHP/PEAR bis hin zu OpenStreetMap. Außerdem ist er als Speaker auf Konferenzen zu Themen wie IPv6 und DNSSEC anzutreffen und als Autor für IT-Fachmagazine aktiv.

Bequem vom eigenen Sofa aus zu bestellen, scheint Volkssport geworden zu sein. Doch ob Besucher eines Onlineshops verweilen und schließlich einkaufen oder direkt wieder in den Weiten des Webs verschwinden, hängt von vielen Faktoren ab: Finden sie auf Anhieb, was sie gesucht haben? Erscheint der Shop vertrauenswürdig? Passen Preise für Produkte und Versand?

Hinzu kommt die Reaktionszeit der Seite, die einen großen Anteil am „Wohlfühlfaktor“ des Besuchers hat. Wenn der Nutzer den Eindruck hat, dass die Seite nur behäbig auf die Eingaben reagiert, macht das Surfen durch die Produkte des Shops nur wenig Spaß und der Einkauf wird bei Mitbewerbern fortgesetzt. Google wird deshalb in Zukunft die Ladegeschwindigkeit einer Seite stärker in seine Beurteilung innerhalb der Suche einbeziehen – ein weiterer Grund, ein Auge auf die Performance zu werfen.

Flexibilität als Fluch und Segen

Flexibilität galt bei Magento von Beginn an als Maxime. Über Module und Templates lässt sich das System sowohl funktional als auch optisch an fast alle Anforderungen und Ansprüche der Shopbetreiber anpassen. Nicht zuletzt dieser Flexibilität ist die hohe Beliebtheit Magentos zu verdanken.

Gleichzeitig erweist sich diese Flexibilität aber als größter Feind der Performance. Statt Prozesse, Daten und Layouts strikt festzulegen, bleibt dem Betreiber immer die Möglichkeit, Dinge anzupassen und zu erweitern. Dass das System hierdurch komplexere Routinen durchlaufen muss, ist die logische Konsequenz.

Bestes Beispiel hierfür ist das Entity-Attribute-Value-Pattern (EAV), das Magentos Datenmodelle hochgradig flexibel macht. Über das Backend können Betreiber Produkte frei mit beliebigen Attributen verschiedener Typen ausstatten. Die Besucher können dann Produkte anhand dieser Attribute vergleichen, filtern oder suchen.

Andererseits ist EAV sehr performancelastig. Im Gegensatz zu herkömmlichen Datenbankmodellen, bei denen die Eigenschaften eines Objekts in einzelnen Spalten einer flachen Tabelle gespeichert werden, teilt EAV die Daten in mehrere Tabellen auf: Entitätstypen wie Produkte, Kategorien oder Kunden werden zentral in der Tabelle eav_entity_type definiert. Attribute zu Produkten werden in eav_attribute spezifiziert und den jeweiligen Entitätstypen zugeordnet. Optionen für Auswahl-Attribute werden in eav_attribute_option, deren Labels in eav_attribute_option_value gespeichert. Die eigentlichen Daten der Produkte, Kategorien und sonstigen EAV-Objekte liegen aber in den Wertetabellen. Hierbei handelt es sich um eine Kopftabelle (beispielsweise catalog_product_entity) und bis zu neun datentypspezifische Tabellen für Integer, Texte, Datumswerte und andere.

Um nun ein Produkt vollständig aus der Datenbank zu lesen, muss zunächst bestimmt werden, welche Attribute diesem Produkt zugeordnet sind, um anschließend die jeweiligen Werte auslesen zu können. Hierfür sind mehrere Datenbankzugriffe über mehrere Tabellen notwendig, was mehr Zeit und Ressourcen in Anspruch nimmt als der Zugriff auf eine einzelne Tabelle.

Ein weiteres Beispiel sind die Module: Über XML-Konfigurationen lässt sich das Verhalten anderer Module anpassen, indem beispielsweise Klassen dynamisch ausgetauscht werden. Hierdurch wird der Instanzierungsprozess von Klassen jedoch deutlich gebremst. Noch verstärkt wird dieser Effekt durch die vier Codepools „lib“, „core“, „community“ und „local“, durch die die Ordnung und Update-Fähigkeit des Systems gewahrt bleiben soll. Wird eine bestimmte Klasse gesucht, probiert das System die vier Ordner rückwärts durch. Dadurch wird das Laden der Klassen in Magento paradoxerweise schneller, je mehr Klassen in „local“ oder „community“ überschrieben werden.

Caching, Caching, Caching

Um Flexibilität und Performance unter einen Hut zu bringen, beinhaltet Magento diverse Caching-Mechanismen. Hierbei wird ausgenutzt, dass die meisten Konfigurationseinstellungen zu Beginn eines Projekts stark variieren, zur eigentlichen Produktivphase jedoch überwiegend gleich bleiben.

Eine Übersicht über die Zustände der Caches findet man im Backend bei System, Cache Management. Während es für die Entwicklungsumgebung durchaus sinnvoll sein kann, die Caches zu deaktivieren, ist dies in der Produktivumgebung keine Option. Innerhalb des Caching-Moduls finden sich folgende Optionen:

• Konfiguration: Beinhaltet die Grundkonfiguration des Systems sowie die Konfiguration aller aktiven Module.
• Layouts: Definition der Ausgabeblöcke sowie deren Positionen.
• Block HTML-Ausgabe: Speichert die HTML-Ausgaben von Blöcken, wenn diese für Caching konfiguriert wurden.
• Übersetzungen: Dieser Cache speichert die verschiedenen Übersetzungen zentral ab.
• Kollektionsdaten: Bestimmte Listen werden in Magento immer wieder aufgerufen. Werden diese zwischengespeichert, kann wertvolle Zeit gespart werden.
• EAV-Typen und -Attribute: Konfiguration der verschiedenen EAV-Elemente, sodass diese nicht permanent aus der Datenbank gelesen werden müssen.
• Konfiguration der Webdienste: Vorrangig für die SOAP-API interessant; speichert öffentliche Methoden und Zugriffsrechte.

Obschon überall zu Caching geraten wird, finden sich in der Praxis noch zu viele Magento-Shops mit (partiell) deaktiviertem Cache. Das ist zum Teil einer fehlenden Unterstützung durch Templates oder Erweiterungen von Drittanbietern geschuldet: Haben die Entwickler Caching bei der Programmierung nicht vorgesehen, beeinträchtigt dies unter Umständen die komplette Installation.

Cache-Keys

Ob Magento einen Block live generieren muss oder eine valide Version aus dem Cache beziehen kann, wird anhand so genannter Cache-Keys entschieden. Diese geben den aktuellen Zustand der Ausgabe wieder und werden vor der Ausgabe eines Blocks generiert.

Wird der aktuelle Zustand in einem gültigen Eintrag im Speicher gefunden, kann der dort hinterlegte Inhalt direkt ausgegeben werden, ohne weitere Programmlogik ausführen zu müssen. Wird der Block nicht im Speicher gefunden, erzeugt Magento die Blockausgabe und legt diese für die definierte Cache-Lebenszeit statisch ab. Ohne Cache-Informationen im Block kann das System die Blockausgaben nicht zwischenspeichern und erzeugt die Ausgaben bei jedem Zugriff dynamisch.

Die Definition der Cache-Angaben erfolgt in der Regel im Magento-eigenen Platzhalterkonstruktor des Blocks (Template Method Pattern).

class T3n_Example_Block_Example extends Mage_Core_Block_Template
{
	protected function _construct()
	{
		$this->addData(array(
			'cache_lifetime'	=> 86400,
			'cache_tags'	=> array(Mage_Catalog_Model_Product::CACHE_TAG)
		));
	}

	public function getCacheKeyInfo() {
		return array(
			'T3N_EXAMPLE',
			(int)Mage::app()->getStore()->isCurrentlySecure(),
			Mage::getDesign()->getPackageName(),
			Mage::getDesign()->getTheme('template')
		);
	}

}

Der angegebene Wert in der Cache-Lifetime definiert den Zeitraum in Sekunden, für den der Cache gültig sein soll. Der Wert sollte mit Bedacht gewählt werden. Fällt er zu niedrig aus, wird der Block zu häufig dynamisch generiert. Ist er zu hoch, kommt es zu keiner Aktualisierung und die Informationen bleiben länger im Speicher als gewünscht. Im Beispiel wird eine Cache-Lebenszeit von einem Tag (in Sekunden; 60 x 60 x 24 = 86400) definiert.

Die Cache-Tags unterteilen die Informationen im Cache in verschiedene Kategorien. Diese Kategorien werden etwa verwendet, um bestimmte Bestandteile gezielt zu aktivieren, zu deaktivieren oder zu verwerfen. Genau das passiert auch beim Löschen eines Caches über das Magento-Backend.

Dritter Bestandteil des Listings ist die Definition des Keys in der Methode getCacheKeyInfo. Der Cache-Key ist der eindeutige Bezeichner für eine im Cache hinterlegte Information. Die Werte des Cache-Keys sollten alle verschiedenen Zustände eines Blocks wiedergeben, die einzeln gespeichert werden. Erlaubt ein Block verschiedene Zustände, so darf es genauso viele unterschiedliche Cache-Keys für den aktuellen Block geben. Um Cache-Kollisionen mit anderen Blöcken zu vermeiden, wird als erster Teil meist der Identifikator des aktuellen Blocks verwendet. Weitere Komponenten sind häufig das Package und Theme sowie die Sprache.

Cache-Backends

Wie die Caching-Daten gespeichert werden, entscheidet die Wahl der Cache-Backends, welche in der Konfigurationsdatei app/etc/local.xml eingestellt werden.

<config>
	<cache>
		<backend>memcached</backend>
		<slow_backend>database</slow_backend>
		<fast_backend>memcached</fast_backend>
		<memcached>
			<servers>
				<server>
					<host>192.168.0.1</host>
					<port>11211</port>
					<persistent>0</persistent>
				</server>
			</servers>
		</memcached>
	</cache>
	[...]
</config>

In <backend> wird das Cache-Backend eingetragen, welches mit der Zwischenspeicherung beauftragt werden soll. Mögliche Werte sind memcached, apc, xcache, eaccelerator, sqlite, database und file. Wird kein Wert übergeben, nutzt Magento standardmäßig den dateibasierten Cache.

Die vier erstgenannten Cache-Backends sind arbeits­speicher­basiert und dementsprechend schnell; allerdings sind sie nicht persistent und unterstützen keine Cache-Tags. Sie werden deshalb im Rahmen des Two-Level-Cache-Backends mit einem langsameren, aber persistenten Speicher kombiniert. Dies geschieht über die Konfigurations-Tags <slow_backend> und <fast_backend>. Darüber hinaus werden dem memcached-Backend im Beispiel noch notwendige Serverinformationen übergeben.

Zur Verbesserung der Two-Level-Cache-Performance existiert ein Cache-Modul [1], welches verhindert, dass Magento bei jedem Lesezugriff den schnellen Cache neu schreibt. Über das Modul kann zusätzlich das Cache-Backend Libmemcached aktiviert werden, welches in den Benchmarks deutlich besser abschneidet als Memcached [2].

Empfohlen wird für einzelne Webserver übrigens APC mit File-Cache. Werden mehrere Webserver verwendet, sollte das Libmemcached- mit dem Datenbank-Backend kombiniert werden.