Boilerplates und Frameworks

Es ist gerade eine tolle Zeit für Webentwickler. Überall sprießen Frameworks und Boilerplates für jedes erdenkliche Einsatzgebiet aus dem Boden. Man muss eigentlich nur noch zugreifen und sich die gewünschten Sachen zusammenklicken. Eigentlich eine schöne Sache, aber irgendwie auch doch wieder nicht.

Boilerplates

Das HTML5 Boilerplate hat den großen Anfang gemacht und bietet eine super Anlaufstelle für die Best-Practices, wenn ich eine neue Webseite beginne. Problematisch ist, dass das Standardtemplate in vielen Fällen aber einfach "blind" übernommen wird. Getreu dem Motto: "Super, da hat ja jemand schon die ganze Arbeit für mich erledigt." Statt sich mit den vorhanden Features auseinanderzusetzen, finden sich teilweise Anweisungen um das Boilerplate wieder zu überschreiben. Das ist knapp am Ziel vorbeigeschossen.

Die Entwickler hinter dem Boilerplate, allen voran Paul Irish, haben als Intention die Best Practices zu vereinen und muntern dazu auf, auch mal länger auf der Entfernen-Taste zu bleiben. Ich bevorzuge hier allerdings den anderen Weg: Die Dinge, die ich brauche rausziehen und in ein wesentlich einfacheres Boilerplate überführen (mein persönliches basiert auf dem von Harry Roberts alias csswizardry).

Twitter's Bootstrap ist ein Boilerplate für gesamte Webapps und ist dementsprechend umfangreich. Ein Blick in den Code lohnt sich auf jeden Fall, insbesondre auch was CSS und JS betrifft.

Frameworks

Frameworks werden idealerweise so eingesetzt wie sie kommen. Kein rumfuhrwerken, höchstens außenrum bauen. Einfach nur, um sich die Option offen zu halten, später auf eine neue Version es Frameworks umzugraben. Ich verwende beispielsweise jQuery als grundlegendes Framework für so ziemlich alle JavaScript-Geschichten. Würde ich anfangen direkt in jQuery Dinge zu ändern, wäre ich beim nächsten Release, das vielleicht fatale Bugs behebt, aufgeschmissen.

Zugegeben: jQuery ist da ein eher schlechtes Beispiel, weil es sehr ausgereift ist. Templating Frameworks eigenen sich besser als Beispiel (unabhängig davon, ob sie überhaupt sinnvoll sind): Es gibt ein paar große Frameworks und dutzende Micro-Frameworks, die meist nur einen kleinen Anwendungsfall abdecken. Der typische Ablauf sieht dann so aus: Man suche sich ein so kleines Framework, das ungefähr passt und baut das erstmal ein. Gerne kommen dann auf einmal Fälle, in den sich das Framework einen Ticken anders verhalten soll. Der schnellste Lösungsweg führt viele dann doch dazu, das Framework so aufzubohren, dass es den eigenen Vorstellungen entspricht. Der Vorteil der Kompatibilität ist dahin.

Viel zu selten finden (sinnvolle) Anpassungen wieder den Weg zurück in das eigentliche Framework, vor allem da bei kleineren Frameworks schnell das eigene Aufbohren fast so viel Code umfasst wie das gesamte Framework.

... aber warum nicht gleich alles selbst machen?

"Jeder gute Programmierer macht das alles selbst." – Oder so ähnlich. Es gibt einen Grund für Best Practices und ich persönlich wäre beispielsweise nie auf die Idee gekommen, welche Image Replacement Methode denn jetzt die beste sei. Bei Frameworks ist es ähnlich: Ich persönlich habe weder Lust noch Zeit, sicherzustellen, dass mein selfmade Framework auf sämtlichen Plattformen so funktioniert, wie es soll, wenn es schon zig weiterentwickelte Frameworks gibt.

mehr dazu:

Lesenswert zu diesem ganzen Thema auch Stop solving problems you don't have yet und In defense of reinventing wheels.

iOS Simulator wiederbeleben

Ich benutze den iOS Simulator seit Langem um mobile Webseiten zu debuggen. Zum einen fehlt mir ein physische iPad und zum anderen ist es recht umständlich localhost so verfügbar zu machen, dass man ihn auch über's WLAN ansurfen kann. Bisher konnte man den iOS Simulator entspannt über Spotlight finden und starten. Seit ein paar Wochen funktionierte das irgendwie nicht mehr und der Simulator war nur noch über XCode startbar. Und wer einmal XCode gestartet hat, weiß warum man die IDE nicht starten will, wenn man sie nicht unbedingt braucht. Die Ursache des Problems ist, dass der iOS Simulator in das App-Package von XCode gewandert ist, seit Apple angefangen XCode als eigenständige App auszuliefern. (Zuvor gabs über den AppStore nur den Installer.) Ins Package schaut Spotlight nicht rein. Glücklicherweise liegt der Simulator dadrin aber immer noch als einständige App. Am besten legt man sich über den Finder ein Alias an, da Symbolic Links (ln -s) von Spotlight offensichtlich nicht beachtet werden. Hier noch der vollständige Pfad : /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/ Debuggen macht zwar immer noch kein Spaß, aber man hat schneller die Ergebnisse vor sich.

Coding: VPN Shortcut

Ich schreibe ja im Moment meine Bachelorarbeit. Sowas muss natürlich ordentlich versioniert werden, dementsprechend gibt es am Lehrstuhl auch die entsprechenden Git & SVN-Repositories. Von daheim aus komme ich nur über ne VPN-Verbindung ins LRZ-Netz und somit an die entsprechenden Server. Da mir das ewige Geklicke in den Einstellungen zu blöd war und ich die VPN-Anzeige auch nicht in meiner Menübar haben will, hab ich da mal ein kleines AppleScript geschrieben: Es togglt den VPN-Status und gibt über Growl Bescheid, was es grade tat. So lässt sich die VPN-Verbindung über den Spotlight oder jeden anderen App-Launcher deiner Wahl aktivieren und deaktivieren.

Den Code dazu gibt es als kompaktes gist zur Verfügung gestellt. In Zeile 2 muss lediglich der Name der VPN-Verbindung angepasst werden.

Q&A: Hacker Historian George Dyson

permalink

They were hackers. They were young men and women, mostly in their twenties. The ones in their thirties were considered old. They did all the things hackers do: working all night, living for their code, arguing over whether a problem was due to software or hardware. They kept logbooks where they left notes telling the next shift what they had done, and they filled them with dark nerd humor, the same sort of sarcastic jokes you find on email and comment threads today.
Wired hat den Technik-Historiker George Dyson interviewt. Über die Anfänge von Computern, Turing, von Neumann & Co. Extrem interessant und lesenswert.

Standing Desk Experiment

Max probiert Dinge aus – Episode drölf. Dieses Mal: Im Stehen arbeiten. Seit einigen Jahren bin ich immer wieder über Blogbeiträge gestolpert von Personen, die ihren Schreibtisch soweit umgebaut haben, dass sie im Stehen arbeiten können. Die Motivation dahinter war oft sehr unterschiedlich: Produktivität, Gesundheit und Auchmalausprobieren. Vor drei Tagen und viel zu viel Sitzen den ganzen Tag über, hab ich es dann auch mal probiert. Mehr aus reinem Interesse denn fundierten Beweggründen. Hier meine ersten Erfahrungen.

Standing Desk

Kartons, Bücher und Trinkspiele

Die kniffligste Aufgabe, war es Bildschirm und Tastatur auf ein angenehmes Level zu bringen. Richtige Stehschreibtische sind zu teuer und es ist ja auch erstmal nur ein Versuch. Also Kartons und Bücher solange gestapelt, bis die Arme locker sind und man nicht nach unten auf den Bildschirm schauen muss. Das Ergebnis hält für den Moment, dennoch baue ich es jeden Tag, wenn ich länger nicht dran arbeite, wieder ab. Sollte ich mich entscheiden, längerfristig so zu arbeiten, dann muss da aber definitiv noch eine stabilere Lösung her.

Stehvermögen

Es geht sehr in die Beine. Die ersten Tage musste ich mich alle paar Stunde mal hinsetzen und bin oft auch eine Runde durchs Zimmer gegangen oder habe mir den siebten Kaffee geholt. Eigentlich auch eine willkommene Abwechslung. Subjektiv aber hat sich meine allgemeine Körperhaltung aber verbessert. Ein schöner Nebeneffekt.

Produktivität

Wie immer, wenn man etwas neues zum Ausprobieren hat: Die ersten Stunden sind immer super. Die Ernüchterung folgt recht schnell: Man kann auch im Stehen prokrastinieren. Gefühlt arbeite ich jetzt aber mehr in längeren Blöcken. Sprich, erst A fertig machen, dann Ablenken und irgendetwas anderes machen, dann B machen. Vor allem das Verlangen, einfach mal eine Serie nebenzu anzuschauen ist ziemlich zurückgegangen. Was eher schwerlich geht, wenn man längere Texte einfach nur lesen muss. Da heißt es dann eher, Notebook abstöpseln und aufs Sofa setzen. Das kann ich sogar soweit verallgemeinern, dass ich eigentlich am Schreibtisch mittlerweile fast zu 90% wirklich arbeite. Entertainment passiert jetzt wesentlich mehr auf dem Sofa. Unschlagbarer Vorteil: Man kann neben dem Arbeiten durchs Zimmer tanzen. Ich halte euch auf dem Laufenden, wie sich das auf lange Sicht so macht.