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.

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…

Anika reist…

Während unsere Teams in Hamburg und Berlin gerade arbeitsmäßig die Ohren anlegen, hat meine liebe Kollegin Anika das große Los Sabbatical gezogen und bereist seit ein paar Wochen, Monaten, nein, Ewigkeiten, Australien und Neuseeland. Glücklicherweise verbloggt sie ihre Erlebnisse unter »Anika reist«, so dass ich relativ zeitnah an ihrer Reise teilnehmen kann. Doing the Abel Tasman und Welcome To Paradise haben es mir besonders angetan, aber eigentlich ist der ganze Reisebericht sehr lesenswert, zumindest für mich als Landei, der noch nie in down under oder Neuseeland war.

Neid kommt dabei natürlich gar nicht auf. Das lasse ich mal so stehen. Aber, liebe Anika… Reiseberichte hin oder her, magst Du jetzt bald mal wieder kommen?! 😉

Foto: Unter CC Lizenz von PhillipC.

Immer an der Wand lang

Ich muss mal zwischendurch eine kleine Pause vom Benblogging machen und auf diesen wunderbaren Artikel meines Kollegen Arne Seemann hinweisen. Arne hatte ihn seinerzeit erfolglos beim Offscreen Magazin eingereicht, was ich für eine schreiende Ungerechtigkeit halte. Das Abo, dass wir für’s Büro abgeschlossen haben, können wir gleich wieder kündigen.

While working in the digital realm, everything seems moldable, changeable, inter-changeable. It’s a marvel of constant challenge and a great place to work. But at the same time, the product of our work in the digital is never done. It is released, but it’s never quite finished. There’s always something that can be tweaked, something that can be achieved more elegantly. If not now, then at least in a few weeks worth of time, when technology has changed and the new possbilities have arisen. It’s the challenge of flux.

Arnes Text—und ich mag mir nicht vorstellen, wie lange er daran gefeilt haben mag, allein schon um bestimmte favorisierte Formulierungen darin unter zu bringen—fängt ein Gefühl ein, das ich teile, nur in letzter Zeit zu faul bin, es mir selbst gegenwärtig zu machen. Vielleicht sollte ich mir wirklich mal ab und an einen Whiskey einschänken, das scheint zu helfen. Sláinte!

Präsentationen mit reveal.js

Für meinen letzten Vortrag, habe ich mal Keynote links liegen lassen und mich an reveal.js herangewagt. Im Großen und Ganzen wird damit aus einer Präsentation eine Website. Darin eingeschlossen sind allerdings beinahe alle Funktionen, die man auch von einer Präsentationssoftware kennt, wie Übersichtsmodus, Speakernotes mit Vorschau und Uhr, PDF-Export, Übergangseffekte. Und reveal.js kann auch noch ein paar Dinge, die mein Keynote nicht hinbekommt, beispielsweise einen parallax scrollenden Hintergrund, Markdown-Support oder Themenstacks. Mit slide.es gibt es sogar einen Onlineeditor für den HTML-Unkundigen.

Installation

Die Installation ist in zwei Varianten möglich. Will man nur schnell eine Präse ohne Zusatzfunktionen bauen, kann man dieses Release von reveal.js herunterladen, die enthaltene index.html editieren und diese dann im Browser öffnen. Funktioniert sogar ohne Webserver.

Mehr Möglichkeiten hat man allerdings, wenn man sich die Sourcen von reveal.js per Github auscheckt und die Node-Module installiert. Via grunt serve bekommt man dann einen lokalen Webserver mitgeliefert, der einem einige interessante Zusatzfunktionen, beispielsweise die Speakernotes, zur Verfügung stellt.

Demopräsentation von reveal.js:

Folien anlegen

reveal.js kommt mit einem recht anschaulichen Default-CSS daher (kann man hier in der reveal.js-Demo sehr schön sehen), so dass man im Grunde gleich loslegen kann. Um Folien einzufügen, kann man bspw. die vorhandene index.html öffnen und das nötigr Code-Gerüst herstellen. Minimal sieht das so aus:

<div class="slides">
    <section>
        <!-- content slide 1 -->
    </section>
    <section>
        <section>
            <!-- content slide 2.1 -->
        </section>
        <section>
            <!-- content slide 2.2 -->
        </section>
    </section>
</div>

Eine Folie entspricht also einem section-Element innerhalb des div mit der Klasse slides. Eine der Stärken von reveal.js sieht man hier auch schon: es gibt nicht nur eine Inhaltsebene, sondern zwei. sections die direkte Kinder von slides sind, werden horizontal nebeneinander dargestellt, Kindelemente von sections werden als Stack untereinander dargestellt, das erste ist dabei auf einer Höhe mit den Umliegenden. Nun kann man nicht nur links und rechts, sondern zeitweise auch von oben nach unten durch die Slides gehen. Tipp: mit den Pfeiltasten kann man frei durch die Slides navigieren, will man sich linear durch das Dokument sliden, geht das mit space bzw. SHIFT-space.

So kann man die Slides einzeln anlegen. Wer kein eigenes HTML oder Markdown schreiben will, kann aber auch den Online-Editor http://slid.es/ nutzen, der reveal.js Präsentationen produzieren und auch exportieren kann. Zum ersten Ausprobieren eine durchaus sinnvolle Einrichtung.

HTML und/oder Markdown

Eine Gesetzmäßigkeit kann man für reveal.js festhalten: alles was als Folie angezeigt werden soll, muss in eine section. Hier kann man HTML eintragen wie man möchte. Die wichtigsten Elemente sind in den CSS-Themes bereits brauchbar gelayoutet, also h1h6, p, ul, ol und so fort kann man direkt nutzen.

Ich nutze allerdings auch sehr gerne Markdown. Kann reveal.js natürlich auch, man kann es sozusagen inline eintragen.

<div class="slides">
    <section data-markdown>
        <script type="text/template">
            ## Page title

            A paragraph with some text and a [link](http://hakim.se).
        </script>
        <aside class="notes" data-markdown>
            - talk about page titles
            - anecdote about paragraphs
        </aside>
    </section>
</div>

Wie man hier auch sieht, können Speakernotes mit eingebaut werden, als <aside class="notes">.

Die Frage ist, ob man eine der beiden Optionen eigentlich möchte. Es ist natürlich für einen Webdev das Naheliegendste, seine Slides in HTML zu bauen. Übersichtlich ist das allerdings nicht, jedenfalls nicht während man noch am Inhalt schreibt. Das Inline-Markdown ist gleichsam kompliziert und durch die zusätzlichen <script type="text/template"></script> noch ein wenig mehr bloated.

Die beste Lösung ist also, man packt das Markdown in eine externe Datei. Dies ist letztendlich die beste Option für die Markdownliebhaber, da hier dann der Text aller Folien fein getrennt vom Anzeigesystem in einem Textdokument liegen.

<div class="slides">
    <section data-markdown="example.md"  
        data-separator="^---"  
        data-vertical="^***"  
        data-notes="^Note:"  
        data-charset="utf-8">
    </section>
</div>

Man kann Text zum Trennen der Folien und zum Auszeichnen von Notes angeben. Das passende Markdown würde dann so aussehen:

# Folie 1

Der Text auf Folie 1.

---

# Folie 2

Der Text auf Folie 2.

Note: Notiz auf Folie 2

***

# 1. Unterfolie der 2. Folie

---

# Folie 3

Tipp: Als Trenner zwischen den horizontalen Folien eignet sich meiner Meinung nach die <hr> wesentlich besser, als die standardmäßig verwendeten Zeilenvorschüben. Da man in Markdown --- und *** als Linien benutzen kann, lassen sie sich gut als Trenner nutzen.

Fragmente

Einzelne Elemente können als Fragmente nacheinander innerhalb einer Folie angezeigt werden. Dabei kann die Reihenfolge der Elemente auch noch frei gewählt werden. Eine Liste, bei der zunächst Punkt 2 und dann Punkt 1 angezeigt wird sieht dann so aus:

<ul>
    <li class="fragment" data-fragment-index="2">Appears second</li>
    <li class="fragment" data-fragment-index="1">Appears first</li>
</ul>

oder in Markdown (hier werden spezielle Auszeichungen als Kommentare hinzugefügt):

- Item 1 <!-- .element: class="fragment" data-fragment-index="2" -->
- Item 2 <!-- .element: class="fragment" data-fragment-index="1" -->

Zuätzlich gibt es eine Liste von Effekten, die sich auf die Fragment-Darstellung anwenden lassen, u.a. grow, shrink, roll-in, fade-out usw. Diese werden einfach als Klassenname angefügt:

<ul>
    <li class="fragment roll-in" data-fragment-index="2">Appears second</li>
    <li class="fragment grow" data-fragment-index="1">Appears first</li>
</ul>

Hintergründe und Übergangseffekte

Jede Folie kann ihre eigene Hintergrundfarbe und/oder win Hintergrundbild haben. Dieser werden als data-Attribute an die Slide geschrieben. Den Übergangseffekt für die Folien kann man global festlegen, es besteht aber die Möglichkeit, per Folie diesen Wert zu überschreiben.

Attribute die an eine einzelne Slide festgemacht werden, schreibt man im Markdown so:

<!-- .slide: data-background="#ff0000" data-transition="linear" -->
# Folie 2

Der Text auf Folie 2.

Tastentricks

Zwei Quickwins die reveal.js mitbringt sind noch das leichte Umschalten in den Fullscreenmodus. Während der Präsentation einfach Taste f drücken, schon ist man im Präsentationsmodus des Browsers. Mit der ESC-Taste verlässt man diesen Modus wieder. Ist man nicht im Fullscreen führt die ESC-Taste übrigens in den sogenannten Overviewmodus, mit der man eine Draufsicht auf seine komplette Präsentation bekommt. Eine gute Ansicht um den Zuhörer am Beginn auf die kommenden Themen vorzubereiten, beispielsweise. Hierin kann man wieder navigieren. Den Overviewmodus kann man auch mit der Taste o aktivieren.

Wie schon erwähnt, mit den Pfeiltasten kann man sich durch die Slides navigieren, Space und SHIFT-Space gehen linear vorwärts und rückwärts. Man kann noch weitere Tasten dafür festlegen, standardmäßig machen das noch n für next und p für previous.

Mit den Tasten b oder . wird der Bildschirm schwarz geschaltet, beispielsweise, wenn man in einem anderen Fenster außerhalb der Präse etwas zeigen möchte, oder externen Filminhalt hat o.ä.

Speakernotes

Ich hatte nun schon ein paar Mal die Speakernotes angesprochen. Die werden, jedenfalls, wenn man die Node-Version laufen lässt (mit grunt serve, s.o.), direkt mitgeliefert. Einfach während die Präse im Bild ist, die Taste s drücken, und in einem neuen Browserfenster poppen die ggf. eingetragenen Notizen auf. Dazu gibt es ein Bild der aktuell angezeigten Folie und der darauffolgenden, sowie einen Timer. Alles was man so braucht, um eine professionelle Präse abzuhalten.

Screenshot

Ich hatte bei meinem Vortrag leider mit den Speakernotes ein paar technische Probleme, u.a. mit Links in den Slides bzw. Notizen. Links stellen ein kleines Problem für reveal.js dar, dazu gleich noch mehr, jedenfalls schienen die Notes den Kontakt zur Präse verloren zu haben, beides lief auseinander. So leicht lässt sich das für mich nicht reproduzieren, weil man während einer Präse leicht in Panik gerät, geht mir jedenfalls so. In einer späteren Präsentation beim Holtzbrinck Technology Day 2014 hat es aber problemlos geklappt.

Konfiguration

Über den Konfigurationsabschnitt in der HTML-Datei der Präsentation kann man nochmal weitere Funktionen freischalten und beeinflussen.

Reveal.initialize({
    controls: true, // Navigationspfeile zeigen
    progress: true, // Fortschrittsbalken
    center: true, // Inhalt zentrieren

    theme: Reveal.getQueryHash().theme, // available themes are in /css/theme
    transition: Reveal.getQueryHash().transition || 'default', // default/cube/page/concave/zoom/linear/fade/none

    // Parallax scrolling
    parallaxBackgroundImage: 'img/wood.jpg',
    parallaxBackgroundSize: '2880px 1920px',

Die Liste der Optionen, mit denen man Standardverhalten vorgeben kann ist lang. Vom Anzeigen einzelner Option, Standardwerte für Effekte, Einrichten eines parallaxen Hintergrundbildes oder geänderter Tastenkombinationen ist einiges möglich.

Probleme

Probleme gibt es auch, die betreffen aber eher alle HTML-Präsentationen. Bei eingeschaltetem Fullscreenmodus bekommt man schnell Probleme, wenn man versucht Links innerhalb der Vortragsfolien aufzurufen, was ja erstmal nahe liegt. Wenn man einen Link in einem neuen Tab oder neuem Fenster öffnet, fliegt man aus dem Fullscreenmodus natürlich wieder raus. Das ist zwar an sich noch keine dramatisches Problem, nur sollte man den Umgang damit vielleicht vorher einüben, vor allem in der Situation mit zwei Bildschirmen, bei denen man sich auf die Notizen vor sich konzentriert, erfordert das teilweise etwas Übung (den Shortcut für das Wechseln zwischen zwei Fenstern einer Applikation muss beim Mac auch erstmal an die richtige Stelle legen). Einfacher wird es, wenn man einfach einen komplett anderen Browser hernimmt und alle Links darin sozusagen vorbereitet. Dorthin kann man dann direkt springen, wobei die Präse im Hintergrund im Fullscreen offen bleibt. Das hat mir bisher am besten gefallen.

Und dann noch

Das soll es für einen Einsteigerartikel aber auch gewesen sein. Es soll aber nicht unerwähnt bleiben, dass man sich natürlich® noch eigene Themes für reveal.js anlegen kann, man jede Menge Erweiterungsmöglichkeiten hat, sich per Javascript an alle möglichen Events zu hängen, überhaupt hat reveal.js ein ausgewachsenes API. Es bringt ein Theme für Codebeispiele mit, kann Bild stretchen, man kann prima Videos einbetten, der PDF-Export funktioniert über den Druckendialog. Und über Multiplexing kann man seine Präsentation auch direkt auf den Smartphones und Tablets der Besucher anzeigen. Ich habe jetzt selbst noch nicht alles ausprobiert.

Artikelbild: Bestimmte Rechte vorbehalten von Photogestion