YellowLeds Weblog v2 - Webstandards

Advent, Advent

nospam@example.com (Matthias Mees) — Fri, 23 Dec 2011 08:33:00 +0100

Es ist wieder soweit: Am 1. Dezember öffnet sich wieder das erste Türchen des Webkrauts-Adventskalenders mit 24 spannenden Artikeln rund um Webentwicklung und Webstandards.

Ich bin mir sicher, dass wir erneut eine sehr interessante Mischung an Themen zusammengetragen haben. Auf meinen Beitrag müsst Ihr noch ein bißchen warten, laut aktueller Planung ist mein Thema (das ich natürlich noch nicht verrate) erst einen Tag vor Heiligabend dran.

Nachtrag

Mittlerweile sind beide Artikel des Adventskalenders 2011, die ich (mit-) verfasst habe, veröffentlich:

Außerdem im Dezember erschienen: Ausgabe 12/11 des Webstandards-Magazins mit meinem Artikel .htaccess: Feuerwasser für den Apachen.

Für (mehr) konstruktive Kritik im Web

nospam@example.com (Matthias Mees) — Wed, 27 Apr 2011 14:05:00 +0200

Disclaimer: Ich nehme mich selbst von dem hier beschriebenen Verhalten nicht aus. Ich beziehe mich hier nicht auf konkrete Fälle, sondern auf Beobachtungen über einen längeren Zeitraum aus verschiedenen Quellen.

Mir fällt schon seit geraumer Zeit immer wieder eine meines Erachtens wenig erstrebenswerte, wenig sinnvolle und wenig zielführende Einstellung unter Webworkern (aber auch Webnutzern) auf: Eine eindeutige Vorliebe für destruktive Kritik. Wir entwickeln und pflegen ein Bild der „im Web lebenden und arbeitenden“ Menschen, welches man als „Angry Nerds“ bezeichnen könnte – eine Einstellung, die kommuniziert: „Dieses ist meine Meinung zu einem Thema, sie ist die einzig richtige. Wer anderer Meinung ist, hat keine Ahnung.“ Man findet sie überall – in Blogartikeln, Kommentaren, Tweets und Podcasts, auf Mailinglisten und in Webforen.

Woher dieser allgemeine Unmut?

Ich bin mir unschlüssig, woher diese Einstellung genau kommt. Möglich, dass es daran liegt, dass es im Grunde (Stichwort: Browser) unser Job ist, die Fehler anderer zu kaschieren, und dass wir gerade in diesem Bereich lernen mussten, dass nicht jeder Kritik postwendend annimmt und umsetzt. Vielleicht ist es auch einfach Teil der Kultur technischer Berufe, maximale Intoleranz Fehlern gegenüber „cool“ zu finden. Eventuell ist es gar einfach nur die Reflexion einer generell meckernden Gesellschaft innerhalb einer bestimmten Gruppe.

Selbstverständlich müssen Fehler angesprochen werden, natürlich soll Kritik erlaubt sein – darum geht es mir nicht. Ich glaube lediglich, dass sowohl die Annahme der Kritik als auch die Wahrnehmung dessen, der sie äußert, deutlich positiver ausfällt, wenn sie konstruktiv, freundlich und gelassen geäußert wird. Nebenbei ist das auch viel besser für den eigenen Blutdruck, ganz zu schweigen von der berüchtigten „Online-Reputation“. Aber ganz fernab von der eigenen Selbstdarstellung (und damit -vermarktung) im Web bremst destruktive Kritik auch die eigene Arbeit aus.

Machen statt meckern

Sich über schlecht gemachte Webseiten oder nicht funktionierende Software, über Kollegen oder Kunden aufzuregen ist verschwendete Zeit und Energie. Der bloße Vorwurf: „Das ist schlecht gemacht.“ wird in den meisten Fällen ohnehin nicht die gewünschte Reaktion nach sich ziehen – eher im Gegenteil. So menschlich es ist, angesichts schlecht gemachter Arbeit einen gewissen Unmut zu verspüren, so wenig bringt es praktisch, ihn lautstark zu äußern. Wenn überhaupt (das darf in Einzelfällen durchaus bezweifelt werden), dann erreicht man über konstruktive Kritik eine Veränderung.

Ich habe die Theorie, dass in jedem vernünftigen Webworker ein Lehrer steckt. Wir sind es gewöhnt, unser Wissen aus (Blog-)Artikeln zu beziehen, weil diese Form für unseren Fachbereich um ein Vielfaches effizienter und geeigneter ist als klassische Formen der Vermittlung von Wissen; deshalb geben wir es in dieser Form auch gerne weiter. Ein Lehrer aber, der seinem Schüler sagt: „Das wird so aber nichts, Du bleibst sicherlich sitzen.“ ist ein ausgesprochen schlechter Lehrer. Ein guter Lehrer wird stets versuchen, selbst den vermeintlich hoffnungslosen Schülern zu helfen, den richtigen Lösungsweg zu finden.

Was wir brauchen sind weniger in die Höhe gereckte Nasen, die herabblicken, und mehr Kommunikation auf Augenhöhe; weniger „Du kannst ja gar nichts!“ und mehr „Warum machst Du das nicht so?“; weniger „Gammelcode!“ und mehr „Da hat mal jemand einen richtig guten Job gemacht!“ Immer im Hinterkopf behalten: Die Basis des Webs war und ist Kollaboration, die nur in Form konstruktiven Teamworks funktionieren kann.

HTML5 Boilerplate: Das build-Skript

nospam@example.com (Matthias Mees) — Wed, 23 Mar 2011 11:42:00 +0100

Das HTML5 Boilerplate ist ein sensationelles Projekt. Es liefert Webworkern einen hervorragenden Ausgangspunkt für HMTL5-Seiten – grundlegendes Markup, Basis-Stylesheet inklusive Reset, hilfreiche Javascripts, Beispieldateien zur Server-Konfiguration. Alles da, gepaart mit den „best practices“ in diesen Bereichen.

Wer sich das Boilerplate zum ersten Mal ansieht, wird sich vermutlich auf das Markup oder das CSS stürzen, eventuell auch auf die .htaccess – was vollkommen legitim ist. Die entsprechenden Dateien sind voll interessanter, gut dokumentierter Hinweise zu modernen Frontend-Techniken. Aber der meines Erachtens größte Vorteil, der Teil des Boilerplates, der mich persönlich endgültig überzeugt hat, es künftig zu benutzen (statt eines eigenen Kickstart-Templates), ist das build-Skript.

build-was?

Im Verzeichnis build einer lokalen Kopie des Boilerplates liegen neben ein paar nützlichen Java-Programmen (z.B. der YUI Compressor) ein Shell-Skript und eine XML-Datei (welche man unter Linux, OSX oder Windows benutzen kann, wobei unter Windows deutlich mehr Arbeit zur Einrichtung nötig ist). Diese machen das Arbeiten mit dem Boilerplate unglaublich bequem.

createproject.sh sorgt dafür, dass man nicht für jedes Projekt eine frische Kopie des Boilerplates herunterladen muss – es erzeugt eine Arbeitskopie der benötigten Dateien in einem separaten Verzeichnis. Aus diesen erzeugt dann das Apache-Tool ant mit Hilfe der build.xml die „finalen“ Versionen der Dateien, welche man dann auf den Server überträgt.

If you build it, they will come

Welche das genau sein sollen, lässt sich über die Datei project.properties (im Verzeichnis build/config/ der Arbeitskopie) fein steuern, genauer gesagt muss diese Datei für jedes Projekt individuell angepasst werden, wenn man zusätzliche Dateien und/oder Verzeichnisse verwendet, damit der build-Prozess korrekt funktioniert. In eher seltenen Fällen können auch Änderungen an der build.xml notwendig sein.

ant build macht erheblich mehr als „nur“ die Dateien zusammenzustellen, welche schließlich auf den Server wandern: Javascript und CSS wird kombiniert, minifiziert und versioniert, Grafikdateien optimiert, HTML von Kommentaren und unnötigen Bausteinen befreit und noch Einiges mehr. (Die im Boilerplate enthaltenen Teile, welche man nicht verwenden möchte – wie etwa Google Analytics – muss man aber dennoch nach wie vor manuell entfernen.)

Das spart mit wenigen Shell-Kommandos derart viel Kleinarbeit, die man sonst von Hand machen würde, dass es wirklich keinen Grund gibt, noch ein eigenes Grundgerüst für eine Webseite in HTML5 zu pflegen – alles, was man eventuell hinzufügen möchte (Markup, Stylesheets, Javascript, Webfonts usw.) kann ja problemlos und mit vergleichsweise geringem Aufwand in den build-Vorgang integriert werden.