Animated GIFs – here we go again

Totgesagte Leben bekanntlich länger, wobei so richtig vorbei war der Hype ja nie. Wir erinnern uns an die inflationäre Verwendung auf Google+ im letzen Jahr? Seit Ende der 1980er Jahre taucht das Graphic Interchange Format regelmäßig wieder auf und ist nicht unterzukriegen. Kaum ein anderes Format, das derart polarisiert. Von den einen geliebt, von den anderen verhasst. Und jetzt die Good News: Es hat eine Professionalisierung gegeben und abseits des nervigen Gezappels gibt es heute ein paar wirklich klasse Einsatzmöglichkeiten, die ein erneutes Revival versprechen.

Die Geschichte des Graphic Interchange Formats

Das Graphics Interchange Format, entwickelt 1987 von Steve Wilhite und eingeführt von dem US-Online-Dienst CompuServe, hat den Vorgänger RLE abgelöst, der nur Schwarz-Weiß-Bilder darstellen konnte. – Wikipedia

Bereits das erste Format konnte mehrere Bilder in einer Datei speichern. Diese Fähigkeit wurde genutzt um True Color GIFs mit einer Farbtiefe von 24 bit zu erstellen. Logischer nächster Schluss war es, verschiedene Bilder mit leichten Änderungen nacheinander in einer Datei unterzubringen, wodurch der Eindruck einer Animation entstand. Voilà, das animated GIF war geboren!

Der Overkill der animierten Bilder

Als Mitte der 1990er Jahre der Netscape Navigator am Markt erschien, wurde eine neue Ära eingeleitet. Browser konnten fortan diese Dateien automatisch animieren und eine Flut von GIFs überschwemmte das Web.

Die Klassiker waren mitunter die amerikanische Flagge, Flammen oder aber auch der „Under Construction Bar“. War es irgendwie möglich, wurde animiert. Überbleibsel solcher Websites finden sich ja bis heute im Web.

Zuerst wurden Animated GIFs eigentlich nur als Eyecatcher verwendet. Um die Jahrtausendwende hat man sich dann endgültig satt gesehen und sie galten bald schon als veraltet. „Animated GIFs, die sind ja wirklich abgedroschen und aus dem letzten Jahrtausend“, ächzte es aus allen Ecken. Doch wie in der Mode kann man sich alle Trends ruhig merken. Denn, sie kommen wieder!

Animated GIFs & Cinemagraphs

Mit der Verwendung von HTML5 und CSS3 haben sich völlig neue Möglichkeiten in punkto User Interface Design ergeben. Animierte Inhalte sind auf fast jeder Website zu sehen und dadurch erleben auch Animated GiFs ihre Renaissance. Egal ob auf Blogs, in Onlinekatalogen, Headergrafiken, oder Logos, man kann sie überall einsetzen. Man verleiht den altbewährten statischen Fotos neues Leben.

1000 Wege zum animierten Bild

Aber wie erstellt man nun diese animierten Grafiken? Designer kennen bestimmt schon genügend Wege, aber wie sieht es bei Laien aus? Es gibt unzählige kostenlose „Animated GIF Creators“ im Web, aber taugen die auch etwas? Zum Teil. Wer jedoch tolle und exakte Animationen erstellen möchte, sollte auf Photoshop CS6 oder eine ähnliche Version setzen, die Videoframes auf Ebenen unterstützt.

Eine weitaus schnellere Variante, die auch unterwegs gut funktioniert, ist Cinemagram. Damit lassen sich Kurzvideos aufnehmen, aus denen man eine Sequenz wählt. Im Anschluss wird der zu animierende Bereich ausgewählt und nach Lust und Laune mit Filtern, ähnlich wie Instagram ausgestattet und fertig ist das GIF. Danach kann es wahlweise gespeichert oder auf Facebook wie auch Twitter veröffentlich werden. Wäre doch mal was Neues, im Gegensatz zu den schon langweiligen Instagram Fotos. Man lässt seine Freunde an dieser Szene teilhaben, nicht nur durch ein Bild.

Ich hoffe, euch hat dieser Beitrag selbst animiert, in Zukunft mit dem totgesagten Format ein wenig zu spielen und es in eure Arbeiten und Projekte zu integrieren um die Dinge ein wenig lebendiger zu gestalten. Wir haben da schon etwas im Hinterkopf, dazu aber mehr im neuen Jahr.

Und zum Schluss habe ich noch eine nette Website mit einer animierten Headergrafik.

Barracuda, Octopus und Aegir – Aquarium im Eigenbau

Was die Haushaltsversicherung in Hinblick auf Wasserschäden sicher etwas nervös macht, können wir als Drupal Developer völlig risikofrei und mit garantiert trockenen Socken in Angriff nehmen. Konkret wollen wir den vom OS mitgelieferten Apache, beziehungsweise LAMP/WAMP/MAMP, durch eine lokale BOA Instanz ersetzen. Im Rahmen dieser mehrteiligen Blogreihe stellen wir das System vor und erklären Schritt für Schritt, wie man es auf dem eigenen Rechner konfiguriert.

Von Raubfischen und Kopffüßern

Wer mehrere Drupal Webseiten betreibt und bestrebt ist seine Arbeitsabläufe zu beschleunigen, der stößt unweigerlich auf Aegir. Aegir ist ein Hostingsystem, das selbst auf Drupal basiert und dabei hilft, mehrere Drupal Installationen zu verwalten.

Aegir makes it easy to install, upgrade, deploy, and backup an entire network of Drupal sites.

Klingt spannend, ist es auch! Automatische Backups, Migration ganzer Webseiten, kollektive Updates, Seiteninstallation per Mausklick, [Drush] Integration – das lässt das Administratorherz höher schlagen. Eine vollständige Auflistung und Erklärung aller Aegir Features würde allerdings den Rahmen dieses Beitrags sprengen. Wer sich dafür interessiert, wird um die [Aegir Community Seite][community] ohnehin nicht herum kommen.

Drupal in Drupal in …?

Wer jetzt schon im Geiste mit [Inception] Metaphern um sich wirft, der möge sich noch einen Moment gedulden. Der Name des BOA-Projekts, mit dem wir uns eigentlich beschäftigen, steht für Barracuda Octopus Aegir. Und es handelt sich dabei um nicht weniger als ein System zum Verwalten mehrerer Aegir Instanzen.

Kein Scherz.

Genau genommen ist BOA ein Shellskript, das eine nackte Linux Maschine (Vorzugsweise Ubuntu 12.0.4) von Grund auf in ein High-Performance Drupal Hostingmonster verwandelt. Und in der wiederum können mehrere Instanzen von Aegir gehostet werden, die wiederum mehrere Drupal Plattformen betreiben, in der wiederum mehrere Drupal-Seiten laufen. Das sind verdammt viele „wiederum“ für einen Satz. Um das Konstrukt im Ganzen zu erfassen, rollen wir es von aussen nach innen auf und definieren auch gleich die Begriffe, die uns weiter begleiten werden.

  • Barracuda: Das Shellscript, welches mit Root-Rechten in einer Vanilla Installation von Ubuntu oder Debian ausgeführt wird und den kompletten Server Stack von der Datenbank bis zum HTTP-Server konfiguriert.
  • Octopus: Ein weiteres Shellscript, das eine Aegir-Installation innerhalb von Barracuda, inklusive SSH/SFTP Zugängen für Developer und eine separate Administrationsoberfläche einrichtet.
  • Platform: Unter Platform versteht man im Grunde den Quellcode einer Drupal Distribution, die innerhalb einer Octopus Instanz betrieben wird. Das ist die Ebene auf der man operiert, wenn Drupal klassisch, also ohne BOA, installiert.
  • Site: Hierbei handelt es sich um das ganz normale Multisite-Verhalten einer Drupal Installation. Der einzige Unterschied ist, dass das Hostmaster-Interface von Aegir die Installation neuer Seiten direkt über das Administrationsmasken ermöglicht.

Technologie

Die genauen Eckdaten können der Projektseite von Barracuda entnommen werden. An dieser Stelle nur die wichtigsten Punkte:

  • NGINX: Barracuda setzt nicht auf dem altbekannten Apache Webserver auf, sondern nutzt NGINX. Dabei handelt es sich um eine deutlich schlankere, spezialisiertere und – speziell beim ausliefern von statischen Inhalten – sehr viel schnellere Alternative.
  • MariaDB: Drop-In Replacement für MySQL, das auf der einen Seite einige Performanceverbesserungen enthält, und gleichzeitig – im Gegensatz zu MySQL – vollständig Open Source lizenziert ist.
  • PHP-FPM/APC: Prozessoptimierung und Opcode Caching für PHP.
  • Redis: Performanter Key-Value Store, der für Cache-Bins in Drupal verwendet werden kann.
  • Tomcat und Solr: Richtig, die Katze sitzt gleich mit im Aquarium! Richtig tollen Suchfunktionen steht nichts mehr im Wege.

Und wozu das Ganze?

Um Drupal zu hosten, klingt es natürlich toll. Wir selbst betreiben unseren Server mit dieser Software, Omega8.cc – die Schöpfer von BOA – verkaufen nicht umsonst professionelles Hosting auf dessen Basis und auch Branchengrößen wie Pantheon bauen auf ähnlicher Technologie auf. Warum man sich alles nach Hause auf den eigenen Rechner holen sollte, erschließt sich allerdings nicht sofort. Folgende Gründe haben mich dazu bewogen:

  • „Auf meiner Maschine funktioniert es.“ Überraschungen beim Deployment sollten wegfallen, da wir zum Entwickeln dasselbe System betreiben, wie unserer Server.
  • Die komplette Installation ist in einer Virtuellen Maschine verpackt, die als ganzes gesichert und weitergegeben werden kann. Das spart Zeit, wenn Entwickler dazukommen oder ein Rechner aufgrund von übermäßigem Kaffeekonsum ausfällt.
  • Die Installation läuft selbst virtualisiert deutlich schneller, als der von Mac OSX mitgelieferte Apache oder MAMP. Wer viel Site-Building betreibt und mit Views und Panels UI arbeitet weiß das sicher zu schätzen.
  • Das lästige editieren der hosts-Datei fällt weg.
  • Die Domains funktionieren automatisch auch in anderen Virtuellen Maschinen. Stichwort Internet Explorer testing …
  • Testseiten können blitzschnell installiert und wieder entfernt werden. Datenbanken werden automatisch verwaltet.
  • Tomcat und Solr kommen ohne Zusatzaufwand oder große Konfiguration funktionstüchtig mit.

Diese Gründe sollten eigentlich ausreichen um Entwicklern das Wasser im Munde zusammenlaufen zu lassen. Die Tatsache, dass man damit auf diversen Meetups ganz toll prahlen kann ist nur das Tüpfelchen auf dem i. Im nächsten Teil werden wir uns mit dem richtigen Aufsetzen der Virtuellen Maschine beschäftigen. Stay tuned!