Helfer im Alltag

Variablen/Berechnungen

Ein interessanter Vorteil ist die Möglichkeit, Variablen zu definieren und damit sogar zu rechnen. Ein direkter Nutzen zeigt sich bei einem Beispiel, dass man so oder ähnlich öfters in CSS-Dateien finden kann:

1
2
3
4

.box h3 {
  margin: -18px -15px 0;
  …
}

Hmm. Woher kommen die Werte -18 und -15? Und warum wurden genau diese Werte gewählt? Schaut man sich das gesamte Beispiel an, wird es mit SASS auf den ersten Blick verständlicher:

1
2
3
4
5
6
7
8
9
10
11
12
13

$box-hpad: 15px;
$box-vpad: 18px;

.box {
  padding: $box-vpad $box-hpad;
  border: 1px solid #ccc;
}

.box h3 {
  padding: $box-vpad $box-hpad;
  margin: (-$box-vpad) (-$box-hpad) 0;
  background-color: #ccc;
}

Ändern sich hier im Layout die Abstände, muss dies nur noch an einer Stelle geschehen. Zugleich ist dokumentiert, was die einzelnen Pixelwerte bedeuten und man verhindert, einen Wert bei einer Änderung zu vergessen. Das hilft besonders, wenn mehrere Entwickler am Frontend arbeiten.

Don‘t repeat yourself

Viele Standard-Codesnippets, die man in fast jedem Projekt benötigt, sind in Compass bereits enthalten, das Zusammensuchen von Code entfällt also: Clearfix-Methode, diverse CSS-Reset-Einstellungen (basierend auf Eric Meyer‘s Reset 2.0), CSS3-Buttons, etc.

Wer genauer wissen will, was es mit den einzelnen Snippets auf sich hat, kann sich auf der Compass-Website jeden Sourcecode einzeln ansehen. Und das Beste: Sollte es für diese Mixins im Laufe der Zeit Updates geben (z.B. der Wegfall von Vendor-Prefixen), braucht man lediglich einmal Compass selbst zu aktualisieren und seine Stylesheets neu zu erzeugen.

Darüber hinaus gibt es auch weitere Mixins, z.B. zum automatischen Erstellen von CSS-Sprites, die einem die Arbeit erleichtern. Ebenso kann man eigene Module als Compass-Erweiterungen zusammenstellen.

Deployment

Einige nützliche Funktionen drehen sich um die Ausgabe der CSS-Dateien, die sich auch dann anbieten, selbst wenn man sonst kein einziges Feature von SASS nutzen würde:

Strukturelle Validierung

Beim Parsen der SASS-Datei wird der Code strukturell validiert. Sollten also eine Klammer oder ein Semikolon fehlen, wird eine Fehlermeldung im Browser angezeigt. Auf die verwendeten Eigenschaften hat es keine Auswirkungen, Vendor-Prefixes oder Browser-Hacks sind also weiterhin möglich.

Codestrukturierung und Wiederverwendbarkeit

Endlich ist @import nicht mehr „böse“. Bisher verhinderte diese Regel das parallele Herunterladen von CSS-Dateien und konnte so zu einer Verlangsamung des Seitenaufbaus führen. In SASS werden die importierten Dateien direkt in die Gesamtausgabe eingebettet. Man kann also seine Styles hervorragend modular aufbauen und für Wiederverwendbarkeit kapseln.

Kommentare

Kommentare, die mit // … statt dem üblichen /* … */ eingesetzt werden, erscheinen nicht im ausgegebenen CSS. Man kann diese Möglichkeit also hervorragend nutzen, seinen Code zu kommentieren, ohne dass diese Anmerkungen nachher auf dem Produktivsystem zu sehen sind. Das ist besonders auch für Arbeiten im Team nützlich.

Minifizierung des Codes

Last but not least, kann mit einer Option die Ausgabe des Codes direkt minimiert erfolgen, also ideal für Produktivumgebungen.

Sicher kann man diese Möglichkeiten auch ohne den Einsatz eines Präprozessors nutzen, allerdings erfordert dies für gewöhnlich entweder einen eigenen Build-Prozess oder man ist auf die manuelle Nutzung von Online-Tools angewiesen. Als “Dreingabe” also auf jeden Fall schon interessant.

Fazit

Man sollte sich – wie bei allen neuen Techniken – anschauen, was SASS und Compass zu bieten hat und danach gezielt entscheiden, was für den eigenen Arbeitsworkflow sinnvoll ist.

Mit SASS kann man genauso übersichtliche oder unübersichtliche Stylesheets produzieren, wie man es auch mit CSS alleine machen kann, man muss also trotzdem die Regeln kennen. Dann können aber gerade die kleinen Handreichungen eine echte Erleichterung im alltäglichen Arbeiten sein.

cd /Applications/iCal.app/Contents/Resources
sudo mv alarmclock.gif alarmclock.gif.original
touch alarmclock.gif
cd /System/Library/Frameworks/CalendarStore.framework/Versions/A/Resources/iCal\ Helper.app/Contents/Resources/
sudo mv alarmclock.gif alarmclock.gif.original
touch alarmclock.gif

Das Ganze funktioniert mit iCal ab Version 4 (Snow Leopard), bei älteren Versionen können die Pfade abweichen.

Die Woche startete großartig: In Düsseldorf fand die beyond tellerrand-Konferenz in gemütlicher Atmosphäre des Capitol-Theaters statt, das der Veranstaltung direkt ein wenig Varieté-Atmosphäre verlieh. Und genau so, wie es der Rahmen versprach, waren die Themen der Vorträge auch interessant und abwechslungsreich gewählt.

“More Honesty, Less Ninjas”

Den Auftakt machte Chris Heilmann, der in gewohnt gut gelaunter Manier einen Rundumschlag interessanter Technologien zeigte, die in aktuelle Browser gerade Einzug halten. Gerade BrowserID als Ersatz für heutige Login-Mechanismen erscheint äußerst vielversprechend: Damit dürfte das lästige Account-Anlegen oder Anmelden über Drittanbieter wie Twitter oder Facebook bald nicht mehr erforderlich sein, um sich eindeutig als Nutzer zu authentifizieren.

Der darauf folgende Vortrag von Steph Troeth mit dem Thema User Experience Design (UX) war etwas theoretischerer Natur und ob der Menge an Informationen leider ein wenig unter Zeitdruck, aber Sie machte deutlich, dass UX ein wichtiges Feld ist, mit dem sich Entwickler und Designer gleichermaßen mehr beschäftigen sollten. Danach gab Aaron Gustafson einen Überblick über Progressive Enhancement mit diversen Tipps und Techniken, wie man bestehende Funktionalitäten sinnvoll (und barrierearm) mir JavaScript und CSS erweitern kann.

Naomi Atkinson sprach in ihrem Talk ein Thema an, dass gerade für deutsche Webworker interessant ist: Was können wir bei beruflicher Selbstdarstellung von den Stars lernen? Auch wenn sich das im ersten Moment seltsam anhören mag, scheinen es gerade deutsche (oder allgemein europäische) Webworker zu sein, die ihr Licht zu sehr unter den Scheffel stellen und die Bühne ihren amerikanischen oder britischen Kollegen überlassen. Man muss nicht bei Google, Mozilla oder einem fancy Sillicon Valley-Startup arbeiten, um interessante Dinge rund ums Web präsentieren zu können!

Danach ging es weiter mit der Frage, welche Möglichkeiten es gibt, mit Webapps auf Funktionen von mobilen Geräten wie Push Notifications, Kamera oder Sensoren zuzugreifen. Heiko Behrens präsentierte Vor- und Nachteile unterschiedlicher Methoden und Frameworks.

Der Vortrag von Smashing Magazine-Gründer Vitaly Friedman wurde von Vielen zwiespältig aufgenommen: Zwar waren einige Thesen um “The Invisible Side of Design” interessant, allerdings versuchte Vitaly, sie oftmals mit sehr visuell prägnanten Beispielen zu belegen, so dass die Argumentation teilweise eher verwirrend als erhellend war.

Wer bisher dachte, JavaScript in Webseiten wäre nur für Formularvalidierung gut, wurde nun anständig überrascht: Seb Lee-Delisle zeigte in seinem Talk einige Tricks, die Teil seines Creative JS-Workshops vom Sonntag waren. In einer spontanen Live-Coding-Session zeigte er mit einfachen Canvas-Tricks wie Partikelsysteme, Feuerwerk oder wachsenden Bäumen, wie viel Spaß man mit JavaScript haben kann. Selbst die Designer unter den Anwesenden schauten neugierig, wie Codezeilen im Editor entstanden und danach vom Browser Leben eingehaucht bekamen. Coole und sehr unterhaltsame Präsentation.

Im Anschluss an die Talks gab es eine längere Pause, die wir für eine Working Draft-Sondersendung in recht großer Runde nutzten. Vielen Dank nochmals an Naomi, die die Herrenrunde durch ihre Anwesenheit bereichert hat und mit uns über ihren Vortrags diskutierte.

Um 20:00 zeigte Yves Peters in seinem Abendvortrag die Rolle der Schrift “Trajan” in Filmplakaten. Mit dem Slogan “make it Oscar™ material” entscheiden sich viele Filmstudios für diese Schrift, um Filme vermeidlich “edler” zu gestalten. Ein Trend der schlussendlich von den Academy Awards selbst für die Oscar™-Veranstaltung übernommen wurde. Ebenso wurden “Gestaltungsregeln” und Trends für unterschiedliche Film-Genres deutlich, sobald man einige Filmplakate direkt miteinander vergleicht. Insgesamt ein sehr interessanter und unterhaltsamer Typographie-Vortrag, der den ersten Konferenztag offiziell beendete.

Tag zwei: Content is King

Nach der Party den ersten Vortrag am nächsten Tag zu haben ist sicherlich der undankbarste Zeit-Slot. Das Thema “Datenvisualisierung” klingt auf den ersten Blick auch nicht grade spannend, aber weit gefehlt. Des Traynor gab einen interessanten thematischen Überblick: Wie lügt man mit Grafiken? Welche Darstellungen eigenen sich für welche Daten? Wie muss ich Daten für bestimmte Zielgruppen aufbereiten, damit sie tatsächlich auch nützlich sind?

Wenn Design und Entwicklung abgeschlossen ist und “Lorem Ipsum” ausgedient hat, beschäftigen sich viele erst mit dem ungeliebten Thema Content. Steph Hay zeigte, wie wichtig jedoch gut geschriebene Inhalte sind und gab Tipps, wie man griffigen Content schreibt und überflüssiges Blabla vermeidet. Eine gute Ergänzung auch zu Naomis Vortrag vom Vortag.

Webentwicklung als Handwerkskunst

Simon Collison hat für seinen Vortrag ein wenig in der Familiengeschichte geforscht: Er entstammt einer Familie, die über viele Generationen Backsteine in England gefertigt hat. Aber was hat dieser Hintergrund mit der Tätigkeit als Webentwickler zu tun? Es geht um “Software Craftmanship” - es geht darum, dass der Beruf des Webworkers in vielen Belangen auch eine Handwerkskunst ist. Damit ist auch verbunden, Stolz auf seinen Beruf und die eigenen Leistungen zu sein, den Anspruch zu haben, stets sein Bestes zu geben. Ein sehr inspirierender und wichtiger Vortrag.

Den anschließenden Talk von Tomas Caspers habe ich leider völlig verpasst, habe nur im Nachhinein von schönen Tierbildern auf den Slides gehört.

Dan Rubin zeigte in seinem Vortrag, wie man Usability Testing auch in engem Zeitrahmen und mit einfachsten Mitteln durchführen kann: Auch Seiten, die für Webworker absolut gruselig daherkommen, können für den normalen Nutzer durchaus funktionieren. Viele Leute werden ein optische Veränderung nicht bemerken, aber eine Verbesserung in der Funktionalität um so mehr. Daher muss es nicht unbedingt ein kompletter grafischer Relaunch sein, um die Benutzbarkeit für den Anwender zu verbessern.

Falls es mit dem Programmieren irgendwann nicht mehr so läuft, sollte Jake Archibald dringend über eine Karriere als Standup-Comedian nachdenken:

Neben praxisnahen Beispielen, wie man in JavaScript wiederverwertbaren Code schreibt und APIs für eigene Plug-ins übersichtlich entwirft, berichtete er auch von einem aufwühlenden Ereignis seiner Jugend, wie er (durch einen Dokumentationsfehler in der Fernsehzeitung) unerwarteterweise “Berühmte Phalli der Geschichte” mit seiner Mutter schauen musste. Wenn das kein Anstoß ist, stets auf gründliche Dokumentation wert zu legen!

Den Abschluss des zweiten Tages bildete wieder ein Typographie-Vortrag. Jon Tan spannte den Bogen von Grundlagen der Web-Typographie wie allgemeine Lesbarkeit bis hin zu den Möglichkeiten, die sich mit Schrifteinbettung über @font-face ergeben. Auch hier waren wieder viele praktische Tipps dabei, wie man mit einfachen typografischen Mitteln Websites deutlich aufwerten kann.

Fazit

Die zwei Tage waren eine gute thematische Mischung, so dass für jeden etwas dabei war. Viel wichtiger noch: Die Vorträge boten alle eine Menge Inspiration. Schon während man noch zuhörte und über das Gesagte nachdachte, wollte man direkt Hand an eigene Projekte legen. Und ich finde, dass dieses Gefühl mehr als alles andere für eine ausgezeichnete Konferenz spricht. Daher vielen Dank an Mark Thiele für die hervorragende Organisation, bis zum nächsten Mal!

brew update && brew upgrade `brew outdated`

Dabei kümmert sich brew update zuerst um die Aktualisierung von Homebrew und der Paketliste selbst, brew outdated listet alle lokal installierten Pakete, für die eine Aktualisierung vorliegt, die dann schließlich mit brew upgrade installiert werden. Voilá!

Octopress basiert auf dem statischen Seitengenerator Jekyll, der unter anderem auch alle GitHub-Pages antreibt, bietet darüber hinaus viele weitere Features:

• Bequemes Schreiben mit dem Fokus auf Inhalten
• Lesefreundlicher Standard-Theme mit Unterstützung von mobilen Geräten
• Syntax-Highlighting für Code in Solarized-Optik, diverse Einbettungsmöglichkeiten auch über Gist und jsFiddle
• Unterstützung für Twitter, Facebook, Google +1, Google Analytics
• Kommentare über Disqus
• Einfacher Template-Aufbau
• Vielfältige Deployment-Möglichkeiten

Es ist wirklich so angenehm, sich beim Schreiben von Texten ganz auf den Inhalt konzentrieren zu können: Alle Texte werden einfach in Markdown geschrieben (mittlerweile eines meiner Lieblingsformate), das geht mit jedem beliebigen Text-Editor und passt sich so an persönliche Vorlieben und Workflows problemlos an. Damit sind die Texte auch jederzeit einfach portierbar, einen Konverter um Wordpress-Inhalte nach Markdown zu konvertieren gibt es ebenfalls.

Octopress kommt dabei von Haus aus mit einem ansehnlichen, lesefreundlichen Standard-Theme, so dass man direkt loslegen kann, ohne sich vorher um viel kümmern zu müssen: In einer Konfigurationsdatei trägt man die wichtigsten Grundeinstellungen (Seiten-Name, URL-Struktur, etc.) ein und aktiviert nach Wunsch die mitgelieferten Widgets (u.a. GitHub, Twitter oder Google Analytics), dann kann es losgehen. Ein weiterer Vorteil ist die bequeme Art, Codebeispiele einbetten zu können: Entweder per reinem Markdown, in GitHub-typischer “Three Backtick”-Weise, als Link direkt aus einer Datei, per Gist oder jsFiddle, dazu alles direkt mit gut durchdachtem Syntax-Highlighting.

Die mitgelieferte Disqus-Integration lädt die Kommentare zu einem Beitrag über Ajax nach. Das mag nicht ganz ideal sein, da Artikel und Kommentare von einander getrennt sind, liegt aber durch die statisch generierten Seiten in der Natur der Sache. Disqus bietet dafür aber gute Moderations- und Spamfilter-Möglichkeiten, ebenso kann sich ein Nutzer direkt über Twitter, Facebook, o.ä. einloggen. Sollte man irgendwann in Betracht ziehen, die Kommentare anderswo verwalten zu wollen, ist ein kompletter Datenexport jederzeit möglich. In Octopress lassen sich auch andere Kommentarsysteme integrieren.

Da Octopress weder auf eine Datenbank oder eine bestimmte Serverumgebung angewiesen ist, fällt auch das Deployment sehr flexibel aus: Die statischen Seiten können auf beliebigen Hostingplattformen abgelegt werden. Das geht entweder direkt per RSync, alternativ stehen auch GitHub-Pages oder Heroku als Hosting-Plattform zur Auswahl (für die kommende Version sind sogar Amazon S3 und CloudFront in Planung). Wer seine Seiten vor der Publizierung nochmal prüfen möchte, kann dazu die Vorschau auf dem integrierten Webserver nutzen.

Neben der freien Plattform-Wahl können statische Seiten deutlich schneller ausgeliefert werden: Auch wenn es für datenbankgestütztze Systeme wie Wordpress diverse Caching-Plugins gibt, kommen Sie von der Performance her nicht an statische HTML-Seiten heran. Die Seiten sind weder anfällig für SQL-Injections, noch müssen Updates oder Sicherheits-Patches eingespielt werden.

Fazit

Octopress ist ein System um einfach und schnell Inhalte zu publizieren, gerade für Leute, die ohnehin lieber in Texteditor und Konsole arbeiten und nicht auf WYSIWYG-HTML-Editoren angewiesen sind. Ruby-Sprachkenntnisse sind für den täglichen Gebrauch nicht erforderlich: Die Templates sind in sehr übersichtlichem Liquid-Syntax gehalten, aber wer mag kann mit wenigen Zeilen Code eigene Plugins erstellen oder vorhandene erweitern.

Eine ausführliche Dokumentation findet sich auf octopress.org, probiert es einfach mal aus …

Bisher hatte ich zum Verwalten von Ruby-Versionen RVM genutzt, um die Version 1.9.2 parallel zur mit OS X gelieferten System-Version 1.8.7 zu betreiben. Das funktioniert soweit auch ganz prächtig, wenn man (wie ich) aber keine weiteren Features von RVM benutzt, gibt es auch eine einfachere Alternative.

rbenv konzentriert sich auf das Wesentliche, das Festlegen der verwendeten Ruby-Version, entweder auf globaler oder projektbezogener Ebene. Selbst das Downloaden und Installieren von unterschiedlichen Ruby-Versionen ist in das Schwesterprojekt ruby-build ausgelagert. Damit folgt es dem UNIX-Gedanken, dass ein Programm lediglich eine einzige Aufgabe erfüllen sollte - und das zuverlässig. Die Verwaltung von Gemsets bietet rbenv nicht, dafür empfiehlt sich stattdessen Bundler, das ohnehin mittlerweile in vielen Projekten Verwendung findet.

Schritt 1: Ruby Version Manager (RVM) deinstallieren

Wie tief sich RVM im System verankert stellt man fest, wenn man es versucht zu deinstallieren. Eigentlich sollten diese beiden Zeilen genügen:

1
2

$ rvm implode
$ gem uninstall rvm

Dazu kommen - je nach System - allerdings noch Einträge in ~/.bashrc, ~/.profile, ~/.bash_profile oder /etc/profile und die Ordner /etc/rvmrc, /etc/profile.d/rvm und ~/.rvmrc.

Ebenso sollte man einen Blick in /usr/local/bin werfen: Hier können sich noch Symlinks und RVM-Ersatzscripte für erb, gem, irb, rake, rdoc, ri, ruby und testrb befinden. Ich hoffe, dass ich bei dieser Auflistung nichts vergessen habe, es empfiehlt sich auf jeden Fall, die entsprechenden Ordner und Dateien genau zu durchleuchten.

Schritt 2: rbenv/ruby-build installieren

Wenn man unter OS X den Paketmanager “homebrew” installiert hat, geht die Installation erfreulich einfach:

1
2
3

$ brew update
$ brew install rbenv
$ brew install ruby-build

Danach fügt man noch in seinem Shell-Profil die Zeile eval "$(rbenv init -)" hinzu und startet anschließend den Shell-Prozess neu. Die Installation ohne Paketmanager ist ähnlich schnell erledigt.

Schritt 3: Ruby installieren

Die Installation einer neuen Ruby-Version ist dann in wenigen Schritten abgeschlossen:

1
2
3
4
5
6
7
8
9
10

# Installiert die gewünschte Ruby-Version
# (eine Übersicht der verfügbaren Versionen erhält man mit `rbenv install`)
$ rbenv install 1.9.2-p290

# Wichtig: Muss nach jeder Installation von Ruby oder Gems mit
# ausführbaren Dateien einmal aufgerufen werden.
$ rbenv rehash

# Setzt die global verwendete Ruby-Version
$ rbenv global 1.9.2-p290

… fertig und ready to rumble.

Üblicherweise befinden sich die Einstellungen zum Prompt in einer Datei namens .profile oder .bash_profile im Home-Ordner des eigenen Benutzers. Dort sucht man nach einer Zeile, die mit PS1= beginnt. Im folgenden Beispiel ist der Prompt so aufgebaut, dass er den aktuellen Benutzer, den Host- und aktuellen Verzeichnisnamen ausgibt, gefolgt von einem Dollar-Zeichen als Abschluss.

Das Ganze sieht dann in den Profileinstellungen so aus:

1

PS1='[\u@\h] \w\$ '

Um nun Informationen über Git- und SVN-Repositories im Prompt anzeigen zu können, müssen wir die Einstellungen folgendermaßen erweitern:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

vcs_info() {
    if [ -d .svn ]; then
        echo -e " [svn]"
    else
        branch=`git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/'`
        if [ $branch ]; then
            # If branch is not master, add branch name
            branch=`echo $branch | sed -e 's/master//'`
            if [ $branch ]; then branch=":$branch"; fi
            echo -e " [git$branch]"
        fi
    fi
}

PS1='[\u@\h] \w$(vcs_info)\$ '

Die Funktion prüft zunächst, ob es im aktuellen Verzeichnis einen versteckten Ordner .svn gibt. Das bedeutet, dass der Ordner zu einem Subversion-Repository gehört. Als Ausgabe erscheint dann im Prompt:

[user@host] ~/Workspace/my_svn_project [svn]$

Für Git ist es ein kleines bisschen aufwändiger: Per git branch wird ermittelt, ob wir uns überhaupt in einem Git-Repository bewegen. Falls das der Fall sein sollte und wir im master-Branch arbeiten, geben wir die Information verkürzt aus:

[user@host] ~/Workspace/my_git_project [git]$

Ist hingegen ein anderer Branch aktiv, wird dieser zusätzlich aufgeführt:

[user@host] ~/Workspace/my_git_project [git:my_git_branch]$

Der Übersicht halber, habe ich im obigen Code-Beispiel auf die Escape-Sequenzen zur Kolorierung verzichtet. Die vollständige Version findet sich zusammen mit anderen gesammelten Tricks in meinem dotfiles-Repository auf GitHub.

UPDATE: Thomas hat mich freundlicherweise noch auf git-completion hingewiesen, dass zudem noch Tab-Vervollständigung der Branch-Namen bietet.

Falls man – wie ich – das Kommando git durch einen Alias g ersetzt hat, muss man zusätzlich am Ende des Scriptes die folgende Zeile einfügen, damit die Vervollständigung auch mit dem Alias funktioniert:

1
2

complete -o bashdefault -o default -o nospace -F _git g 2>/dev/null \
    || complete -o default -o nospace -F _git g

deck.js

Das Framework deck.js von Caleb Troughton ist quasi “the new kid in town”. Was mir auf den ersten Blick gut gefällt ist der modulare Aufbau: Themes, Transitions und Erweiterungen wie eine Slideübersicht, sichtbare Slidenummern, etc. können alle nach eigenem Belieben zusammengestöpselt werden.

Das birgt natürlich auch die Gefahr, dass man sich statt am den Inhalt einer Präsentation zu sehr auf das Feintuning von Plug-Ins und Effekten konzentriert. Es ist auf jeden Fall ein interessantes Framework, die Modularität erlaubt das Abstimmen auf die eigenen Bedürfnisse, wenn man sich ein wenig Zeit nimmt, in die Details einzusteigen.

impress.js

In eine ähnliche Kerbe schlägt impress.js das optisch wirklich äußerst beeindruckend ist. Es orientiert sich im Wesentlichen an dem Präsentationsservice prezi.com, bedient sich dabei aber ausschließlich CSS3 Transformationen und Transitions von modernen Browsern. So lassen sich auf einer beliebig großen Präsentationsoberfläche Position, Rotation und Größe der einzelnen Objekte festlegen.

Momentan muss man die Werte leider für jedes Slide von Hand angeben, was die ganze Sache noch ein wenig mühselig macht. Aber da das Framework noch sehr jung ist, wird sich da sicherlich noch was tun.

CSSS

Das CSS-based SlideShow System von Lea Verou setzt – wie der Name schon sagt – den Schwerpunkt bei der Umsetzung auf CSS, lediglich die Komponenten, die sich darüber nicht abbilden lassen, werden durch JavaScript unterstützt. Die Struktur der Folien bleibt dadurch schlank und das Ergebnis kann sich sehen lassen.

Pik6

Eigentlich nur als selbstgebautes Hilfsmittel für seine HTML5-Erklärbär World Domination Tour gedacht, verfolgt Peter Kröner mit Pik6 einen sehr interessanten Ansatz: Durch die Verwendung von WebWorkern können mehrere Browserfenster mit der Präsentation synchron laufen. Das ermöglicht z.B. die Darstellung auf einem Projektor, während in einem anderen Fenster der Präsentationsmodus läuft, der auch separate Notizen für den Vortragenden ermöglicht. Ebenso können sich mehrere Clients die Präsentation gleichzeitig ansehen, etwa zusätzlich zur Projektion auf dem eigenen Laptop.

Praktisch für Entwickler: Automatisches Syntax-Highlighting von Quellcode ist schon direkt mit an Board.

Reveal.js (aka CSS 3D Slideshow)

Wem Präsentationen in 2D zu langweilig sind, der sollte zu Reveal.js von Hakim el Hattab greifen. Basierend auf seinem CSS-Experiment CSS 3D Slideshow, kann man schnell gut aussehende Präsentationen erstellen, benötigt aber auch hier zur Darstellung einen aktuellen Browser, der CSS 3D Transitions und Transformationen unterstützt. Die anderen Experimente auf seiner Seite können sich ebenfalls sehen lassen.

HTML5 Slides

Google stellt mit seinen HTML5 Slides ebenfalls ein weitverbreitetes HTML-Präsentationsframework. Der Code ist dank HTML5 schön übersichtlich strukturiert, <article> Tags bilden die einzelnen Slides, die gängigen Präsentationselemente (einzeln eingeblendete Listenpunkte, Bilder in unterschiedlichen Größen, Codebeispiele mit Syntax-Highlighting, etc.) sind über Slide-Klassen bereits definiert.

Layouts für 4:3-Darstellung und Widescreen lassen sich über die jeweilige Klasse für die ganze Präsentation setzen … hier fehlt mir persönlich noch ein Automatismus, damit sich die Slides besser auf die Fullscreen-Darstellung anpassen.

Weitere Frameworks

• S5 – Eines der ersten Frameworks für HTML-Präsentation von CSS Godfather Eric Meyer
• slides – Eine schlichte und elegante Lösung von Brian Cavalier
• Shower von Vadim Makeev (Opera) bietet unter anderem eine schöne Slide-Übersicht

Fazit

Für welches Framework man sich letzten Endes entscheidet bleibt eine Frage des Geschmacks. Es wird auf jeden Fall deutlich, dass aktuelle Web-Techniken in vielen Bereichen ein hervorragender Ersatz für klassische Präsentationssoftware sein können.

Update (5.01.2012): impress.js als neues Framework hinzugefügt.

Normalerweise wird in den meisten Programmiersprachen Programmcode sequenziell abgearbeitet, das heißt eine neue Anweisung im Code wird erst dann begonnen, wenn die vorausgegangene Anweisung vollständig abgearbeitet ist. Wenn hingegen Vorgänge nebenläufig durchgeführt werden sollen, greifen Programmiersprachen wie z.B. Java auf sogenannte Threads zurück: Die nebenläufige Aufgabe wird angestoßen und durch einen separaten Prozess ausgeführt, während der vorhergehende Code weiterläuft. Das Problem dabei: Jeder zusätzliche Thread verbraucht sowohl CPU-Zeit als auch Speicherplatz im RAM, was bei vielen gleichzeitigen Threads zu Performance- und Skalierungsproblemen führen kann.

Node.js hingegen arbeitet mit einem einzigen Thread und verarbeitet den Code eventbasiert. Was das bedeutet, kennt man teilweise schon aus dem normalen clientseitigen JavaScript, wenn es z.B. um DOM-Events geht. Hier ein Beispiel in jQuery:

1
2
3

$('button').click(function(){
    alert('Hallo Welt!');
});

Die Aktion wird im Vorfeld definiert, was daraufhin aber geschehen soll kommt erst dann zum Tragen, wenn das Ereignis tatsächlich ausgelöst wird.

Was hat diese Arbeitsweise für Vorteile in Node.js?

Wie bereits zu Anfang erwähnt, wird in vielen Sprachen die weitere Ausführung von Code geblockt, bis eine Anweisung verarbeitet wurde. Dies betrifft nicht nur einfache Operationen, sondern auch z.B. Zugriffe auf das Dateisystem, Datenbankanfragen, Web-Services, etc. All diese Operationen blockieren die weitere Verarbeitung.

Auf den ersten Blick scheint das nicht weiter problematisch zu sein. Wenn man sich das aber mal in Rechenzyklen vorstellt, bekommt dieses Vorgehen schon ganz andere Dimensionen. Ich glaube, Ryan Dahl (der Entwickler von Node.js) hat dafür einmal folgendes Beispiel genutzt:

Liquid error: undefined method `map’ for #<String:0x00000101e7fc00>

In all dieser Zeit bleibt die eigentliche Arbeit liegen, da immer noch auf die Information aus Tokio gewartet wird. Da man grade unterwegs ist, die Daten zu beschaffen, kann man auch in der Zwischenzeit keine anderen Arbeiten erledigen (z.B. Anrufe im Büro annehmen).

Aus diesem Grund sind solche Operationen in Node.js grundsätzlich “nicht blockierend” und werden wie z.B. aus dem DOM bekannt eventbasiert ausgeführt. Das gilt für Zugriffe auf das Dateisystem, Datenbanken, Netzwerk-Verbindungen, etc. Und das ist eigentlich auch der Part, an den man sich als Node.js-Einsteiger ein wenig gewöhnen muss.

Solche Anweisungen wie

1
2
3

var myfile = fs.readFile('myfile.txt', 'utf8');
console.log(myfile);
console.log('Fertig!');

wird man so in der Regel in Node.js nicht finden, stattdessen werden Callback-Funktionen verwendet:

1
2
3
4
5

fs.readFile('myfile.txt', 'utf8', function(err, data) {
    if (err) throw err;
    console.log(data);
});
console.log('Fertig!');

Das bedeutet also in diesem Fall auch, dass wir auf der Konsole zuerst “Fertig!” sehen und dann erst den Inhalt der Datei. Dessen muss man sich bei der Entwicklung bewusst sein. Das wird vor allem dann schnell ein wenig wuselig, wenn man beispielsweise Kombination hat wie: Warte auf eine Datei, die per Webformular hochgeladen wird, lese diese Datei dann ein und schreibe deren Inhalt in eine Datenbank. Hier muss man also darauf achten, wann welche Daten tatsächlich zu Verfügung stehen, bevor man sie weiterverarbeiten kann.

Und wofür kann ich Node.js verwenden?

Für die Auslieferung einfacher statischer Inhalte tut es nach wie vor ein gewöhnlicher Webserver, dafür wäre Node.js kein Gewinn, ebenso wie bei rechenlastigen Apps. Wo es allerdings seine Stärken ausspielen kann, sind die Bereiche, in denen seine eventbasierte Art zum Tragen kommt. Also bei Datenverarbeitung wie beispielsweise bei (JSON) APIs oder Streaming. So können z.B. mit Node.js Videofilme schon beim Hochladen auf einen Server in ein anderes Format transkodiert werden oder Clients über WebSockets (bzw. sockets.io) mit aktuellen Daten versorgt werden.

Aber auch für Kommandozeilenprogramme und Shellscripte lässt sich Node.js verwenden, etwa für Buildtools oder zur Datenverarbeitung.

Node.js selbst ist vom Umfang her sehr rudimentär, bringt aber alle grundlegenden Bausteine mit, aus denen man eine ganze Menge ausbauen kann, etwa: Events, Buffer, Streams, TLS/SSL, Dateisystem-Zugriff, DNS, UDP und HTTP. Es ist auch bewusst das Ziel der Entwickler, den eigentlichen Kern schlank zu halten und sich auf das Wesentliche zu konzentrieren.

Man kann also mit wenigen Zeilen Code von Hand seinen eigenen Webserver schreiben (quasi das “Hello World” in fast allen Node.js-Tutorials), für weiterführende Aufgaben ist das natürlich wenig praktikabel. Es gibt natürlich schon eine ganze Menge Bibliotheken, die einem die Arbeit vereinfachen, so z.B. für Datenbank-Anbindungen, API-Handler, Parser, Template-Engines und vieles vieles mehr, wie etwa das Web-Framework “Express”.

Kann man Node.js schon produktiv einsetzen?

Diese Frage wird recht häufig gestellt, da der stabile Zweig von Node.js grade erst bei Version 0.4 ist. Eine pauschale Antwort darauf zu geben ist nicht leicht. Node.js hat erst vor etwa einem Jahr richtig an Fahrt aufgenommen, hat aber eine sehr aktives Entwicklerumfeld, der IRC-Channel ist immer gut gefüllt und die Leute insgesamt sind sehr hilfsbereit.

Auch wenn es noch vergleichsweise wenige Unternehmen gibt, die Node.js als Haupt- oder Exklusiv-Technologie verwenden, gibt es doch viele, die zumindest Teile ihres Business mit Node.js betreiben: So etwa Anbieter von Webservices und APIs, GitHub zum dynamischen Erstellen aller Downloads, LinkedIn hat grade den Server-Part ihrer mobilen App von Rails auf Node.js umgestellt, mit Yammer gibt es sogar ein komplettes Enterprise Social Network und Zynga verwendet es für ihre HTML5-basierten Spiele.

Es kommt also insgesamt auf den Kontext an. Was man aber eindeutig festhalten kann: Node.js gewinnt zunehmend an Bedeutung und erfährt eine breitere Adaption im produktiven Umfeld.

Am besten bekommt man aber ein Gefühl für Node.js, wenn man es direkt selber mal ausprobiert:

Installation

Linux-Nutzer können Node.js problemlos direkt kompilieren.

Wer Node.js auf Mac OS X installieren will, sollte vorher XCode installiert haben (oder das eigenständige GCC-Paket für OS X), da Node.js kompiliert werden muss. Das geht am einfachsten, wenn man es über einen Paketmanager wie “homebrew” macht.

Unter Windows ist das ganze momentan noch etwas umständlicher: Zwar gibt es einen nativen Build von Node.js für Windows, es handelt sich aber noch um eine recht junge Entwicklungsversion, in der noch nicht alles rund läuft. Bis Ende des Jahres wollen die Entwickler aber eine stabile Version anbieten.

Alternativ lässt sich Node.js aber auch via Cygwin installieren, entweder von Hand oder als aktuelles Binary-Paket.

Als nächstes noch den Paketmanager npm installieren, über den man Zugriff auf die vielen bestehenden Tools und Bibliotheken erhält.

Dann kann es jetzt ja losgehen …

Links:

• Node.js
• NPM
• Felix’s Node.js Guide
• Node Beginners Book
• Mastering Node.js (Free E-Book)
• Express

Ruby ist eine dynamische, stark typisierte Sprache, die Mitte der 90er von Yukihiro “Matz” Matsumoto geschaffen wurde. Der große Unterschied z.B. zu PHP ist dabei, dass diese Sprache komplett objektorientiert aufgebaut ist, was eines der herausragenden Merkmale von Ruby ist.

Die aktuelle Version von Ruby ist 1.9.2 … dabei müsste sich die Versionsnummer eigentlich genauer genommen auf den Ruby-Interpreter beziehen. Denn hier sind wir schon bei einer Besonderheit. Neben dem “offiziellen” Ruby-Interpreter (auch MRI, “Matz’ Ruby Interpreter” genannt), gibt es noch weitere kompatible Interpreter, die teilweise für spezielle Einsatzzwecke angepasst sind, z.B. Rubinius, JRuby, Ruby Enterprise Edition, IronRuby oder MacRuby.

Auch wenn ich mir die Interpreter noch nicht genauer angesehen habe, sind doch zwei davon recht interessant: Zum einen ist das JRuby, das eine 100%ige Java-Implementierung von Ruby darstellt. Man kann damit also beide Welten miteinander verbinden und auf existierenden Code von beiden Seiten aus zugreifen. Sicherlich auch im Enterprise-Kontext nicht uninteressant. Der zweite interessante Interpreter ist MacRuby, das sich auch mit XCode zusammen verwenden lässt, um native Mac-Programme ohne Objective-C zu schreiben. Für iOS ist das leider nicht geeignet aufgrund des dort fehlenden Garbage Collectors. Mit Ruboto hingegen ist ein Ruby für Android bereits in der Entwicklung.

Aber für diese Betrachtung bleibe ich weiterhin beim “normalen” MRI Ruby 1.9.2.

Installation

Wer sich Ruby einfach mal ein wenig ansehen möchte oder auch professionell damit entwickeln möchte, sollte sich entweder den Ruby Version Manager (RVM) oder rbenv von 37signals verwenden. Das sorgt für eine saubere Trennung der Ruby-Umgebungen, so dass man getrost mehrere Interpreter parallel installieren kann, ohne irgendwann in heilloses Chaos zu versinken. Darüber hinaus wird bei OS X die mitgelieferte System-Ruby-Version von der eigenen Entwicklungsumgebung getrennt (man kann also nicht aus Versehen seine System-Rubyversion beschädigen).

Die Installation ist bei beiden Tools mit wenigen Handgriffen abgeschlossen und gut dokumentiert. Ich persönlich bevorzuge rbenv, man kann aber auch nachträglich von RVM auf rbenv umsteigen.

Ruby unter Windows

Wer Ruby unter Windows installieren möchte, findet ein komplettes Paket auf rubyinstaller.org. Es empfiehlt sich für einige Erweiterungen direkt das angebotene Development-Pack mit zu installieren. Danach müssen nur noch zwei Umgebungsvariablen für UTF-8 als Standardzeichensatz gesetzt werden (statt en_US kann man natürlich auch de_DE verwenden):

set LC_ALL=en_US.UTF-8
set LANG=en_US.UTF-8

Erste Schritte in Ruby

Eine gute Einführung in Ruby findet sich unter Try Ruby – hier wird man in kleinen interaktiven Einheiten in die Grundlagen der Sprache eingeführt, so dass man mit ersten Programmen schon direkt anfangen kann. Ich kann die Website nur wärmstens empfehlen: Schon nach etwa 20-30 Minuten hat man die wichtigsten Konzepte der Sprache kennengelernt. Ebenfalls praktischerweise in Ruby enthalten ist “irb”, die interaktive Ruby Konsole. Hier kann man direkt die ersten Schritte wagen und Ruby ausprobieren.

Wenn der Standard-Umfang der Sprache nicht mehr ausreichen sollte, kann man zusätzlich auf Pakete zugreifen, von denen es im Netz mehr als 27.000 Stück für so ziemlich alle Lebenslagen gibt. Mit

gem install <paketname>

installiert man ein solches “Gem”, um bereits vorhandene Pakete auf den neusten Stand zu bringen reicht ein “gem update”. Ein Verzeichnis der Gems findet man unter anderem auf rubygems.org oder GitHub. Übrigens: Man kann auch problemlos Ruby verwenden, um damit eigene Shell-Scripte für *nix und Mac zu schreiben und hat dabei ebenfalls Zugriff auf den vollen Sprachumfang.

Rails

Rails ist das am weitesten verbreitete MVC Framework für Ruby und ist ideal für Web-Applikationen und schnelles Prototyping. Alle typischen CRUD-Datenoperationen (Create, Read, Update, Delete) können dabei einfach über die URL aufgerufen werden, z.B.:

/users           Listet alle Datensätze des Typs "user" auf
/user/1          Zeigt den User-Datensatz mit der ID 1
/users/new       Zeigt eine Eingabemaske um einen neuen Benutzer anzulegen
/users/1/edit    Zeigt eine Eingabemaske um den Benutzer mit der ID 1 zu editieren

Rails Motto ist “convention over configuration”, so dass vieles schon bereits “out of the box” funktioniert, wenn man sich an die Rails-Konventionen hält, natürlich kann man auch Dinge anpassen, muss diese aber dann von Hand konfigurieren. So lässt sich natürlich im obigen Fall z.B. der Zugriff beschränken (z.B. für angemeldete Benutzer oder Administratoren) oder die Namen der Routen ändern.

Rails: Scaffolding

Neue Datenmodelle legt man in der Regel über ein sogenanntes Scaffolding an, dass bereits alle notwendigen Dateien (Model, View, Controller und Unit-Tests) anlegt und auch im Datenbank-Script die entsprechenden Einträge hinterlegt (welches sogar versioniert aufgebaut ist, so dass Änderungen in der Entwicklungs-Umgebung auch versionsweise auf dem Produktiv-System automatisch nachgezogen werden können).

Ein Scaffolding-Aufruf für ein einfaches Benutzer-Modell sieht so aus:

rails generate scaffold User name:string email:string password:string

Rails: Models

Nur um kurz zu zeigen, weshalb Rails einem die Entwicklung an vielen Stellen so vereinfacht, möchte ich noch ein Beispiel für den Umgang mit der Datenmodellierung geben.

Selbst ohne weitere Kommentare kann man sehr gut verstehen, wie das Modell aufgebaut ist:

1
2
3
4
5
6
7
8
9
10
11
12
13

class User < ActiveRecord::Base
  validates :name, :presence => true
  validates :email, :presence => true, :uniqueness => true, :format => { :with => /[\w\d]*@[\w\d]*\.\w{2,5}/ }
  validates :password, :presence => true, :length => { :minimum => 5 }

  has_many :postings
end

class Posting < ActiveRecord::Base
  validates :title, :presence => true, :length => { :minimum => 2, :maximum => 200 }

  belongs_to :user
end

So einfach werden Validierungsregeln und Datenabhängigkeiten untereinander definiert.

Um an die Informationen im Modell zu kommen, benutzt man folgenden Aufruf:

1
2

administrator = User.find(1)
=> #<User id: 1, name: "Jim Panse", email: "jim@panse.com", password: "ILoveTheJungle">

Ebenso kommt man über diesen User direkt auch an seine Postings:

1
2
3
4
5

administrator.postings.count
=> 4

administrator.postings
=> [#<Posting id: 1, …>, #<Posting id: 4, …>, …]

Rails: Fazit

Mein erster Eindruck: Wenn man schnell eine Webapplikation bauen möchte, die in das oben beschriebene Schema passt, geht das mit Rails wirklich fix. Mit einem grundlegenden Tutorial daneben, um ab und an Details nachzuschlagen, kann man sehr schnell auch produktive Apps bauen.

Hat man hingegen sehr unstrukturierte Daten oder muss an vielen Stellen Hand anlegen und tief im System rumwerkeln, ist Rails glaube ich nicht die richtige Wahl, da auch sehr viel “Magic” im Hintergrund geschieht. Die immer im Detail zu verstehen und entsprechend “umbiegen” zu können ist sicher eher was für Rails-Experten.

Ich denke, auch hier greift wieder die typische 80/20-Regel: Für 80% der üblichen Web-Applikationen, die in irgendeiner Art Datensätze verwalten dürfte Rails gut passen und eine tolle Vereinfachung darstellen. Grade bei für Entwickler so leidige Themen wie Validierung, Datenmodellierung und -verarbeitung kann man sich vieles sparen und sich direkt um den Kern der Anwendung kümmern.

Rails hat eine sehr aktive Entwicklergemeinde, daher wird das Framework stets weiterentwickelt und verbessert, wobei man sich auch nicht scheut, Komponenten auszutauschen oder alte Zöpfe abzuschneiden, so dass man beim Updaten zumindest in Hauptversionszweigen (2.x, 3.0, 3.1) auf jeden Fall ein wenig die Augen aufhalten muss. Da Rails aber dazu anhält, testorientiert zu entwickeln, lässt sich vieles vorab prüfen und beheben, bevor man eine neue Version seiner App in die Produktivumgebung einspielt.

Links:

• Try Ruby
• Ruby on Rails Tutorial
• Interaktiver Screencast: Rails for Zombies
• Ruby Weekly: A free, once–weekly e-mail round-up of Ruby news and articles.

Statt alle Module einzeln einzubinden

1
2
3
4

http = require 'http'
url  = require 'url'
util = require 'util'
fs   = require 'fs'

lässt sich das auch bequem in einer Zeile abkürzen:

1

['http', 'url', 'util'].forEach (m) -> global[m] = require m

Danke an @teemow für die kleine Korrektur.