Revision 185: JS Debuggingstrategien & Network Information API

Published: Sept. 7, 2014, 9:26 a.m.

b'Die aktuelle Folge in (fast) vollst\\xe4ndiger Besetzung mit einer Diskussion zum\\nThema JavaScript Debugging und zur neuen Netzwerk Analyse API.\\n\\n\\n[00:00:30] NEWS\\n\\nSASS 3.4 IS RELEASED\\n\\nSass 3.4 ist drau\\xdfen mit einigen Kleinigkeiten. Beim Upgrade ist auf die\\nKompatibilit\\xe4t zu alten Versionen zu achten.\\n\\n\\nSCHAUNOTIZEN\\n\\n[00:00:50] JAVASCRIPT FEHLERBEHEBUNGSTRATEGIEN\\n\\nPeter startete eine Umfrage per Twitter, wie Developer JavaScript Fehler\\nanalysieren. Wir diskutieren die beiden Ans\\xe4tze.\\nHans benutzt in erster Linie console.log, weil ihm das Debugging zu umst\\xe4ndlich\\nist, und vielleicht auch weil er keine \\xdcbung hat. Wenn er ganz viel Details\\nbraucht, dann greift er zum Debugger. Im Verh\\xe4ltnis: eine Verteilung von 80%\\nconsole.log vs. 20% Debugger.\\nMeist wird zum Debugger gegriffen, wenn man herausfinden will, wo eine\\nVer\\xe4nderung urspr\\xfcnglich herkommt. Wenn man nur Werte analysieren will, nimmt\\nman \\xfcblicherweise die Konsole.\\nEin Tipp kommt von Peter. Er nutzt console.log als bool\\u2019schen Wert f\\xfcr einen\\nbedingten Breakpoint im Debugger, um sich Werte ausgeben zu lassen, ohne\\nwirklich console.log in den JavaScript-Code zu schreiben. Au\\xdferdem hat er den\\nEindruck, dass der Debugger nicht angenehm zu bedienen ist, und er ist manchmal\\nzu punktuell und zu detailliert. Manchmal will man eher weniger tief und in der\\nBreite Code analysieren.\\nStefan nutzt gerne die Debugger-eigene Konsole.\\n\\n[00:17:17] HTML5: NETWORK INFORMATION API \\u2013 TUTS+ CODE TUTORIAL\\n\\nStefan meint, \\xfcber die API kann eine Webseite entscheiden, wie \\u201efett\\u201c sie\\ndaherkommen will. Peter wei\\xdft aber darauf hin, dass die gelieferten Infos,\\nrespektive die Folgerungen daraus ganz sch\\xf6n daneben liegen k\\xf6nnen. Peter fragt\\nsich also, warum entwickeln Google und Co. so eine unbrauchbare API? Schepp\\nmeint der Usecase k\\xf6nnte in ChromeOS liegen (vgl. W3C Use Cases). Anselm meint,\\nman kann vielleicht auf bestimmte, \\u201esichere\\u201c Abfragen, also z.B. die Abfrage\\nnach \\u201eCellular\\u201c, gehen kann. Peter sieht die einzige brauchbare Umsetzung von\\nsoetwas in der Art wie Youtube es tut. Anselm liest folgende von der Spec\\ngenannten Use Cases vor: Die BBC-Seite warnt bei \\u201eCellular\\u201c den Benutzer vor dem\\nStart vor hohen Kosten. Ein weiterer Use Case: der Firefox Marketplace bietet\\nnur dann eine SMS-basierte Authentifizierung an, wenn beim Endger\\xe4t \\u201eCellular\\u201c\\nentdeckt wird. Anselm sieht den Vorteil gegen\\xfcber dem Youtube-Verfahren darin,\\ndass die API viel leichter einzubinden und abzufragen ist. Peter meint\\nweiterhin, die API sei nicht zu gebrauchen.\\n\\n\\n[00:40:57] KEINE SCHAUNOTIZEN\\n\\nGRUNT-SPLIT-IMAGES\\n\\nCSS in verschiedene Dateien verteilen, die zum einen Layout, zum anderen\\nStylingbilder betreffen. Letztere l\\xe4sst sich dann praktisch per Lazy Loading\\nnachladen.\\n\\nBUILDING MARKDOWN-BASED DEVELOPER DOCS\\n\\nMarkdown-basierte Dokumentation im Code, die sich automatisiert auslesen l\\xe4sst.\\n\\nLET\\u2019S BUILD A BROWSER ENGINE!\\n\\nEin Tutorial, das beschreibt, wie man eine eigene Browser Engine bauen kann.\\n\\nHOW TO SECURE YOUR SITE IN AN AFTERNOON\\n\\nSSL f\\xfcr die eigene Website in nur wenigen Schritten.'