public learning

Vier Jahre Student sein und immer noch nicht wissen, wie man am besten die ganzen Informationen organisiert. Oder aus Prokrastinationsgründen immer neue ausprobieren? Anyway. Über Stift und Papier, Evernote, Wikis, OneNote, bin ich jetzt bei GitHub gelandet. Die Idee dahinter: Warum nicht die Dinge, die ich mir für Klausuren näherbringen darf, wie Code behandeln? Lernen ist auch nichts anderes als das Wissen zu versionieren. Here you go: https://github.com/mkleucker/public/tree/master/studium (und ja, ich schreib dieses Semester nur eine Klausur)

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.

Stylus und CoffeeScript

Entwickler sind bequem und schreiben sich lieber ein kleines Script oder Programm, ehe sie einen Task manuell ein Dutzend mal ausführen. Für Web(-frontend-)entwickler gilt das genauso. Hier hat sich insbesondere in den letzten beiden Jahren einiges getan: Präprozessoren für CSS und CoffeeScript. Ich bin erst vor einigen Wochen dazu übergegangen, beides zu nutzen und aus meiner Sicht lohnt sich der – ohnehin geringe – Aufwand zum Einstieg. Die Zeit zum Schreiben von CSS und JS hat sich merklich verkürzt. Anpassungen gehen schneller von der Hand. Der Artikel gibt selbstverständlich nur einen kleinen Einblick in den Funktionsumfang.

CSS-Präprozessor: Stylus

Neben den Wegbereitern LESS und SASS, habe ich persönlich am meisten Gefallen an Stylus gefunden. Alle drei sind Präprozessoren für CSS und erweitern es um äußerst praktische Funktionen. Eine wichtige Eigenschaft: alle Möglichkeiten sind optional. Es ist auch möglich ganz normales CSS durch den jeweiligen Präprozessor jagen. Ich konzentriere mich im Folgenden auf die Eigenschaften von Stylus. Die Syntax ändert sich nur minimal: Das Verschachteln von Elementen wird wesentlich vereinfacht. Zudem ist möglich, ohne Klammern zu arbeiten und stattdessen über die Einrückung zu steuern, was wozu gehört. Mit Variablen, Mixins und @extend ist es möglich den eigenen CSS-Code wesentlich besser zu abstrahieren und muss elementare Eigenschaften nur einmalig festlegen. So kann man beispielsweise sicher gehen, dass man bei einer Änderung der Link-Farbe keine CSS-Regel übersehen hat oder sich Mixins anlegen, die Vendor-Prefixe automatisch hinzufügen.

JavaScript-Aufsatz: CoffeeScript

CoffeeScript ist eine eigene Sprache, die sich selbst aber zu 100% in JavaScript übersetzt und lediglich das Schreiben von JavaScript vereinfachen will. Bei CoffeeScript geht es mehr um syntaktischen Zucker, um eine Vereinfachung der Syntax. So können einfache Funktionen wesentlich prägnanter geschrieben werden oder das Initialisieren von Variablen automatisch übernommen werden. Sehr großer Pluspunkt: Der produzierte Code ist lesbar.

Anwendung im täglichen Entwicklerleben

Beide, Stylus und CoffeeScript, müssen ans Werk gehen, eher die Daten an den User geliefert werden. Dafür gibt es zwei Wege: Entweder lokal die Dateien verarbeiten und das Endresultat auf den Server schieben, oder diesen Prozess auf dem Server erledigen lassen. Da ich persönlich erst auf meiner lokalen Entwicklungsumgebung teste und dann alles auf den live-Server schiebe, lade ich die fertigen CSS & JS Dateien einfach per FTP hoch.

Verwendung

Stylus & CoffeeScript sind beide als Module für node.js am Start und erforden auch dementsprechend einen node.js-Server. Wichtig, falls man die Generierung der Dateien gerne remote abfeiern möchte. Für die lokale Umgebung gibt es zwei angenehme Alternativen, welche die Nutzung sehr vereinfachen:
  • Persönlich nutze ich am Mac mit CodeKit eine GUI-Programm, dass die Verwaltung der verschiedenen Präprozesoren sehr angenehm löst und bei jedem Speichervorgang die Dateien neu verarbeitet.
  • Eine Alternative (die es auch bald für Windows gibt) ist LiveReload, das geht soweit, dass es – wahlweise über JavaScript oder Browserengine – auch direkt die Seite aktualisiert.

Designers.MX

designers.mx Ich stolperte gestern über Designers.mx – einfaches Konzept: Leute (ausgewähltedesigneryouknow) laden Playlisten hoch und machen noch ein schönes Cover dazu. Unglaublich gute Stücke dabei. Eignet sich super zum Arbeiten.

Sechs Tage in Lyon

Spreche immer noch kein Französisch, trank dafür aber mehr französisches Bier und Wein. Es endete damit, dass ich ein Jahr älter wurde. Danke an alle Beteiligten für den super Kurztripp.

Ein Wochenende in Berlin

Zum ersten Mal in Berlin gewesen. Anlass war der Google Developer Day. Das bedeutete: Lange Autofahrt, viel Spaß, viel (Glüh-)Wein, bestätigte Vorurteile (Sorry, Berlin), noch mehr Spaß. Danke Google für die geilen Vorträge, X Liter Club Mate, übermäßig viel Essen und ein ganzen Haufen neue Ideen. Bis nächstes Jahr. Dann bekomm ich auch das ChromeBook, deal? Auf dem Bild übrigens der Blick aus unserer - verrauchten und klingellosen (macht jede Pizzabestellung 100% spannender), aber super gelegenen - Wohnung.