Working Draft

Die aktuelle Folge in (fast) vollständiger Besetzung mit einer Diskussion zum Thema JavaScript Debugging und zur neuen Netzwerk Analyse API.

[00:00:30] News

Sass 3.4 is Released

Sass 3.4 ist draußen mit einigen Kleinigkeiten. Beim Upgrade ist auf die Kompatibilität zu alten Versionen zu achten.

Schaunotizen

[00:00:50] JavaScript Fehlerbehebungstrategien

Peter startete eine Umfrage per Twitter, wie Developer JavaScript Fehler analysieren. Wir diskutieren die beiden Ansätze.
Hans benutzt in erster Linie console.log, weil ihm das Debugging zu umständlich ist, und vielleicht auch weil er keine Übung hat. Wenn er ganz viel Details braucht, dann greift er zum Debugger. Im Verhältnis: eine Verteilung von 80% console.log vs. 20% Debugger.
Meist wird zum Debugger gegriffen, wenn man herausfinden will, wo eine Veränderung ursprünglich herkommt. Wenn man nur Werte analysieren will, nimmt man üblicherweise die Konsole.
Ein Tipp kommt von Peter. Er nutzt console.log als bool’schen Wert für einen bedingten Breakpoint im Debugger, um sich Werte ausgeben zu lassen, ohne wirklich console.log in den JavaScript-Code zu schreiben. Außerdem hat er den Eindruck, dass der Debugger nicht angenehm zu bedienen ist, und er ist manchmal zu punktuell und zu detailliert. Manchmal will man eher weniger tief und in der Breite Code analysieren.
Stefan nutzt gerne die Debugger-eigene Konsole.

[00:17:17] HTML5: Network Information API – Tuts+ Code Tutorial

Stefan meint, über die API kann eine Webseite entscheiden, wie „fett“ sie daherkommen will. Peter weißt aber darauf hin, dass die gelieferten Infos, respektive die Folgerungen daraus ganz schön daneben liegen können. Peter fragt sich also, warum entwickeln Google und Co. so eine unbrauchbare API? Schepp meint der Usecase könnte in ChromeOS liegen (vgl. W3C Use Cases). Anselm meint, man kann vielleicht auf bestimmte, „sichere“ Abfragen, also z.B. die Abfrage nach „Cellular“, gehen kann. Peter sieht die einzige brauchbare Umsetzung von soetwas in der Art wie Youtube es tut. Anselm liest folgende von der Spec genannten Use Cases vor: Die BBC-Seite warnt bei „Cellular“ den Benutzer vor dem Start vor hohen Kosten. Ein weiterer Use Case: der Firefox Marketplace bietet nur dann eine SMS-basierte Authentifizierung an, wenn beim Endgerät „Cellular“ entdeckt wird. Anselm sieht den Vorteil gegenüber dem Youtube-Verfahren darin, dass die API viel leichter einzubinden und abzufragen ist. Peter meint weiterhin, die API sei nicht zu gebrauchen.

[00:40:57] Keine Schaunotizen

grunt-split-images

CSS in verschiedene Dateien verteilen, die zum einen Layout, zum anderen Stylingbilder betreffen. Letztere lässt sich dann praktisch per Lazy Loading nachladen.

Building markdown-based developer docs

Markdown-basierte Dokumentation im Code, die sich automatisiert auslesen lässt.

Let’s build a browser engine!

Ein Tutorial, das beschreibt, wie man eine eigene Browser Engine bauen kann.

How to secure your site in an afternoon

SSL für die eigene Website in nur wenigen Schritten.

Anhören