Dev-Blog

Entwicklungsblog von ZEIT ONLINE

Kluge Uhren, gebogene Displays

Von 5. März 2015 um 21:34 Uhr

Auf dem Mobile World Congress in Barcelona haben Technologiekonzerne in dieser Woche zahlreiche Neuerungen gezeigt. Nicht alle sind spektakulär. Welche der vielen Neuerungen werden also Konzeption, Design und Programmierung von Webanwendungen und Apps nachhaltig beeinflussen? Fünf Erkenntnisse aus Barcelona:

1. Es gibt einen Smart-Watch Hype

Ja, es gibt ihn, den Hype um Wearables und Smart-Watches. Im Moment aber nur auf Herstellerseite. Alle großen Smartphone-Hersteller haben sich dem Thema noch ein Mal gewidmet und die nächste Generation von Modellen in Barcelona vorgestellt. Die Palette reicht dabei vom einfachen Fitnessband, über ein Smartband mit E-Ink Display hin zur Android-Wear-Uhr mit Amoled-Display. Viele der neuen Modelle orientieren sich an der runden Moto 360. Anders die Samsung Gear S, die durch ihr verhältnismäßig großes, gebogenes Hochkant-Display deutlich mehr Bedienelemente und Inhalte darstellen kann. Wer sich also mit der Entwicklung einer Android-Wear-App beschäftigt hat, beschäftigt oder beschäftigen will, wird seinen Geräte-Zoo erweitern müssen.

Der Grund für die neuerliche Geräteflut ist klar: Alle warten auf Apple. Falls es Apple gelingt, seine Uhr erfolgreich und in hohen Stückzahlen am Markt zu platzieren, wollen viele Hersteller dabei sein.

2. Mehr gebogene Displays bei Handys

LG hat für sein G Flex – wohl als Antwort auf das Apple “Bendgate” – eher Gesäßtaschenträger als Zielgruppe ausgemacht. Samsung biegt kurzerhand den Display-Rand seines neuen Galaxy S6 Edge. Für Webdesign und Entwicklung hat das Auswirkungen, falls sich diese Variante des Galaxy S6 gut verkauft. Man müsste generell mehr Weißraum am Rand der Inhalte einplanen oder diesen Geräten per Device-Erkennung eine andere Layoutvariante spendieren.

Sowohl das Samsung Edge als auch die vielen runden Smart-Watches verdeutlichen noch einmal das Problem des Bildercroppings. Wie bestimmt man die wesentlichen Informationen in einem Bild und schneidet es über verschiedene Plattformen und Technologien zu, ohne wichtige Informationen zu verlieren? Für responsives Webdesign gibt es Ansätze wie focal-point oder jquery-focuspoint – cross-platform ist dies aber noch eine Herausforderung.

3. Microsoft sollte man nicht unterschätzen

Die neue Generation von Lumia Modellen läuft seit Dezember nicht mehr unter Nokia, sondern unter dem Namen Microsoft. Sie sehen gut aus und fühlen sich auch so an. Auch die Betaversion von Windows 10 macht sowohl optisch als auch funktional einen sehr angenehmen Eindruck. Ob Microsoft damit den großen Abstand zu iOS und Android verringern kann, ist jedoch unklar.

4. Ubuntu und FirefoxOS mit neuer Hardware

Ubuntu für Telefone konnte man bisher auf Android-Geräten installieren. Auf dem Mobile World Congress hat Ubuntu nun das erste eigene Telefon vom spanischen Hersteller BQ vorgestellt. Eher im Niedrigpreissegment angesiedelt, richtet es sich zunächst an Linux-Fans und kommt natürlich mit einer Konsole. Ein höherwertiges Gerät von Meizu wird bald in Asien erhältlich sein.

Neue Hardware gab es auch am Messestand von Firefox. Noch vor knapp zwei Jahren floppte die Markteinführung des Firefox-Phones in Europa, weil die Nutzer sich an hochwertige Geräte gewöhnt hatten. Trotzdem setzt Mozilla weiter auf günstige Hardware und Webstandards. Alle Apps in FirefoxOS können einfach mit HTML, CSS und JavaScript entwickelt werden. Bereits im vergangenen Sommer war es Mozilla gelungen, ein Handy für 25 US-Dollar auf den Markt zu bringen. Das ist insofern bemerkenswert als ein niedriger Preis eines Handys mehr Menschen Zugang zum Internet verschafft.

5. Der nächste große Schritt ist die nächste Milliarde Nutzer

Zugang zum Internet für alle Menschen, das war ohnehin eines der dominierenden Themen. Google und Facebook werden sich hier weiter engagieren. Sowohl Sundar Pichai von Google als auch Mark Zuckerberg kündigten an, Project Loon (Internetballons von Google) und internet.org (Kostenloses Basis-Internet von Facebook) weiter zu forcieren. Für Konzept, Design, Web- und App-Entwicklung mit globalem Scope bedeutet das natürlich: Einfacher ist immer besser – besonders auf ökonomischer Hardware und bei geringen Bandbreiten.

Michael Schultheiß ist Leiter der Entwicklungsredaktion bei ZEIT ONLINE.

Kategorien: Veranstaltungen

Glänzend und schnell: Webseiten mit Varnish

Von 19. Februar 2015 um 19:22 Uhr

Wer das heutige Netz kennt, weiß, dass sich die Aufmerksamkeit dank Social Media in Sekundenbruchteilen auf einen Punkt konzentrieren kann. Für diese Konzentration braucht es nicht mal einen Shitstorm. Ereignisse wie das Bekenntnis des ehemaligen Bundesligaprofis Thomas Hitzelsberger zu seiner Homosexualität oder das tragische Attentat auf das Satiremagazin Charlie Hebdo vor einigen Wochen führten spontan zu weit mehr als doppelt so vielen Anfragen als üblich. Eine Situation, in der das gängige Konzept der horizontalen und vertikalen Skalierung - also bessere und mehr Rechner - nicht mehr funktioniert.

Ein solches System funktioniert gut, solange dessen Lastanforderung linear wächst. Man plant es so, dass es zunächst das Doppelte der Normallast aushält. Wenn sich die Lastanforderungen erhöhen, stellt man nach und nach neue Rechner dazu oder baut ältere Maschinen aus, um sie zu ersetzen.

Die Benutzer von ZEIT ONLINE erwarten, dass die Seite gerade bei ungewöhnlichen Nachrichtenlagen verfügbar ist. Dieses Ziel erreichen wir heute nur, weil wir Varnish einsetzen. Varnish ist ein HTTP-Accelerator, der Anfragen via HTTP durch eine in der IT sehr gängige Technik beschleunigt: Caching.

Seit der Version 2.0 ist Varnish bei ZEIT ONLINE im Einsatz. Derzeit ist Version 3 im Betrieb. Im letzten Jahr erschien Version 4. Als ZEIT ONLINE begann, Varnish einzusetzen, war es ein recht junges Projekt von FreeBSD Comitter Poul-Henning Kamp. Entwickelt für die norwegische Zeitung Verdens Gang, um die Auslieferungsgeschwindigkeit des Online-Angebots zu verbessern. Das ist der zweite große Vorteil von Varnish: Das System hält nicht nur mehr Last aus, sondern wird auch schneller.

Das Projekt selbst steht unter der BSD-Lizenz. Es handelt sich also um freie Software. Alle gängigen Linuxdistributionen bieten mittlerweile eine leicht installierbare Version von Varnish über ihre Paketserver.

Varnish ist von außen betrachtet zunächst einmal ein reverse proxy. Das bedeutet, dass er HTTP-Requests entgegennimmt und weiterverteilt. Eine Fähigkeit, die sich Varnish mit etlichen anderen HTTP-Servern teilt, wie zum Beispiel dem weitläufig bekannten Apache.

Genutzt werden reverse proxys gern, um verschiedene Dienste unter einer Domain zu subsummieren. Bei ZEIT ONLINE wird diese Fähigkeit unter anderem für das Freitextblog genutzt. Mit ein bisschen Konfiguration können wir das Blog unter www.zeit.de/freitext verfügbar machen, obwohl es eigentlich auf einem ganz anderen Server mit der Domain blog.zeit.de gehostet wird. Solche Konfigurationen sind Alltag für Systemadministratoren. Sie beschleunigen jedoch nichts.

Screenshot 2015-02-11 21.26.34

Codebeispiel aus der Konfiguration von ZEIT ONLINE. Das Freitext-Blog unter der URL www.zeit.de/freitext.

Genau an diesem Punkt wendet Varnish jedoch einen einfachen Trick an: Es merkt sich für jeden HTTP-Request die Antwort des Backends, also die Antwort des Servers, an den es den Request schickte, und speichert diese mit einem eindeutigen Schlüssel (genannt hash key) in einer Datenstruktur im Hauptspeicher (RAM). Bei einem weiteren Request auf eine so gespeicherte URL wird dann erneut der gleiche Schlüssel erzeugt, aus der Datenstruktur aufgerufen und direkt beantwortet. Die Anfrage wird also nicht mehr an ein Backend weitergeleitet, sondern direkt aus dem RAM bedient. Dies ist ein bemerkenswerter Performancegewinn, da wir davon ausgehen können, dass normalerweise für jeden Request erst eine Antwort berechnet werden muss. Bei ZEIT ONLINE macht dies zwar ein vom eigentlichen CMS getrennter Anwendungsserver, was schnell einige hundert Millisekunden beansprucht. Varnish schafft es in einem Bruchteil der Zeit.

Da im Netz nichts für die Ewigkeit ist, kann die Geschichte hier nicht enden. Sekündlich werden Inhalte erneuert oder veröffentlicht, eine gecachte URL muss also aktualisiert werden können. Hier macht sich Varnish das HTTP-Protokoll zunutze, welches vorsieht, dass eine Response (also das Gegenstück zu einem Request) beispielsweise mit einem Expires-Header angibt, wie lange sie gültig ist. Erlischt diese Gültigkeit, wird sie von Varnish als invalid markiert. Man spricht von einer Invalidierung. Kommt nun ein neuer Request, wird Varnish diesen nicht mehr aus dem Hauptspeicher bedienen, sondern genau das Backend fragen, von dem ursprünglich die passende Response kam. Anschließend wird der Hauptspeicher mit der neuen Response aktualisiert.

Neben der zeitgesteuerten Variante ist es außerdem möglich eine Resource (also zum Beispiel einen Artikel) direkt aus dem Cache zu entfernen. Hier hat sich der Terminus PURGE-Request etabliert, obwohl der HTTP-Standard diese Methode eigentlich nicht vorsieht. Ein PURGE-Request ist ein normaler GET Request mit einem Pragma: no-cache und einem Cache-Control: no-cache Header. Also das, was ein Browser sendet, wenn man einen Shift-Reload macht. Will man nicht, dass jeder Benutzer so den Cache invalidieren kann - da dies schnell die Perfomance des Servers beeinträchtigen könnte - schränkt man diese Requests mit einer IP-Range ein und steuert diese Requests dann zum Beispiel über das CMS.

vcl

Der Varnish Request Flow zeigt die einzelnen Phasen von Request bis Response. Mit der VCL kann man in jede Phase eingreifen.

Für solche Konfigurationen hat Varnish eine eigene Domain Specific Language (DSL), genannt Varnish Configuration Language (VCL). Hier handelt es sich um eine dem C-Dialekt nahe Sprache, die daher für alle, die imperative Programmierung gewohnt sind, leicht lesbar ist. Gegenüber tabellarischen oder XML basierten Konfigurationskonstrukten ist dieser Ansatz auch deutlich intuitiver.

Die VCL bietet zunächst die Möglichkeit, Backends zu definieren. Gibt es für einen Zweck mehrere Backends, zum Beispiel solche, die Bilder ausliefern, können diese mit einem Director in einen Lastverbund genommen werden. Für oben erwähnte IP-Range gibt es die acl Direktive, die access control list.

Die Stärke der VCL liegt jedoch darin, dass man mit ihr innerhalb des oben abgebildeten Zyklus in jede einzelne Phase eingreifen kann, um ein spezielles Backend auszuwählen oder Request und Response zu manipulieren.

Screenshot 2015-02-11 21.38.19

Für das mobile Backend muss ein separater Hash erzeugt werden, damit für Nutzer der Mobilseite und der Desktopseite jeweils unterschiedliche Varianten eines Artikels ausgeliefert werden.

In der Phase vcl_recv steht der reine Request zur Verfügung. Die mobile Weiche von ZEIT ONLINE wird beispielsweise größtenteils in dieser Phase realisiert. Anhand des User-Agent-Header wird ausgewertet, ob der Benutzer die klassische Desktopseite oder eine Mobilansicht bekommt. Natürlich muss für beide Ansichten hier jeweils ein Objekt im Cache existieren und daher benötigen beide Seiten einen eigenen Hash, obwohl sie sich die gleiche URL teilen. Per default erstellt Varnish einen Hash aus URL und Host-Header. In der Phase vcl_hash können wir die Erzeugung dieses Werts manipulieren. In vcl_fetch sind bereits die Antwortheader des Backends da. Hier könnte man nun noch eingreifen und zum Beispiel eine Ablage im Cache (vcl_hit) verhindern - oder einen sogenannten Restart des Requests auslösen, falls die Antwort des Backends nicht die erwartete ist.

flussdiagramm_varnish

Bei ZEIT ONLINE kann das Backend den Request an ein anderes Backend delegieren. Möglich wird dies durch die Restart Anweisung in Varnish.

Die VCL ist ein Schlüsselfeature, da Varnish mit ihrer Hilfe bedienbar wird. In der ZEIT-ONLINE-Technik hat ein Großteil der Entwickler in Backend und Frontend bereits die zentrale VCL unserer Auslieferungsserver bearbeitet und weiterentwickelt. Varnish selbst läuft so zuverlässig und Ressourcen sparend, dass sich die Software mittlerweile zu einem Eckpfeiler in der RESTful basierten Architektur von ZEIT ONLINE entwickelt hat. Eine Bedeutung, die mit dem bevorstehenden Update auf Version 4 sicher weiter ausgebaut wird.

Dies war der erste Teil einer kleinen Serie, in der wir darstellen, warum wir Varnish einsetzen und schätzen. Im nächsten Teil werden wir auf Hilfsprogramme eingehen, die mit Varnish ausgeliefert werden - allen voran das Programm Varnishtest. Ron Drongowski ist Teamleiter Backend bei ZEIT ONLINE.

Kategorien: Entwicklung

Block, Element, Modifier

Von 20. Januar 2015 um 10:26 Uhr

Das Schwierige an CSS ist, dass es so einfach ist. Obschon leicht erlernt, ist es jedoch schwer zu strukturieren und wirkt oft undurchschaubar. Findet man keinen sauberen Weg, seinen Code zu organisieren, wächst die Codemenge oft exponentiell zur Projektlänge an.

In Just Try and Do a Good Job schreibt Chris Coyier, dass er weder Namenskonventionen noch andere spezielle Methodiken nutzt, um sein CSS zu schreiben. Vielmehr versucht er mithilfe seiner Erfahrung und weniger Richtlinien, immer gute Arbeit (a good job) zu machen. Er schränkt dabei ein, dass er hauptsächlich alleine arbeitet und so seinen Stil leicht einhalten kann. Für Teams reicht die Arbeitsanweisung »Do a good job« selten aus. Zumal oft unterschiedliche Vorstellungen davon herrschen, was genau das denn bedeutet, trotz Coding Richtlinien.

Das Entwicklungsteam von ZEIT ONLINE hat hier viele, oft schmerzliche Erfahrungen gesammelt. Zu Zeiten des Relaunch 2009 hatten wir für uns einen CSS-Schreibstil entwickelt, der unseren damaligen Arbeitsumständen sehr entgegen kam und am damaligen state of the art orientiert war. Leider wissen wir heute, dass wir damit CSS gebaut haben, das zwar gut funktioniert, aber sehr schwierig zu warten ist. Die Weiterentwicklung der Seite führt zu immer mehr Code. Da nie ganz klar ist, welcher Code wo noch in Gebrauch ist, ist es gefährlich, eigentlich überflüssigen Code zu entfernen. Der sogenannte code bloat kann die Website-Performance aber schnell verschlechtern. Wir haben natürlich immer wieder an dem Problem gearbeitet, aber die gewünschten Performance-Werte letztlich nie erreichen können – oder auch nur unsere Entwickler besonders entlasten.

Aus diesem Grund haben wir uns für die Einführung der sehr rigiden Namenskonvention BEM entschieden. BEM steht für Block, Element, Modifier, was schon die drei Entitäten beschreibt, in die wir unseren CSS-Code in Zukunft unterteilen. Blöcke sind unabhängige Einheiten in einer Website, die für sich allein stehen können und einen Teil der Nutzeroberfläche repräsentieren. Dies kann beispielsweise ein Logo, ein Suchformular oder ein Menü sein. Blöcke können weitere Blöcke enthalten, was sie von den Elementen unterscheidet. Diese sind für sich allein gestellt nutzlos, funktionieren nur in ihrem Block. Zu guter Letzt gibt es noch Modifikatoren. Das sind zusätzliche Klassen, die an Blöcke oder Elemente geschrieben werden, um unterschiedliche Status abzubilden. Alle Blöcke, Elemente und die Modifikatoren werden durch Klassen repräsentiert, die per Benennung grob ihre Aufgabe und genau ihre Beziehung zueinander ausdrücken. Im Stylesheet wird ausschließlich mit diesen Klassen gearbeitet, alle anderen Selektoren sind quasi verboten.

The one "rule"ish thing I really believe in: keep your selector specificities fairly low and flat across your whole project. — Chris Coyier

Die Namenskonvention mit den doppelten Unterstrichen oder Minuszeichen – die man durchaus nach seinen Vorstellungen ändern kann – und das zweifelsohne hohe Aufkommen an Klassen-Attributen im HTML wirken zunächst etwas ungewöhnlich. Die einzelnen Blöcke werden dadurch voneinander völlig unabhängig. Sie können leicht und sicher editiert werden. Die Spezifität aller Elemente ist auf zwei Stufen festgezurrt, die Kaskade damit außer Kraft gesetzt. Aber gerade das hilft; vor allem in den ganz großen Projekten, in denen nicht mehr jeder jeden Codeblock kennt. Was also zunächst nach zusätzlicher Arbeit aussieht, kommt der Realität der Entwicklung und vor allem der Weiterentwicklung einer Nachrichtenseite sehr entgegen. Ziel ist es letztendlich, Code zu schreiben, der gut und sicher zu modifizieren ist. Diese Anforderung ist durch die vollständige Modularisierung und die flache Hierarchie der Klassen in BEM erfüllt.

Den Aufwand, den der Einsatz einer solchen Namenskonvention mit sich bringt, fangen wir durch Tools wie Sass (siehe auch BEM-Notation) oder grunt zumindest zum Teil wieder ab. In der Automatisierung liegt dann auch die Möglichkeit, den Code laufend zu prüfen und zu messen. Und nur wer misst, kann seine Performance erhöhen.

Nico Brünjes ist Teamleiter Frontend bei ZEIT ONLINE.

Kategorien: Entwicklung