Emmet - The essential toolkit for web-developers

Eine der Dinge, die ich in meiner täglichen Arbeitswelt nicht habe, ist zu viel Zeit. Daher bin ich immer daran interessiert, wenn möglich genau diese, mir sonst an anderer Stelle fehlende Zeit einzusparen.

Eine der häufig unnötig Zeit kostenden Tätigkeiten ist dabei das Aufbauen der benötigten DOM Struktur. Dabei ist es oft der Fall, dass viele wiederkehrende Elemente, wie beispielsweise Listen und deren Elemente, angelegt werden müssen. Diese Arbeit ist oft mühselig und kostet unnötig Zeit.

Abhilfe kann hierbei Emmet schaffen. Mit dem selbst ernannten "essential toolkit for web-developers" lassen sich mit einfachen Anweisungen schnell und einfach komplexe Strukturen aufbauen.

Einen Überblick über die Funktionen findet ihr in der Emmet Dokumentation.

Emmet ist als Plugin für viele Editoren verfügbar. Viele Online IDEs  wie CodePen und JSFiddle haben Emmet sogar schon integriert.

Glücklicherweise wird Emmet nativ von meiner Lieblings-Entwicklungsumgebung PHPStorm von JetBrains unterstützt.

Für alle, die gerade erst beginnen, oder ausgelößt durch diesen Artikel, mit Emmet zu arbeiten, kann ich dieses Cheat Sheet Empfehlen.

Ich hoffe, dass ihr genauso viel Interesse an Emmet findet und dies euch ebenfalls eure Arbeit erleichtert.

Callbacks in JSDoc

lange Zeit habe ich mich gefragt, ob es in JSDoc  eine Möglichkeit gibt, Callbacks beziehungsweise die Parameter die an die Callbacks übergeben werden sauber zu dokumentieren.

Bis dato habe ich zwar die Callbacks die an die aufrufenden Funktion übergeben werden mit @param Dokumentiert, die Parameter die an diesen Callback übergeben werden musste man jedoch schlichtweg wissen.

Bei kleineren Skripten ist dies ja noch möglich, bei größeren Skripten führt die häufig schnell ansteigende Zahl der Callbacks jedoch auch zu einem recht proportionalen Verlust der Übersicht über eben diese.

Des weiteren konnte ich mir nicht vorstellen, dass es hierfür keine Lösung gibt, denn dinge die man schlichtweg wissen muss stehen ja schon prinzipiell kontrovers gegen den Grundgedanken einer Software Dokumentation und damit auch gegen das Prinzip von JSDoc.

Nach einiger Recherche habe ich heute dann doch die korrekte Lösung dann doch ganz am Ende der Dokumentation zu @param finden können:

/**
 * This callback type is called `requestCallback` and is displayed as a global symbol.
 *
 * @callback requestCallback
 * @param {number} responseCode
 * @param {string} responseMessage
 */
/**
 * Does something asynchronously and executes the callback on completion.
 * @param {requestCallback} cb - The callback that handles the response.
 */
function doSomethingAsynchronously(cb) {
    // code
};

Zunächst definiert man über den @callback Parameter die Callback Funktion mit den zugehörigen Parametern. An der aufrufenden Funktion kann man nun mit {callbackName} auf die zuvor dokumentierte Callback-Funktion verweisen.

Ich bin froh, nun einen Ansatz gefunden zu haben, der mir einen besseren Überblick in großen Projekten verschafft und hoffe, dass ich dem ein oder anderen dadurch ebenfalls helfen konnte.

Performant HTML5 Canvas detection

Für ein aktuelles Projekt muss ich in der Applikation prüfen, ob HTML5 Canvas zur Verfügung steht und genutzt werden kann. Ist dies nicht der Fall, soll dem Anwender eine entsprechende Rückmeldung gegeben werden, mit der Bitte doch bald einmal seinen Browser zu aktualisieren.

Der übliche Weg, der auch in den meisten Frameworks verwendet wird, ist ein entsprechendes Canvas Element zu erzeugen und das Ergebnis zu überprüfen.

Beispiel:

var canvasSupport = !!document.createElement("canvas").getContext;

Leider ist dieser Ansatz, gerade im Internet Explorer, aber auch in anderen Browsern recht performance hungrig. Ein anderer Weg ist es das im HTML Standard und im W3C Working Draft definierte Interface anzusprechen. Eine Dokumentation dazu ist auch im Mozilla Developer Network zu finden.

Beispiel:

var canvasSupport = !!window.HTMLCanvasElement;

Wie vermutet und durch einen jsPerf Test belegt, ist diese Methode in vielen Browsern deutlich schneller. Der Grund hierfür ist recht schnell klar: Bei der zweiten Methode muss nicht erst ein entsprechendes Element erzeugt werden.

Dass dieser Weg deutlich schneller sein muss, ist daher nur logisch. Überrascht hat mich jedoch das Ergebnis. Bei eigens durchgeführten Tests im sogar recht aktuellen Internet Explorer 11 lag der unterschied bei ca 200%!

Den Entsprechenden Test könnt ihr auch selbst durchführen. die URL lautet:
http://jsperf.com/htmlcanvaselement-vs-getcontext-checks

The Power of SASS

See the Pen Particle Orb CSS by Nate Wiley (@natewiley) on CodePen.

Heute bin ich über CodePen über diese SCSS Demo gestolpert die mich doch sehr überrascht hat: Das Ergebnis an sich ist technisch nicht so anspruchsvoll und ließe sich selbstverständlich mit HTML5 Canvas oder ähnlichem problemlos lösen. Die hier vorgestellte Lösung basiert jedoch ausschließlich auf SCSS und kommt ohne JavaScript oder ähnlichem aus. Dies hat mich tatsächlich doch überrascht und mir ein weiteres mal gezeigt, wie mächtig CSS bzw. SASS & LESS doch sind.

Spotify Playlist: Power-Working

Für alle freunde der härteren elektronischen Klänge habe ich einmal eine Playlist mit Liedern die mir beim Arbeiten den richtigen Kick geben zusammengestellt.

 

Falls euch noch Tracks einfallen, die unbedingt in diese Playlist sollten, würde ich mich freuen, wenn ihr mir einen Kommentar hinterlasst.

Shopify Checkout Hack

Für einen Kunden arbeite ich derzeit an einem Web-Shop der auf Wunsch des Kunden mit Shopify umgesetzt wurde.

Wie in diesem Beitrag mehrfach bestätigt, ist es bei Shopify regulär leider nicht möglich den Checkout Prozess anzupassen, weder per Template noch über ein Custom Stylesheet.

Für den Kunden ist es jedoch essenziell, verschiedene Änderungen am Checkout-Prozess vorzunehmen. Zu dem Zeitpunkt an dem ich in dieses Projekt involviert wurde, war die Entwicklung jedoch schon zu weit fortgeschritten, dass ein Wechsel der Shop-Lösung leider nicht mehr möglich war. Daher blieb mal wieder keine andere Möglichkeit, als irgendwie einen Weg zu finden, die Änderungen umzusetzen.

Nach intesivem auseinandersetzen mit Shopify, der Administrationsoberfläche dieser Lösung, und dem integrieten Template System, ist mir nach einiger Zeit aufgefallen, dass es bei hinterlegtem Google Analytics Account die Möglichkeit gibt, Anpassungen für das Google Analytics Tracking zu hinterlegen. Diese Option kann in der Administrationsoberfläche unter

> General > Google Analytics > Additional Google Analytics Javascript

gefunden werden.

Wie sich nach einigen Tests rausstellte, wird der Code, der an dieser Stelle hinterlegt wird, auf allen Shopify Pages, inclusive der Checkout Pages als reguläres <script> Tag geladen.

Ein paar Zeilen später hatte ich ein Script gebaut, dass gegebenenfalls JQuery nachlädt, den aktuellen Schritt des Checkout Prozesses ermittelt und gegebenenfalls JavaScript Code ausführt. Das Ergebnis findet Ihr hier:

Vor dem Einfügen des Scriptes, sollte dieses noch komprimiert werden. Ich persönlich bevorzuge dafür das in node.js entwickelte Tool UglifyJS.

Falls irgendjemand diese Lösung benutzt oder sogar erweitert, würde ich mich über Feedback als Kommentar zu diesem Post freuen.