Joel Test Score: 10/12

Bei der Kandidatensuche für unsere Frontendentwicklerstellen bin ich auf stackoverflow.com auf eine exzessive Nutzung des alten Joel Tests gestossen. Lustig das. Lustig, dass das noch immer in Benutzung ist, der zugehörige Artikel ist von 2000. Und ein Zeichen von Beständigkeit, denn auch 16 Jahre später, können wir die Qualität einer Arbeitsumgebung in der Softwareentwicklung noch in Joelscore messen. Ist scheinbar nichts hinzugekommen, vielmehr sind immer noch nicht alle Punkte standardmäßig erfüllt.

Wenn ich die eigene Arbeitsumgebung so betrachte, die ich derzeit wieder wie faulen Fisch zum Teilen anbiete, dann fehlen mir auch noch zwei Punkte zur vollen Punktzahl. Außerdem unterscheiden sich die Arbeitsbedingungen im Hamburger Verlagshaus (gemeinsames Entwicklerbüro, das sog. dev-o-drome) ggü. dem Berliner Newsroom, wo unsere Entwicklerkollegen mit im Großraumbüro sitzen.

Die Ergebnisse im einzelnen:

  1. Do you use source control?
    Natürlich. Wir nutzen git und github.
  2. Can you make a build in one step?
    Ja, jeder Entwickler kann aus unserer Entwicklungsumgebung heraus sowohl releasen, als auch nach Produktion deployen.
  3. Do you make daily builds?
    Klar. Und mehr, soviel man will. Mit jedem pull request läuft unser Jenkins los und builded und testet…
  4. Do you have a bug database?
    Ja, wir sammeln Bugs auf einem eigenen Board in Jira.
  5. Do you fix bugs before writing new code?
    Nein, nicht immer. Wir verfolgen durchaus etwas, was man als zero-bug-policy bezeichnen kann, aber es muss auch nicht immer jeder visuelle Glitch am morgen behoben werden, oder anders: it depends.
  6. Do you have an up-to-date schedule?
    Ja, natürlich.
  7. Do you have a spec?
    Ja, auch wenn wir heute nicht mehr nach dem Wasserfallprinzip von der Spec abarbeiten, sondern in Userstories denken, sind unsere Aufgaben dadurch doch gut definiert und niemand muss einfach so los coden.
  8. Do programmers have quiet working conditions?
    Im Grunde ja. An beiden Standorten sich die Entwickler in ihre Umgebung eingebunden und ansprechbar, aber es gibt auch immer die Möglichkeit sich zurück zu ziehen und in Ruhe irgendwo zu arbeiten. Kommt allerdings gar nicht so oft vor, wie man denkt. Na gut, der Kicker ist manchmal ein wenig laut.
  9. Do you use the best tools money can buy?
    Ja. Natürlich gibt es einen finanziellen Rahmen, aber dieses schöpfen wir zu unserem Wohle auch aus, das bezieht sich sowohl auf die zur Verfügung gestellten Rechner, als auch die dazugehörige Software und die Services, die wir nutzen.
  10. Do you have testers?
    Nein, haben wir in diesem Sinne nicht. Unsere (testdrivenArbeit wird getestet, von Menschen, aber nicht unbedingt von Leuten, deren Beruf und dauerhafte Aufgabe eben dies ist.
  11. Do new candidates write code during their interview?
    Wir machen eine Bewerbungsrunden (die zweite von drei Möglichen), bei der der Bewerber eine vorher gestellte Aufgabe vorführen und vor allem vorstellen muss/darf/kann.

Webentwickler (m/w) mit Schwerpunkt Frontend (Hamburg)

Webentwickler (m/w) mit Schwerpunkt Frontend (Berlin)

Webentwickler (m/w) mit Schwerpunkt Backend

Code review ohne Furcht und Tadel

Wir halten, in unserem Workflow gekoppelt an den pull request bei github, für praktisch allen Code, der in die Entwicklung eingehen soll, sogenannte peer code reviews ab, d.h. ein Mitglied des Teams begutachtet zusammen mit dem jeweiligen Autoren seinen Code. Zusammen kontrollieren sie einerseits die Plausibilität des Codes, andererseits aber auch den Codingstyle, Codesauberkeit und maintainablity. Mithilfe dieses Vier-Augen-Prinzips soll unsere gesamte Codebasis auch auf lange Sicht einen hohen Qualitätsstandard halten, gut pflegbar bleiben. Als wichtigster Aspekt: Autor und Reviewer sollen voneinander lernen, einerseits, wie die anderen Teammitglieder ihren Code schreiben, aber auch über das jeweilige Feature, das gerade geschrieben wurde. Auf lange Sicht soll sich so eine gemeinsame Auffassung wie Code zu schreiben ist im Team verfestigen, zusätzlich wird neuen Teammitgliedern der Einstieg erleichtert.

 

Collective code ownership und die persönliche Kreativität

Unser Code gehört uns allen, aber gleichzeitig ist jeder Pull request als Beitrag und geistige Erweiterung dieser Codebasis zu respektieren. Meist gibt es kein richtig oder falsch, sondern nur Geschmäcker, oft ist es aber auch umgekehrt. Wir haben für viel oft strittige Themen gemeinsame Vorgaben erarbeitet. Jenseits davon hat natürlich jeder Coder seinen eigenen Stil. Diese Stile zu vereinen, die Herangehensweise des Anderen zu achten und zu respektieren und im Gegenzug, nicht in die Defensive zu geraten, sich nicht von Änderungsvorschlägen angegriffen fühlen, ist die große Schwierigkeit und gleichermaßen Pflichtübung eines code review.

Codeautor und Reviewer müssen jeweils über ihren Schatten springen und sich in der Mitte treffen. Dafür sollen beide aus dem Review herauskommen, mit dem guten Gefühl, etwas gelernt zu haben, etwas beigetragen zu haben, etwas geleistet zu haben. Das ist weit weniger esoterisch, als es klingt.

Das Review

Hier einige einfache Regeln und Hinweise, wie ein gutes Review ablaufen kann. Zunächst sollten sich beide Teilnehmer Zeit für die Sache nehmen. Der Autor hat sich schon vor dem pull request vom ordnungsgemäßen Zustand seines Codes überzeugt:

  • er hat seine Commits klein und inhaltlich zusammenhängend gestaltet und gute commit messages geschrieben,
  • kommentiert wo es nötig erschien,
  • Todos und auskommentierte Codezeilen aufgeräumt,
  • nochmal überprüft, ob die Guidelines eingehalten wurden
  • und die Variablen- und Klassennamen noch Sinn ergeben,
  • sowie überflüssigen Code gelöscht.

Der Reviewer braucht zunächst natürlich etwas Zeit, sich in den Code einzulesen, es empfiehlt sich, zunächst das ganze diff zu lesen, am Ende vielleicht noch die korrespondierende Story, Bug o.ä. heranzuziehen, um inhaltliche Aussagen machen zu können.

Beide Parteien sollten sich ausreichend Zeit nehmen (und bekommen) und eine möglichst entspannter Arbeitsatmosphäre herstellen (Kaffee?). In der ersten Phase wird der Reviewer Rückfragen zu solchen Stellen im Code stellen, die er nicht versteht (kommt bestimmt nur selten vor). Dann wird er wahrscheinlich verschiedene Änderungsvorschläge machen (wenn das nötig erscheint). Reviewer und Autor sollten in dieser Phase gemeinsam diskutieren/kommunizieren. Das ist über line comments in github möglich (und dort dann vorteilshaft auch dokumentiert), geht aber im gemeinsamen Gespräch viel besser, ggf. auch per Skype oder Slack/Screenhero. Für Änderungsvorschläge ist es auf jeden Fall sinnvoll, dieser zunächst als Kommentar zu formulieren und nicht direkt den Code anzupassen. Auch das Hin- und herreichen von diffs und patches kann sinnvoll sein.

Wonach suchen wir?

Kein Code ist perfekt. Selbst beim kleinsten hello world kann man über die Schreibweise streiten. Schreibt man mehr als ein paar Zeilen, schleichen sich auch immer Bugs ein. Oberste Priorität eines Review ist, diese Bugs zu finden. Erst in zweiter Linie geht es darum, durch Erhöhung der Codequalität die Wartbarkeit des Codes auf lange Sicht zu erhalten. Konkret suchen wir:

  • Potentielle Fehler: off-by-one, Schleifen ohne Abbruchbedingung, error handling, Antipattern, scope
  • Browserkompatibilität: Läuft der Code auf allen angesteuerten Browsern und deren Versionen?
  • Plausibilität: macht der Code was er soll, was angefordert wurde und was beschrieben ist?
  • Effizienz: Arbeitet der Code effizient, speicherschonend, schnell? Möglichst wenige reflows und repaints, DOM-Zugriffe minimiert/optimiert, keine Leaks?
  • Codeduplizierung: einmal Code kopieren ist noch vertretbar, beim dritten Auftreten gleichen Codes sollte refactored werden
  • Tests: Für jedes neue Feature sollte es mindestens einen Test geben. Wird das Richtige getestet?
  • Naming things: ist immer eine schwierige Sache, aber machen allenVariablennamen oder Klassennamen Sinn? Entsprechen sie den geltenden Konventionen (bspw. BEM)?
  • Coding Guidelines: Überall eingehalten?
  • Codesauberkeit

Grundregeln zur Herangehensweise

  • Reihenfolge für die Diskussion: zuerst Stellen die nicht verstanden wurden, dann Dinge die möglicherweise nicht funktionieren, dann erst Codingstyle und Codesauberkeit
  • erst kommunizieren, dann machen
  • tauchen beim Reviewer Fragen auf und er versteht Codestellen nicht, sind sie wahrscheinlich auch für andere in der Zukunft schwer zu verstehen
  • schlägt der Reviewer eine Änderung vor und es ist kein Grund zu finden, diese nicht zu übernehmen, dann sollte man sie höchstwahrscheinlich übernehmen
  • nicht vergessen, dass man etwas lernen möchte: der Reviewer vom Autoren und der Autor vom Reviewer
  • immer alles erklären

Um jeden Preis?

Nein. Wir wollen den besten Code, aber man sollte auch Kompromisse machen können. Der eigene Codingstyle ist niemals das nonplusultra und der des anderen niemals die Wurzel allen Übels. Wenn man schon sehr lange über bspw. inhaltliche Punkte diskutiert hat, darf man an anderer Stelle auch mal etwas weniger streng sein, solange alles funktioniert. An dieser Schnittstellen zwischen time to deliver und code quality delivered ist tatsächlich ein wenig Spielraum, den man ruhig ausnutzen sollte.

Safari SVG Sprite Bug fixed

Der Safari SVG Sprite Bug, der mich nun ein paar Wochen verfolgt hat, ist gefixt. Schnell nach bekannt werden des Bugs hatte sich Antti Koivisto der Sache angenommen und einen Fix gebaut, der in den aktuellen Updates von iOS (9.3.2) und Safari für OS X 9.1.1 (11601.6.17) landete, beide Updates sind seit Montag erhältlich. Besucht man mit leerem Cache nun eine Seite mit SVG-Sprite, wird dieses gecached und nicht so oft geladen, wie Icons aus dem Sprite auf der Seite verwendet werden.

safari-svg-sprite-bug-fixed

Notlösung zurückbauen

Es wird wahrscheinlich noch ein wenig dauern, bis wir unsere Notlösung zumindest teilweise wieder zurückbauen können, je nachdem wie schnell sich der Fix verbreitet, da die Seiten aber trotz Bug ja grundsätzlich funktionsfähig bleiben, wird man damit nicht allzu lange warten brauchen. Da wir doch einen sehr fehleranfälligen und komplizierten Herstellungsprozess für die SVG-Sprites hatten, bin ich mir sicher, das wir exakt diesen nicht wieder implementieren werden.

Hektisches Geteste führt zu nüscht…

Gestern habe ich versucht, nach der Rückkehr aus dem Urlaub, mal schnell die Updates zu ziehen und zwischen zwei Terminen den Fix, der mir schon von verschiedenen zugetweetet worden war und die ich schon retweetet hatte.

Um es kurz zu machen, Safari verhält sich beim sogenannten hard reloaden (Tastenkombi CMD-SHIFT-R) immer noch anders als vielleicht Chrome oder Firefox, und lädt in diesem Fall das Sprite mehrmals herunter, aber im Grunde ist das nur richtig, by the word Reload page without cache, also es wird tatsächlich nichts gecached. Das hatte mich ehrlich gesagt zunächst etwas durcheinandergebracht.

Und die Moral von der Geschichte

Ich habe ein paar Dinge gelernt, bei der Sache:

  • Find’s Du einen Bug, brauchst Du einen Testcase… ich hatte im Laufe der Zeit mehrere, einigermaßen brauchbar ist wohl erst der Aktuellste gewesen
  • Hast Du einen Testcase, lass ihn von vielen testen (hat super funktioniert
  • Willst Du einen Bug in Safari gefixt haben, mach Dir nicht die Mühe bei Apple direkt zu fragen, sondern geh ins Webkit-Bugboard
  • Ist ein Bug im Bugboard, einfach mal nachfragen, wann er denn gefixt wird
  • Wenn dann der Fix da ist, Zeit nehmen, ihn zu testen
  • Zeit nutzen um alternative Ansätze zu entwickeln

SVG, yeah you know me

Update: Der hier besprochene Bug wurde inzwischen gefixt.

Oder eher I know you. Über den meiner Meinung nach vorliegenden Safari SVG Sprite Bug hatte ich ja schon berichtet. Kurz zusammengefasst: neuere (mobile) Safari laden ein SVG-Sprite jedesmal komplett runter, wenn ein SVG-Icon daraus angezeigt wird. Das konnten beim ersten Aufruf ohne gefülltem Cache bei der Homepage von zeit.de schon mal bis zu 17MB sein. Um es kurz zu machen, die Welt interessiert sich nicht dafür, weder Apple, die den Safari baut, und auch nicht die Autoren von svg4everybody, die die SVG-Sprite-Technik populär gemacht haben (unter Webentwicklern).

Update: Martin Wolf hat den Screencast zum Bug gedreht.

Lösungssuche

Also mussten wir anderweitig handeln und die Sprites ersetzen. Wenn man nun einmal SVG eingeführt hat, will man nicht wieder zurück auf Pixelbilder umsteigen. Ich habe also lange recherchiert, nach Techniken gesucht, versucht das Problem irgendwie wegzubekommen, allerdings ohne Erfolg. Eine Idee war, und die halte ich durchaus für valide, die SVG per XHR in die Seite zu laden. Für uns sprachen jedoch zwei entscheidende Dinge dagegen:

  • progressive enhancement: es gibt in dem Sinne keine wirkliche Basis, von der die AJAX-Lösung enhancen könnte, ausser vielleicht man schreibt einen Text anstelle des SVG und lädt an dieser Stelle dann die Grafik hinein. Grafik und Text nehmen aber nur selten den gleichen Raum ein, ein fürchterliches Geruckel und Gezucke wäre vorprogrammiert, überall dort, wo der Text größer als die Grafik wäre
  • unsere großen und komplizierten Logos: die Signets der ZEIT, des ZEIT MAGAZIN und so fort sind auch nach vielen Optimierungen immer noch sehr große SVG-Dateien mit vielen Knotenpunkten, gerade diese sollten aber immer vorhanden sein, dürfen also nicht durch Text ersetzt und per XHR nachgeladen werden. D.h. für die Logos musste sowieso eine andere Lösung gefunden werden (die noch verbleibenden Icons sind dann schon fast unerheblich klein).

Für die Logos war schnell klar, dass wir diese oldschool in das HTML einbetten müssen, so wie es auch bspw. Github mit seinen Icons macht. Am Ende haben wir uns entschieden, es mit allen Icons so zu machen: wir betten sie ins HTML ein.

<svg xmlns="http://www.w3.org/2000/svg" width="17" height="15" viewBox="0 0 17 15" class="svg-symbol" preserveAspectRatio="xMinYMin meet" role="img" aria-label="Leserempfehlung">
    <path d="M8.5 11.454L3.322 15l1.983-5.73L.12 5.73l6.405.004L8.5 0l1.975 5.734 6.404-.005-5.185 3.54L13.678 15"></path>
</svg>

Nach- und Vorteile

Das birgt tatsächlich ein paar Nachteile, vor allem weil die Grafiken damit zu Textcontent werden, zumindest aus Sicht des Cachings, es wird also nahezu nicht gecached. Das SVG-Sprite, dass nun wegfällt hingegen wurde natürlich auf ewig gespeichert. So wiegt die Seite nur beim initialen Laden weniger als vorher. Das ist leider weitestgehend ungelöst, auch wenn ich die Hoffnung habe, dass sich die SVG wenigstens sehr gut gzippen. Es bleibt aber eine lästige Abhängigkeit, die man eigentlich nicht haben will. Ohne Zweifel ist der Gewinn für Nutzer des mobile Safari allerdings grandios.

Die Lösung bringt aber auch Vorteile. Zunächst mal können wir uns nun eine Sonderlösung für cross-domain-Seiten einsparen und haben eine Menge polyfills abgeschafft, da das inlinen von SVG eine hervorragende Browserunterstützung genießt. Unser Grunt-Workflow hat sich dadurch auch deutlich verschlankt, weil wir bspw. keine Fallback-Bilder im PNG-Format mehr produzieren. Für das Einlesen der SVG habe ich einen Jinja-Helper geschrieben, der die Daten von der Platte holt (und das Ergebnis wegcached), und noch ein paar Änderungen am Code vornimmt, die wir sonst im Grunt mit svgstore gemacht haben (bspw. fill-Attribute wegstrippen). Außerdem kann man beim Aufruf das Füllen der ARIA-Attribute beeinflussen, damit in Situationen, in denen das Icon direkt neben einem erklärenden Text steht, kein doppeltes Vorlesen passiert:

<a href="#leserempfehlung">
<svg xmlns="http://www.w3.org/2000/svg" width="17" height="15" viewBox="0 0 17 15" class="svg-symbol" preserveAspectRatio="xMinYMin meet" role="img" aria-hidden="true">
    <path d="M8.5 11.454L3.322 15l1.983-5.73L.12 5.73l6.405.004L8.5 0l1.975 5.734 6.404-.005-5.185 3.54L13.678 15"></path>
</svg>
Leserempfehlung
</a>

Zumindest wurde so der Prozess auf Entwicklerseite stark vereinfacht. Und ein paar nodige Abhängigkeiten entfernt.

Geschmäckle

Was bleibt ist die Frage, warum das Problem eigentlich niemanden so richtig interessiert. Zunächst mal nehme ich inzwischen an, dass wir als Hochlastwebsite mit Massencontent zu den Paradiesvögeln gehören, wenn wir moderne Techniken des Web einsetzen. Die Verbreitung einer Lösung wie SVG-Sprites und da kann Chris Coyier noch auf sovielen Konferenzen dafür Werbung machen, scheint vergleichsweise gering, jedenfalls auf Seiten, die vielleicht mehr als ein oder zwei Icons pro Seite haben. Und dann interessiert es die Betreiber der Seiten, die das nun doch nutzen vielleicht auch nicht richtig, wieviel Megabytes für iPhone-Nutzer durch den Äther gejagt werden. Vielleicht monitoren sie das auch nicht so. Der Kunde merkt es vielleicht auch nur, wenn die sogenannte Flatrate schon Mitte des Monats leergesaugt ist. Apples Verhältnis zu Safari scheint sowieso ein Gebrochenes zu sein, was sich widerum im Verhältnis von Safari zu aktuellen Webtechnologien zeigt, da wird sogar zurückgebaut! Und schlussendlich muss ich auch zugeben, wahrscheinlich haben wir es mit unserem Sprite von der Größe her ein wenig übertrieben, zumindest hat das dem Bug vorschub geleistet.

Safari SVG Sprite Bug?

Update: Der hier besprochene Bug wurde inzwischen gefixt.

Ich hatte es schon getweetet, aber es liegt mir doch sehr auf der Seele, deswegen nochmal ausführlich hier…

Vor ein paar Tagen haben unsere Backend-Kollegen einen starken Anstieg an Downloads einer bestimmte Datei unserer Website festgestellt, nämlich jener SVG-Datei, in der unsere SVG-Sprites abgelegt sind. Die Datei wurde mit einem Male so exorbitant oft heruntergeladen, dass es in den Logs auffiel. Zunächst gingen wir natürlich von einem Fehler unsererseits aus, auffällig war allerdings von Anfang an, dass nur Safaribrowser (Desktop, vor allem aber Mobile) ab Version 9 die vielen Downloads verursachten.

Meiner Meinung nach haben wir es mit einem Bug in Safari zu tun. Und seit nun schon ein paar Tagen bin ich auf der Suche nach diesem Bug. Ich habe einen Testcase gebaut (um Knnfigurations- und Serverfehler zu vermeiden auf einem anderen Server), mit dem man das Problem nachvollziehen kann. Und nachdem ich nach langer langer Recherche sprichwörtlich nichts darüber im Netz finden konnte, habe ich einen Bug bei Apple eingetütet und ein Issue bei svg4everybody erstellt, dort wird die betroffene Technik ausgiebig genutzt, die sollten sich dafür interessieren. Bisher gab es keine Reaktionen.

svguse

Was ist denn das Problem?

Wir nutzen eine externe SVG-Spritemap. Darin befinden sich alle Icons und Logos, und braucht man ein Icon, wird es auf diese Weise in den Code eingebunden:

<svg class="svg-symbol logo_bar__brand-logo" role="img" aria-labelledby="title">
    <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="icons.svg#svg-logo-zon-black"></use>
</svg>

Das geht natürlich nur in modernen Browsern, deswegen nutzen wir svg4everybody um das ganze für ältere Browser zu polyfillen, was aber keinen Einfluss auf den Bug hat. Auf einer Artikelseite mit Kommentaren, können so bis zu 30 Icons auf einer Seite auftauchen. In Chrome, Firefox und anderen wird das Sprite genau einmal geladen pro Seitenaufruf und dann natürlich gecached. In Safaris > 9 (unter iOS 9.3.1 oder auf dem Desktop 9.1.1) wird die SVG-Datei einmal pro angezeigtem Icon heruntergeladen, was ein sehr hohes Datenaufkommen verursachen kann (siehe oben). Uns fällt sowas in den Logs auf, Nutzer von mobile Safari spüren es womöglich auf ihrer Telefonrechnung.

Was bedeutet das?

Einfach gesagt: das Netz ist sowas von kaputt… man braucht keine leftpadding-Funktion via npm einzubauen, um eine Website kaputt zu machen. Allein schon ein Browserupdate kann einen in Teufels Küche bringen. Kann natürlich immer noch sein, dass der Fehler bei mir liegt (und ja, die Datei ist viel zu groß, da kann man ansetzen), vielleicht findet ja einer meiner Leser etwas… Mich beschleicht aber auch irgendwie das Gefühl, dass Apple SVG nicht so richtig im Safari haben will.

Für uns bedeutet das letztlich, dass wir unsere Art der SVG-Einbindung nochmal komplett überarbeiten müssen, wir wollen ja nicht noch mehr Daten ausliefern, als wir sowieso schon tun…

Update: Martin Wolf hat den Screencast zum Bug gedreht.

Fronteers Spring 2016

Talkshow

 

Jedesmal wenn ich auf einer Fronteers Conference war: hintendran diese Lobhudelei. Kann ich mir aber auch in diesem Jahr nicht verkneifen, auch und besonders im Vergleich mit meiner letztjährigen Konferenzpleite (ich nenne sie liebevoll the event that should not be named). Also liebe jungen Webentwicklerkollegen, die noch nie auf einer Fronteerskonferenz waren (gibt’s die?), fangt sofort an euren Chef zu löchern und bucht euch eine, z.B. im Oktober, da kann man nichts falsch machen.

Konferenzfrühlingsgefühle

Die Frühlingsausgabe in diesem Jahr stand unter dem inhaltlichen Thema »Performance« und dem Motto Frühling. Und während der englisch-pessimistische Host Phil Hawksworth eher Regenschirme verteilt hätte, gab es als einziges Konferenzgimmick in diesem Jahr eine Fronteers-Sonnenbrille, die Organisatoren wussten warum.

Das Format

Das Format der Springconference war IMHO schon experimentell, aber zum allergrößten Teil auch gelungen. In drei Themenblöcken gab es drei Talks zu jeweils 20 Minuten und danach eine gemeinsame Talkrunde mit den Sprecherinnen und Sprechern. Hier wurden dann auch die per Twitter aus dem Publikum gestellten Fragen eingebaut.

Dazwischen blieb viel Platz fürs coffiedrinke und kommunikatie maken im wunderbaren futuristischen Veranstaltungsort EYE.

EYE von oben

Mein einziger Kritikpunkt hier sind vielleicht die 20-Minuten-Talks, bei denen die Sprecher öfter zum Schnellsprechen und Foliendurchwinken tendierten, anstatt sich thematisch zu konzentrieren und einzuschränken. Aber das hatte im Grunde nur Auswirkungen auf meine geliebten conference notes, inhaltlich war alles top.

Das Thema performt

Der Tag war eingeteilt in drei Unterbereiche:

  • Visual Performance, hier ging es um das Gefühl von Schnelligkeit auf Webseiten, Zeit und Geschwindigkeit an sich und wie man all dies für seine Seite einsetzt, um dem Nutzer ein flüssiges Nutzungsgefühl zu vermitteln, das vielleicht gar nicht immer das schnellste ist;
  • Accessible Performance, hier wurde gezeigt, dass man bei allem Herausholen von Millisekunden, die Zugänglichkeit der Seite nicht aus dem Blick verlieren darf, und das eben diese Zugänglichkeit auch ein Performancewert ist;
  • Technical Performance, hier ging es nun darum, wie man technisch am besten und sichersten eine guter performende Website hinbekommt.

Abgeschlossen wurde der Tag dann mit einer Keynote, in der Kristian Sköld vermittelte, wie man die Arbeit an der Performance von Webseiten innerhalb des Unternehmens oder beim Kunden bewirbt und sich Sponsoren für den Kampf um Millisekunden sucht. Den Tag über war eben genau diese Frage, wie üblich gemischt mit etwas Unmut, in mir aufgekommen: wer soll das eigentlich alles bezahlen?! Die perfekte inhaltliche Klammer also.

Wie man eine schlechte Webentwicklerkonferenz erkennt

Das Jahr ist vorbei, die meisten meiner Kollegen und Arbeitsbekanntschaften haben in diesem Jahr mindestens eine tolle Konferenz besucht. Ich nicht. Es gab eine ganze Reihe von Gründen, meist terminlicher Natur, warum ich dieses Jahr auf keiner der coolen Konferenzen war, dass ich mir stattdessen einen mittelschweren Reinfall gegönnt habe ist allerdings ganz klar meine eigene Schuld.

Um wenigstens irgendetwas für die Community mit nach Hause zu nehmen, gibt es hier nun meinen Leitfaden: „Eine schlechte Webentwickleronferenz 1) erkennen“. Nicht alle Dinge erkennt man schon vor der Anmeldung, leider, aber wenn ihr auf einer Konferenz gelandet seid, die euch komisch vorkommt, mit diesem Leitfaden könnt ihr entscheiden, ob man die zwei oder drei Tage nicht doch etwas besseres machen kann, als sich zu ärgern.

  1. Die Website der Konferenz passt in Gestaltung und Ausführung nicht zum Thema, bspw. ist nicht responsiv, obwohl es auf der Konferenz um responsive webdesign gehen soll, lädt wie eine Herde Schildkröten, obwohl es um Performance geht, oder wirft 200 Javascriptfehler, obwohl Javascriptdevelopment und -testing zu den Hauptthemen gehören.
  2. Die Website wird nicht gepflegt, bspw. eine Woche oder einen Tag, oder während der ganzen Konferenz ist noch der call for papers online oder auch kurz vor Konferenzbeginn stehen noch nicht alle Sprecherinnen im Programm, das natürlich von tba oder n.n. nur so wimmelt.
  3. Die Website gibt keine Auskunft über den oder die Hauptsponsoren der Konferenz.
  4. Die Konferenz findet unter dem Label einer internationalen Organisation statt (bspw. W3C, Khan Academy, XYZ Foundation), aber von dieser Organsiation stehen kaum Sprecher auf dem Programm. Oder nur von der Organisation. Auch doof.
  5. Es ist die erste whatsoever Konferenz in Deutschland.
  6. Die Konferenz wird organisiert von einer Firma, schwerwiegender: einer Firma mit der Buchstabenkombination EDV im Namen.
  7. Die Konferenz findet parallel zu einer anderen Konferenz statt. (Habe ich auch schon in gut erlebt, hier vielleicht drauf achten, ob auch das Thema der Parallelkonferenz interessiert und vor allem, ob die Zeiten der Talks oder die Räumlichkeiten den Besuch beider Veranstaltungen erlauben).
  8. Im Konferenznamen taucht die Abkürzung DACH auf (schlimmer ist nur noch EMEIA).
  9. Die Konferenz findet in einem Hotel statt.
  10. Im Vorlauf zur Konferenz bekommst Du mehrere Informationsmail von genauso vielen unterschiedlichen Leuten, es gibt keinen Verantwortlichen, nur PR-Praktikantinnen.
  11. Die letzte Mail vor der Konferenz bekommst Du gleich vier- oder fünfmal, sie enthält noch Wordanmerkungen („hier ruhig mehrerem schreiben“) und am Schluss kommt eine Entschuldigungsmail von jemanden, dessen Mailprogramm sich „schon in den Feierabend verabschiedet“ hat.
  12. Am Konferenzort angekommen gibt es keinerlei visuelle Hinweise auf die Konferenz, der überkandidelte Concierge des Hotels weiss von keiner Konferenz, auf einem Bildschirm am Empfang läuft aber ein Zeitlupenband mit den Räumen für die derzeit 30 im Haus stattfindenden Veranstaltungen. Nach 5 Minuten Wartezeit weisst Du, wo Du hinmusst.
  13. Bei der Anmeldung gibt es eine Jutetasche mit einem Schreibblock und viel Werbung und einem Katzenkalender (auch Werbung).
  14. Das Schlüsselband an dem dein Konferenzkärtchen hängt kratzt auf der Haut.
  15. Der Raum für die 200 erwarteten Teilnehmer fasst höchsten 50 Leute. Es kommen nur 30.
  16. Die Tracks der Parallelkonferenz dauern 60 Minuten, die der eigenen Konferenz 45 min., siehe Punkt 7.
  17. Der Hauptsponsor der Konferenz hat den ewig offen gehaltenen call for papers ernst genommen und gestaltet den kompletten ersten Tag, nahezu völlig wertfrei natürlich.
  18. Der Hauptsponsor der Konferenz ist Microsoft.
  19. Alle Vortragenden am ersten Tag haben übrigens früher hauptsächlich dotnet gemacht. Und C#. Alle anderen haben Java gemacht.
  20. Es gibt einen Vortrag über Accessibility, und die ist übrigens ganz leicht, man muss nur überall wai-aria dranschreiben, wer hätte es gedacht.
  21. Internet Explorer 11 und Edge sind die neuen Sterne am Himmel der Webentwicklung. Hört man.
  22. Es spricht eine Frau auf der Konferenz.
  23. Es spricht eine Frau auf der Konferenz.
  24. Angular ist die Zukunft.
  25. Also Angular, nicht Angular 2, das ist ja noch Alpha.

1) Es geht hier ausdrücklich um Konferenzen für Webentwickler, kann sein, dass es sich bei Konferenzen für Lehrer, Physiker oder Bäckerlehrlinge komplett anders verhält. Muss aber nicht.

Nö.

Nö, Felix.

Es ist ja nachgerade höchsterstaunlich, wie man jemanden in (zumindest gespielte) Aufregung versetzen kann, in dem man ihm mit aller gebotenen Knappheit vor Augen führt, dass er Quark redet. In diesem Fall entsprang die Knappheit der Aussage zwar eher den äußeren Umständen: Zugfahrt, Edge, keine Zeit gleich per Artikel zu antworten, keinen Bock auf Disques-Kommentare (und mobil funktionieren die auch nur bei LTE glaube ich), also Twitter, aber auf 140 Zeichen kann ich das auch nicht erklären, Ende. Ich hätte auch schreiben können: „Ey Felix alter Bartträger, ich hab gerade keine Zeit zu antworten, schau doch nochmal genau nach.“ Und Felix hätte mich fragen können: „Hey Nico, ich schätze Deine Arbeit und ZEIT ONLINE, ich hab hier aber etwas entdeckt, und bevor ich das jetzt in die Welt hinausposaune und es am Ende gar nicht stimmt…“, aber hey, wir sind Blogger, oder nicht?!

So, und nun nochmal für alle zum mitschreiben: obwohl das Gerücht geht, dass wir Verlagsleute total bekloppt und degenerierte Volldeppen sind, sind wir doch nicht so blöd, so etwas wie einen nativen Adblocker in unsere Seite zu bauen. Überraschung. Stattdessen haben wir uns sehr lange und ausgiebig Gedanken machen und viele viele viele Zeilen Code schreiben müssen, um zwei komplett konträre Systeme: eine moderne responsive Website und völlig antike pixelgebundene Bannerwerbung so miteinander zu verbinden, dass es für Werbekunden und Nutzer gleichermaßen funktioniert.

Was also in Wahrheit passiert ist, dass auf ZEIT ONLINE je nach Gerät, Browser- oder Bildschirmgröße die passenden Ads geladen werden und zwar zum Zeitpunkt des Ladens. Verändert man die Fenstergröße, werden diese geladenen Ads mitunter ausgeblendet, damit sie nicht das sich an die Umgebung anpassende Design zerstören. Damit sind sie natürlich keinesfalls geblockt. Inzwischen könnten wir an diesen Stellen passende Ads on the fly nachladen, aber darauf haben wir erstmal verzichtet, weil wir es tatsächlich nicht für den häufigsten Anwendungsfall halten, das Leute ihr Fenster auf und zu machen.

Das alles sind natürlich nur Kompromisse. Leider gibt es noch so gut wie keine responsiven Ads auf dem deutschen Markt, eher nur zwei Formen, desktop und mobile. Und ebenso schlimm ist, dass es so viel aussen liegende Werbung gibt (Walppaper, Fireplace), die die Maximalbreite einer Seite plump einschränken. Und dann ist das alles natürlich auch noch fehleranfällig, es konnten nicht alle Werbeplätze eins zu eins übernommen werden und und und. Allerdings sind uns die Kollegen von der werbeschaltenden Zunft auch schon ein paar Schritte entgegen gekommen, bspw. durch endlich nicht mehr blockende Ads: es kommt also erst der Content, dann die Werbung. Das schon angesprochene Nachladen von Ads ermöglicht uns endlich wieder bedienbare Bildergalerien.

TL;DR: Wer also Werbung auf ZEIT ONLINE nicht sehen will, der kann nach jedem Seitenload schnell die Größe seines Browserfensters ändern und währenddessen solange wonaders hinschauen. Blocken tut er damit aber nichts, ausser vielleicht den eigenen Lesegenuss…

Post-Launch-Depression

Die Post-Launch-Depression (PLD) ist eine unter Webentwicklern bekannte psychotraumatische Erfahrung, die den Entwickler gerne in jenem Moment kurzer Unaufmerksamkeit von hinten anfällt, wenn er gerade eben das Produkt, an dem man viele Monate gearbeitet hat, in die Freiheit entlässt. Schwierigkeiten bei diesem Ereignis, wenn also das Baby nicht so richtig ans Licht der Welt will und sich lieber im Server zu verkriechen sucht, bereiten für die PLD das Terrain besonders gut vor. In diesen Momenten ist der Entwickler besonders angreifbar.

Symptome der PLD sind unter anderem eine geistige Abkopplung des Entwicklers von seinem Produkt. Es gehört ja nun auch nicht mehr ihm (und seiner Gilde) alleine, viel mehr muss er es nun mit der breiten und mithin undankbaren Masse von Nutzern teilen, die sich allesamt allerhöchstens für das Aussehen interessieren, oder das auch alle Knöpfchen schön pling pling machen und am allermeisten eigentlich dafür, dass zwar alles neu und modern sein soll, dem Grunde nach sich aber nichts verändern soll. In einem Jahr Entwicklungszeit hat der Entwickler derart viele Wasch-mir-den-Pelz-aber-mach-mich-nicht-nass-Situation erlebt, dass er der Bipolarität der Nutzermasse nur höchst gleichgültig gegenüber steht, was dann schon eine Ausdruck der PLD ist, denn er hat ja ein Jahr oder länger für die Nutzer gekämpft. Hunderttausend Details bleiben aber natürlich immer nur Details und die werden dort draussen selten betrachtet. Aber auch schon die Formulierung „dort draussen“ deutet auf eine schwere PLD hin. In einer recht aufwendigen Differentialdiagnose muss die PLD übrigens gegen andere in dieser Phase auftretenden Entwicklerkrankheiten wie der akuten Unlust, dem Teamstockholmsyndrom und dem *designerium homicerium“—der Lust Designer zu ermorden—abgegrenzt werden. Ein Zusammentreffen von PLD und Teamstockholmsyndrom ist übrigens keinesfalls unüblich, ganze Teams oder Abteilungen sind schon so der PLD zum Opfer geworden. Hier ist äußerste Vorsicht geboten und die Erkrankten sind in eine strenge Quarantäne—auch bekannt als Überstundenausgleich—zu nehmen.

Was hilft jedoch gegen die PLD? Wenn sie erst mal eingetreten ist leider nicht mehr so viel. Dann hilft nur warten, den Entwickler mit neuen Projekten (aber nichts Wichtiges bitte, die Gefahr des Scheiterns ist in dieser Phase hochprozentig) zu zuschütten und vor allem Alkohol. Am besten feiert man den geglückten Launch zwischen vier und sechs Mal und achte dabei darauf, die Entwickler ordentlich mit Bier und Champus abzufüllen. Danach sollte das PLD nach ca. vier bis sechs Wochen langsam abklingen. Ebenfalls als hilfreich haben sich agile Entwicklungsmethoden erwiesen. Der moderne agile Prozess an sich kennt ja keinen Launch, allenfalls den permanenten. Wenn sie es schaffen, am Tag nachdem ihre Website endlich online gegangen ist, so zu tun als wäre nichts passiert—einfach ganz normal ein daily machen—dann bemerkt Entwickler frühestens in der nächsten Review, dass sich irgendetwas verändert hat. Wenn dann die Retro geschickt um zwei, drei Wochen verschleppt wird, ist der Entwickler schon wieder viel zu sehr mit anderen Dingen beschäftigt, um der PLD anheim zu fallen.

Wer killt hier eigentlich wen?

Performance, performance, performance. Als Webentwickler mit Verantwortungsbewusstsein reisst man sich ja seit Jahren den Arsch auf, um hier und da noch ein paar Bytes einzusparen, die Requests zu reduzieren, die Downloads zu beschleunigen und wenn alles nichts hilft, das Rendering so zu optimieren, dass wenigstens die gefühlte Geschwindigkeit stimmt. Ich habe kiloweise Artikel dazu gelesen, Vorträge gesehen, verlinkt, selbst gehalten, wie alle meine Kollegen. Und das alles stecken wir in die tägliche Entwicklung, reviewen uns gegenseitig und treten gegenüber Designern, PO und Stakeholdern permanent als die Warner und Mahner auf, Bedenkenträger by profession, alles um am Ende ein paar Millisekunden Speed herauszuholen.

Eigentlich können wir uns das aber auch schenken. Vergessen. Unsere Lebenszeit besser einsetzen. Denn es bringt alles nichts. Ist nutzlos, vergebene Liebesmüh. Auf die Idee könnte man zumindest kommen.

Denn wenn die möglicherweise hochperformante Website dann live ist, wird sie zugeballert von eine ganzen Phalanx von Trackingskripten, Werbeeinbindungen und Bannerwerbungen, die alle das Erstladerecht für sich beanspruchen und gefühlt von Leuten programmiert werden, die wahlweise keine Ahnung haben oder auf Performance täglich ihre Notdurft verrichten, einfach nur so, weil sie es können. Lese ich auch beim Guardian, Ad tech is killing the online experience, dessen Website natürlich ebenso mit Werbung zugekleistert ist:

[R]eally it’s not the website’s fault, since to a very large degree the owner of the website you’re visiting doesn’t actually control what you see, when you see it, how you see it, or even whether you see it. Instead, there are dozens of links in the advertising-technology chain, and every single one of them is optimising for financial value, rather than low-bandwidth user experience.

Da ist viel dran: denn neben dem Betreiber weiss natürlich auch der Techniker einer Website nicht, was werbemäßig passiert. Ist eine Website erstmal vermarktet, gibt es dort Bereiche, auf die deren Betreiber nur in sehr kleinem Maße noch Einfluss hat. So ist die Technik. Aber auch der Betreiber des Adservers von dem die Werbung eingespielt wird, zuckt regelmäßig mit den Schultern. Denn dort sind schon lange keine echten Ads mehr eingebucht, sondern wieder nur Links und Weiterleitungen zu anderen Adservern, Agenturservern, irgendwelchen Servern, die zumeist auch selbst wieder irgendwohin weiterleiten. Und jeder bringt noch schnell seinen eigenen Tracker mit. Deswegen kann man beispielsweise gar nicht sagen: wir haben drei/vier/fünf Tracker auf der Seite, da man nicht wissen kann, was noch dazu kommt, je nach ausgespielter Werbung. Nochmal der Guardian:

Web-based articles, these days, are increasingly an exercise in pain and frustration. In many ways, the experience of reading such things is worse today than it was in the early days of dial-up internet. Because at least back then web pages were designed with dial-up users in mind. […] Today, by contrast, everything is built for a world where everybody has a high-bandwidth supercomputer in their pocket.

Obwohl wir natürlich alle tatsächlich einen Supercomputer in Hosentasche mit uns herum tragen. Ein iPhone6 beispielsweise ist heute genauso leistungsstark, wie ein 11 Zoll MacBook Air von vor ein paar Jahren. Nur, warum funktionieren Webseiten dann darauf nicht besser? Bei The Verge hat man dafür die Hersteller von mobilen Browsern als Schuldigen ausgemacht, The mobile web sucks:

But man, the web browsers on phones are terrible. They are an abomination of bad user experience, poor performance, and overall disdain for the open web that kicked off the modern tech revolution.

Wobei lustig ist, dass die Website von The Verge nicht gerade eine Performance aus dem Bilderbuch abliefert. Auf der Seite meldet Ghostery 26 (!) Tracker, sie zu laden hat bei mir eben lange acht Sekunden gedauert. Am Desktoprechner wohlgemerkt. Wie alle werbefinanzierten Seiten eben.

And yes, most commercial web pages are overstuffed with extremely complex ad tech, but it’s a two-sided argument: we should expect browser vendors to look at the state of the web and push their browsers to perform better, just as we should expect web developers to look at browser performance and trim the fat. But right now, the conversation appears to be going in just one direction.

Hervorhebung von mir. Naja. Ob das so stimmt? Also zumindest im Falle Apple muss man sich schon fragen, warum es mit der Entwicklung des Safaris nicht so richtig voran geht, ob vielleicht sogar die Aussagen zutirfft Safari is the new IE.

They never send anyone to web conferences, their Surfin’ Safari blog is a shadow of its former self, and nobody knows what the next version of Safari will contain until that year’s WWDC. In a sense, Apple is like Santa Claus, descending yearly to give us some much-anticipated presents, with no forewarning about which of our wishes he’ll grant this year. And frankly, the presents have been getting smaller and smaller lately.

Auffällig allerdings, dass Apple zuletzt sowohl ein Adblocking für iOS9 ankündigte, als auch den Start einer eigenen Newsapp. Für letztere stellen sie sogar Journalisten ein. In die gleiche Kerbe schlägt Facebook mit seinen Instant Articles, auch wenn diese immer noch nicht in ernstzunehmender Zahl stattgefunden haben. Fakt ist: Apple und Facebook wollen in Zukunft immer mehr Newskonsumenten in ihre walled gardens locken.

Ich will ja nicht schon wieder The End Of The World As We Know It verkünden, mache mir aber doch Sorgen, ob es nun mit dem Umbruch weg von adfinanzierten Modellen zu noch in den Sternen stehenden Finanzierungsmöglichkeiten nicht etwas schnell geht. Zumal da doch noch einiges drin wäre, würde sich nur mal jemand bewegen. Die Webwerbebranche müsste sich gehörig ändern, um Strukturen zu entwickeln, die in dieser Gemengelage konkurrenzfähig wären. Ist ja nicht so, dass man an den völlig veralteten Bannereinbindungen nicht noch viel an Performance raus zu holen ist. An responsive webdesign will ich dabei noch gar nicht denken, obwohl das natürlich auch Pflicht wäre. Ein kleines Beispiel gefällig?

Gleichzeitig muss man natürlich immer und immer wieder die Frage nach den Alternativen stellen. Denn, angenommen, man will seine werbefinanzierte Website weiterbetreiben, was sollten man denn verkaufen, wenn es mit Werbung nicht geht und mit Bezahlschranken nicht klappt? Ja, was?