YellowLeds Weblog v2 - Interna

Wie ich arbeite (3): Hardware

nospam@example.com (Matthias Mees) — Thu, 26 Jan 2012 13:28:00 +0100

Zum Abschluss dieser Serie nun also das „obligatorische“ Schreibtischfoto. (Ja, ich habe extra aufgeräumt. Guckt nicht unter den Tisch, die Kabellage ist grausam.)

Desktop-PC

Ein nach meinen (wenigen) Vorgaben vom lokalen PC-Händler meines geringsten Misstrauens zusammengestelltes Modell. Kein Gaming-Monstrum, das ich ohnehin nicht nutzen würde, sondern ein solider Office-Dienstleister, in dessen Kern ein Athlon 64 X2 7750+ (2,7 GHz) auf einem Asus-Board arbeitet. Müsste mal etwas mehr RAM bekommen, fällt mir gerade auf. Dazu gesellen sich:

Monitor: Samsung SyncMaster B2430L, 24 Zoll, 1920×1080 Pixel
Tastatur: Logitech K360
Maus: Logitech M705 Marathon
Headset: Logitech H110
Boxen: ~~JBL (genaues Modell unbekannt)~~ Logitech S220 (nicht im Bild)
Backup: externe iomega USB-Festplatte, 500 GB

Den Monitor habe ich gerade erst angeschafft, weil ich wieder mehr am Desktop-PC arbeiten möchte. Ich bin ganz zufrieden damit, aber noch nicht dazu gekommen, ihn vernünftig zu kalibrieren. Tastatur und Maus sind funkgesteuert, laufen aber über einen Empfänger. Das Headset reicht mir für Skype und Podcasting völlig aus. Die 2.1-Boxen habe ich mal geschenkt bekommen – ich finde sie grottenhässlich und bin deshalb ständig versucht, sie auszutauschen, aber sie klingen recht gut, haben nicht ganz wenig Wumms und ~~einen Ersatz, der mir wirklich gefällt, finde ich irgendwie auch nicht so recht. (Logitech böte sich an, falls jemand eine Empfehlung hat …)~~ wurden heute spontan durch die oben ergänzten Logitech-Boxen ersetzt.

Laptop

Unterwegs oder auf dem Sofa arbeite ich mit einem Lenovo Thinkpad Edge 13 mit AMD Turion II Neo K685 (1,8 GHz), 4 GB RAM, 500 GB Festplatte. Die 1366×768 Pixel des 13-Zoll-Displays reichen unterwegs völlig aus, zudem ist es mit 1,7 kg (inklusive Akku, der je nach Nutzung etwa 3 Stunden hält) angenehm leicht. Soll hier das Headset zum Einsatz kommen, schließe ich es über eine externe USB-Soundkarte (Terratec Aureon Dual) an, da der einzige Haken des ThinkPads eine Kombibuchse (3,5 Zoll, 4-polig) ist, für die es praktisch keine funktionierenden Headsets gibt. Backups am Laptop mache ich über den integrierten Kartenleser auf SDHC-Karten.

Betriebssystem(e)

Auf Laptop und Desktop läuft Ubuntu in der derzeit aktuellen Version 11.10, auf dem Desktop als Dual-Boot-System mit Windows 7 (Ultimate). Ich nutze auf beiden Rechnern unter Ubuntu Unity als Desktop-Umgebung, die wichtigsten Daten werden mittels Unison auf beiden Rechnern regelmäßig synchronisiert.

Wie ich arbeite (2): Webdev

nospam@example.com (Matthias Mees) — Sat, 21 Jan 2012 12:55:00 +0100

Im zweiten Teil der Serie geht es um Werkzeuge, die ich direkt einsetze, um meinen Job zu machen. Ich umschreibe das, was ich tue, gern kurz und knapp mit „HTML, CSS, JS, CMS“. Manche nennen das Webdesign, andere lieber Frontend-Entwicklung. Ich denke, es ist beides, aber nicht jeder versteht beide Begriffe. Gehen wir meine grundlegenden Helfer in diesen vier Bereichen durch.

HTML

Sehr simpel: Basis aller meiner Webprojekte ist das HTML5 Boilerplate. Ich schätze es vor allem wegen seines großartigen build-Skriptes und der Beispiel-.htaccess, aber auch ohne Modernizr als Helfer für progressives Enhancement mag ich kein Projekt mehr angehen. Ich habe ein paar Erweiterungen dazu in einem GitHub-Repository, auf die ich gleich zu sprechen komme.

(S)CSS

Diese Erweiterungen beziehen sich – neben ein paar JS-Helferchen – vor allem auf CSS, welches ich fast ausschließlich über den Präprozessor Sass bzw. als SCSS schreibe. Dabei handelt es sich um Styles, die ich immer wieder benutze, Hilfsstyles für Formulare und Typografie sowie ein paar nette CSS-Tricks, die man immer mal wieder brauchen kann.

Den Einsatz eines CSS-Präprozessors kann ich nur empfehlens, es erleichtert viele Routinearbeiten rund um CSS gewaltig. Welchen man dabei wählt, hängt meines Erachtens nicht wirklich von den Funktionalität ab, da tun sich Sass und seine Konkurrenten nicht viel. Entscheidend für Sass war für mich, dass es für mich einfacher einzurichten und zu betreiben war (was daran liegt, dass es auf Ruby statt auf node.js basiert), zudem integriert es sich angenehm in meinen sonstigen Arbeitsablauf. Ansonsten sind Stylus, LESS & Co. nicht viel anders.

JS bzw. jQuery

So richtig warm geworden bin ich mit JS erst durch jQuery. Ähnlich SCSS macht es JS deutlich einfacher und zugänglicher. Neben kleinen Dingen, die man schnell selbst schreiben kann, ist jQuery vor allem aufgrund der Fülle von verfügbaren Plugins interessant, allerdings kann man nicht oft genug betonen, dass man Plugins erst nach eindringlicher Qualitätskontrolle produktiv einsetzen sollte – wo viele Plugins sind, da ist auch viel Mist.

Eine Liste der Plugins, die zu meinem „Webdev-Armeemesser“ gehören, gibt es in meinem pinboard-Konto. Besonders hervorheben möchte ich Accessible Tabs von Dirk Ginader, ein in jeder Hinsicht beispielhaftes Plugin, und Cycle von Mike Alsup, eines der ausgereiftesten Plugins für Slideshows.

CMS

Abgesehen von meiner Vorliebe für Serendipity als Blogengine hat sich in letzter Zeit eine klare Präferenz bei Redaktionssystemen entwickelt: Ich schätze es, wenn ein System mir so wenig vorgibt wie möglich und sich in erster Linie um seine eigentliche Aufgabe, die Verwaltung von Inhalten, kümmert. Ich möchte nicht erst ein Standardtemplate verbiegen, das mitgelieferte CSS abklemmen und mit einem fest eingebundenen (und damit vorgeschriebenen) JS-Framework arbeiten müssen. Das „ideale“ CMS (das es ohnehin nicht gibt) lässt mir in diesen Bereichen zumindest im Frontend volle Freiheit.

Ich finde, jeder Webentwickler sollte zwei CMS in seinem Werkzeuggürtel haben – je eines für große und kleine Projekte. Für große Projekte gefällt mir MODx Revolution, bei kleinen setze ich auf Perch, ein kostenpflichtiges, aber (auch für Laien) sehr angenehm zu benutzendes System. Beide bestechen durch Flexibilität und die Eigenschaft, weder HTML noch CSS oder JS vorzugeben. Perch lässt sich zudem nachträglich in bestehende statische HTML-Seiten intergrieren, was gerade bei kleinen Projekten oft sehr nützlich ist.

Im nächsten (letzten) Teil dieser Reihe soll es um Hardware und meinen Arbeitsplatz gehen – das kann allerdings ein paar Tage dauern, da kommt dieser Tage neues Spielzeug ins Haus …

Wie ich arbeite (1): Software

nospam@example.com (Matthias Mees) — Tue, 17 Jan 2012 00:10:00 +0100

Thomas hatte neulich™ in einem Kommentar auf G+ angemerkt, es sei ganz schön, „mal zu sehen, wie andere arbeiten”. Das habe ich – zusammen mit einem Eintrag bei Dirk – zum Anlass genommen, eine Artikelreihe darüber zu starten, wie ich arbeite (nachmachen, Herrschaften). Los geht es mit der Software, die ich verwende.

Webwerkzeuge

Folgende Werkzeuge sind für mich unabdingbar, wobei ich später meinem Hauptbrowser und dem Texteditor meines Vertrauens gesonderte Absätze widme:

FileZilla (FTP-Client)
Gimp (Grafikbearbeitung)
git/GitHub (Versionskontrolle)
VirtualBox/ievms (Virtualisierung)

Keine Überraschungen, denke ich. Virtual Box benötige ich, um auf dem Linux-Rechner in virtuellen Maschinen Windows-Umgebungen laufen zu lassen, um Webseiten im IE testen zu können. FileZilla ist der beste grafische FTP-Client unter Linux. git als Versionsverwaltung benutze ich übrigens ausschließlich im Terminal, einen grafischen Client brauche ich nicht, zumal es im Editor (siehe unten) integriert ist. Grafikbearbeitung wird dank der Möglichkeiten mit CSS3 zusehends weniger wichtig – ich kann mich mitunter gar nicht erinnern, wann ich Gimp zuletzt benutzt habe, andere Programme wie Inkscape brauche ich maximal noch zur Formatkonvertierung.

Browser: Chrome

Ich habe auf dem Linux-Laptop auch noch einen Firefox installiert, arbeite aber fast ausschließlich in Chrome. Zu sehr habe ich mich trotz einiger Wiedrigkeiten im Zusammenhang mit Javascript an Chrome, speziell dessen Web Inspector als Entwicklungswerkzeug (ich gestalte Webseiten tatsächlich im Browser, ohne vorher grafische Entwürfe im Grafikprogramm zu erstellen), gewöhnt. Als (für Webkram relevante) Erweiterungen nutze ich:

Bildschirmerfassung (Screenshots)
Palette (Farbpaletten aus Grafiken)
Pendule (Entwicklerwerkzeuge)
YSlow (Performance-Tests)

Texteditor: Sublime Text 2

Jetzt erklären mich die Hardliner unter den Linux-Nutzern für bekloppt – ein lizenzpflichtiger Texteditor? Es gibt doch emacs, vi(m) & Co.? Richtig, ebenso wie gedit, Bluefish und viele weitere. Dennoch habe ich mich – auf den 2. oder 3. Blick – in Sublime Text 2 verliebt und beschlossen, die Lizenzgebühr zu investieren. Der Grund ist denkbar simpel: Sublime macht vieles „out of the box“ richtig bzw. so, wie man (ich) es erwartet. Kein langes Einrichten über Konfigurationsdateien in kruder Syntax – die wenigen Anpassungen, die ich vorgenommen habe, sind:

minimale Anpassung des Syntax-Highlightings
Schriftgröße
das Soda-Theme als „eye candy“

Fast alles, was ich mir wünsche, macht Sublime ab Werk besser, intuitiver, logischer als jeder andere Texteditor, den ich länger als 10 Minuten benutzt habe. Selbst die (Webwork-spezifischen) Erweiterungen, die ich installiert habe, halten sich sehr in Grenzen:

Git (git-Integration)
HTML5 (Highlighting und Snippets für HTML5)
jQuery Snippets pack (leider sehr schlicht)
jsFormat (JS „un-minifizieren“)
SCSS (Highlighting und Snippets für Sass)

Das alles läuft auf einem Ubuntu-System (derzeit 11.04) mit Unity-Desktop; natürlich läuft auf diesem Rechner auch ein lokaler Webserver (Apache 2) mit PHP und MySQL-Datenbank. Einen genaueren Einblick, welche „Bausteine“ und Vorlagen ich für HTML, CSS und JS verwende, gibt es im nächsten Teil der Reihe.

Nach dem Test ist vor dem Test

nospam@example.com (Matthias Mees) — Sat, 19 Feb 2011 08:50:00 +0100

Ich habe ein paar Tage intensiven Testens mit dem Mobile Speed Test hinter mir (nochmal danke an Marc für den Hinweis), in denen ich „nebenbei“ auch noch dem (übrigens sehr netten) Support von Blaze die Erkenntnis verschafft habe, dass sie durch einen Fehler in der Serverkonfiguration einen ganzen Batzen IP-Adressen ausgesperrt hatten. Was tut man nicht alles.

Das Ergebnis sind ein – für den Moment – deutlich abgespecktes Template und ein paar sehr nette (deutlich verbesserte) Messwerte, jeweils ermittelt aus drei Testläufen auf der Einzelansicht des ersten Eintrages:

Ladezeit iPhone (iOS 4.2.1): 6.07 Sekunden
Ladezeit Android (Froyo): 5.16 Sekunden

Das sind natürlich nur Messwerte der Ladezeiten der Seitenkomponenten – daher wäre es spitze, wenn der eine oder andere nochmals in den Kommentaren rückmelden könnte, ob sich auch praktisch die Performance verbessert hat.

Bitte gebt jeweils Endgerät/System/Browser mit an und testet insbesondere die Reaktion des Kommentarformulares (subjektiv; es muss niemand die Stoppuhr rauskramen). Danke!

Was habe ich rausgeworfen?

Für den Moment habe ich die Komponenten komplett entfernt, bei denen relativ wahrscheinlich schien, dass sie den Seitenaufbau massiv verzögern:

CSS3-Anweisungen, die potenziell das Rendering ausbremsen (danke für den Hinweis an Thomas)
nur auf den kleinen Displays: Webfonts
diverse jQuery-Spielereien wie etwa die Tabs im Kommentarbereich
einige der Social Media-Buttons (um HTTP-Requests zu sparen)

Ich habe vor, diese Dinge (zumindest teilweise und für die Desktop-Ansicht im Idealfall ganz) nach und nach wieder einzupflegen, der Einfachheit halber läuft das Blog aber jetzt eine Weile komplett „auf Diät“, bis abgeklärt ist, was genau die Trägeheit und das zähe Laden verursacht.

Nachtrag: Die Bestandteile des CSS, welche ich als relativ unwahrscheinliche Performance-Killer einstufen würde, sind jetzt bereits wieder integriert, werden allerdings nur für Auflösungen größer als 700 Pixel angewandt. Es wäre so gesehen hochinteressant, wenn noch jemand etwas zur Performance auf dem iPad sagen könnte …

Mobile Performance-Probleme

nospam@example.com (Matthias Mees) — Wed, 16 Feb 2011 03:43:00 +0100

Die Performance-Probleme dieses Blogs in Android-Smartphones und dem iPhone sind offensichtlich komplizierter einzugrenzen als erwartet, speziell da ich selbst kein entsprechendes Gerät zur Verfügung habe. Ich danke nochmals allen Testern.

Ich habe mittlerweile einige Tests über den Mobile Speed Test von Blaze laufen lassen, bin mir aber immer noch nicht ganz sicher, wo es konkret hakt. Fest steht: Irgendetwas™ bremst den Lade- und/oder Renderingvorgang der Seite massiv aus, und zwar:

im Mobile Safari deutlich mehr als auf Androiden
auf Artikelseiten deutlich mehr als auf der Startseite

In Desktop-Browsern ist davon – meiner Wahrnehmung und der von YSlow nach – nichts zu bemerken. Ich nutze darüber hinaus hier nahezu denselben „Unterbau“ wie auf meiner gewerblichen Seite, welche auf mobilen Geräten problemlos läuft.

Das grenzt meiner Einschätzung nach die Quelle des Performance-Problems auf die folgenden Kandidaten ein:

CSS-Anweisungen, speziell CSS3-Tricks wie Transforms, Schatten und :before/:after
die jQuery-Bibliothek (hier: Version 1.5, „drüben“ noch 1.4.3)
jQuery-Plugins und Ergänzungen von mir; allerdings wurde das Blog-Template bereits komplett ohne jQuery getestet – ohne signifikante Verbesserung

Falls noch jemandem etwas ein- oder auffällt: Immer raus damit. Ich teste weiter, bis eine Lösung gefunden ist.