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

 

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.

Lang lebe Charlie Countryman

charliecountryman

Am Sterbebett seiner Mutter, erscheint Charlie die Verstorbene und schickt ihn auf eine Reise nach Bukarest. Auf dem Weg dorthin erscheint ihm wiederum sein verstorbener Sitznachbar im Flugzeug und bittet ihn, seiner Tochter ein Geschenk zu überreichen. Charlie findet die Tochter und verliebt sich, aber…

Laut Wikipedia hat Shia LaBeouf für den Drogenrausch den er dort zu spielen hat, tatsächlich LSD genommen, was man durchaus auch dem Zuschauer empfehlen könnte, da man so Film, Story und Setting vielleicht einigermaßen verstehen könnte. Der Hauptteil des Films scheint aus zugedröhnten Herumrennen in der Balkangroßstadt zu bestehen, während der restlichen Zeit gibt es von Mads Mikkelsen auf das Gesicht. Einziges Highlight für Filmenthuisiasten ist wohl einen um Jahrzehnte gealterten Ron Weasley dabei zu sehen, was passiert wenn man eine Überdosis Viagra dreimal hintereinander einnimmt. Ob Rupert Grint für diese Szene auch wirklich Potenzmittel genommen hat, ist allerdings nicht überliefert. Egal: was durch dieses Methodacting von LeBeouf und Grint aufgebaut wird, reisst Til Schweiger in der nächsten Szene mit dem Arsch wieder ein. Am Ende fragt man sich noch kurz, warum der deutsche Titel „Lang lebe Charlie Countryman“ das Gegenteil des Originaltitels „The Necessary Death of Charlie Countryman“ bedeutet. Und wer am Set noch alles LSD genommen hat.

Einen Stern gibt es für den Soundtrack (Moby).

Zuerst veröffentlicht bei Letterboxd.

Das Steinbach-Problem

Sascha Lobo erklärt auf Facebook, warum Erika Steinbachs Raissistentweet rassistisch ist und Erika Steinbach als Rassistin entlarvt.

Wenn gemäß der Weisheit von Forrest Gumps Mutter (“Dumm ist, wer Dummes tut”) derjenige Rassist ist, der sich rassistisch äußert – dann ist Erika Steinbach Rassistin. Steinbach Rassistin.

Viel ist dem eigentlich nicht hinzuzufügen, außer vielleicht, dass meines Erachtens viel zu oft beim Blick auf einen Politiker oder eine Politikerin auf eine Einzelperson geschaut wird und der dahinterstehende Apparatus, also das jeweilige Büro, der Verband und natürlich auch die Partei selbst aus dem Auge verloren wird. Welche Leute arbeiten mit Steinbach und kriegen die jedesmal einen Herzinfarkt, wenn sie einen ihrer gefürchteten Tweets absetzt, oder führen sie ihr Fotos zu, die man auch in rechtsextremen Foren wiederfinden kann? Und was ist die CDU für eine Partei, die derlei Entgleisungen duldet.

Aber am Ende haben wir das wieder alles falsch verstanden, meint jedenfalls Erika Steinbach, das Bild stamme von einem besorgtem Familienvater aus Frankfurt/Main und sei kein aggressives Foto, als wenn es darum gegangen wäre. Erika Steinbach postet also nicht nur rassistische Bilder, sondern bedient auch der gleichen Entschuldigungs- und Verschleierungstaktiken, wie Pegida und AFD (und alle anderen rechtsextremen Parteien/Gebilde/Politker zuvor).

In diesen Zusammenhang passt Carolin Ehmkes Frage, was man eigentlich noch alles sagen darf, ohne als rechts zu gelten:

Wir sind nicht rechts. Wir zünden halt nur Häuser von Flüchtlingen an. Wie viele Sätze, Aussagen, Reden, wie viele Handlungen sind eigentlich nötig, damit etwas als rechts gelten kann? Wo „Ich bin kein Rassist“ draufsteht, ist eben allzu oft leider doch ein Rassist darin.

Bleibt die Frage nach der Konsequenz. Was passiert denn nun eigentlich mit Erika Steinbach, wo wir wissen, dass sie eine Rassistin ist?

Teaserbild: Tobias Koch, CC BY-SA 3.0 de