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.
Kommentare
Frederic Hemberger #
Geschrieben am 7.09.2014 um 10:47
Wer sich darüber hinaus für das Thema Debugging im Kontext von Node.js interessiert, dem seien noch diese beiden Links empfohlen:
V8 Performance Profiling
Tools and resources regarding Node.js and Performance Tools Integration
Wobei die Materie noch ein wenig komplizierter ist. Bislang habe ich da wenig einsteigerfreundliches Material entdeckt …
Sebastian #
Geschrieben am 8.09.2014 um 06:56
Was die Network Information API angeht bin ich absolut bei Peter. Das ganze Thema kann so nicht angegangen werden, das berücksichtigt die Realität in vielen Ländern so gar nicht. Der Lösungsansatz fällt komplett in sich zusammen wenn man z.B. in UK eine Karte von „3“ kauft die dann auf einmal eine echte Flatrate in schnell hat, oder in Skandinavien, wo es ja ähnlich aussieht, da bekommt man für wenig Geld 100GB LTE oder hat generell LTE als Ersatz für den Festanschluss und da kann es doch dann nicht die Lösung sein das solche User dann nur noch für Mobil optimierte Auflösungen bekommen.
Ich denke das wäre vor 10 Jahren ne Idee gewesen, aber so langsam sollte man doch sehen das die Mobilnutzung immer größer wird und der Trend dann in einigen Ländern doch auch zu mehr oder unbegrenzten Volumen geht (außer in Deutschland und USA) und da möchte ich als Nutzer doch gern selbst bestimmen wann ich eine schlechte Version von Bildern und Videos bekomme und das nicht von einer API diktiert bekommen.
Casarock #
Geschrieben am 9.09.2014 um 14:25
Hi,
ich habe heute eure Diskussion zu der Network gelauscht. Soweit alles nachvollziehbar. In der Diskussion wird immer wieder von unseren Infrastruktur in Deutschland ausgegangen. Betrachtet man das mal für sog. emerging markets (wachstumsländer, Indien etc.), ist eine solche API durchaus sinnvoll. Genau das verfolgt Mozilla mit Firefox OS. Daher wird diese API auch seitens Mozilla gepushed und immer wieder erwähnt. Geplant ist auch, dass die API irgendwann(tm) zurück gibt, ob die Verbindung „metered“ (Volumenbeschränkt) ist. In wie fern das irgendwann mal realität wird, sei dahin gestellt.
Prinzipiell ist die API sinnvoll, wenn man es nicht nur auf Länder bezieht, die mittlerweile eine ziemlich gute Infrastruktur haben. Das Web ist mehr als nur diese Länder. Und wie man mit Firefox OS sieht, sollen auch die nicht so „fortschrittlichen“ Länder sinnvoll das Netz benutzen können. Und hier gibt es nunmal Beschränkungen, die wir uns zugegebener Maßen, schwer vorstellen können.
Casarock #
Geschrieben am 9.09.2014 um 14:29
Noch ein Nachtrag:
Leider wurde das ursprüngliche „metered“ im aktuellen ED verworfen. Ich habe mich auf den alten, verworfenen WD bezogen. Wie schnell sich sowas ändert ;)
Daniel #
Geschrieben am 10.09.2014 um 17:46
Für die netinfo API sehe ich grundsätzlich schon einige Anwendungsfälle (siehe Punkt 5 in den W3C Use cases – iOS, damit verbunden „WebApps“ auf Mobiltelefonen, FirefoxOS usw.). Oft gibt es Dinge, die über WiFi einfach mehr Sinn machen, da dort in der Regel keine oder seltener Datenlimits existieren. Auch ist es immer interessant zu wissen, ob Connection besteht oder nicht. z.B. könnte man Daten im local storage cachen und wenn wieder Verbindung existiert synchronisieren…
Ob die API in der aktuellen Form für alle dieses Zwecke nutzbar ist, ist eine andere Frage, die man sicher diskutieren kann. Der grundsätzliche Bedarf steht in meinen Augen jedoch außer Frage.
Noch eine Anmerkung zur Diskussion:
„Was der Bauer nicht kennt, ….“
Kurz ging es um das „schlimme“ Eclipse und Java etc. Ob jemand nun mehr der IDE oder Editor-Freund ist, sei mal dahingestellt. Trotzdem fand ich es schon lustig über eine IDE zu lästern, die schon vor 10 Jahren sehr, sehr viel konnte (Eclipse mit dem JDT) und auch heute ein sehr mächtiges Tool ist. Eine IDE entfaltet nun mal immer erst ihre Kraft, wenn man sie beherrscht.
Daher finde ich solch Tool-Bashing (in welche Richtung auch immer) unnötig, da es in der Regel eine persönliche Präferenz ist. Gleiches gilt für andere Programmiersprachen. Auch hier fände ich manchmal etwas mehr Offenheit und Neugier wünschenswert (und nicht immer die ewige Leier vom „schlimmen“ PHP, Java, Whatever ..)
Ansonsten vielen Dank für die Mühe und euren wöchentlichen Einsatz!
Stefan #
Geschrieben am 15.09.2014 um 19:39
Lieber Daniel, nicht falsch verstehen: Ich habe nix gegen Java, Eclipse oder sonst irgendetwas anderes, doch vor einziger Zeit aus langjähriger, eigener Erfahrung beschlossen, dass das halt mal so gar nix für mich ist ;-) IDEs sind ja auch nicht schlimm, ich finde z.B. IntelliJ und Konsorten echt brauchbar.
Bg,
Stefan
Nico #
Geschrieben am 10.09.2014 um 19:20
Zum Debugger kam ich eigentlich über Opera Dragonfly, welches inzwischen leider nicht mehr weiterentwickelt wird, seit Opera Blink nutzt. Nervig wird die Nutzung des Debuggers allerdings manchmal, wenn man mit Bibliotheken wie jQuery arbeitet, weil dann ein schrittweises durchgehen des Codes oft in deren Tiefen unpraktisch wird. Eine Integration des Debuggers in eine IDE halte ich nicht für sinnvoll, sofern diese nicht von jedem Browser aus möglich ist, denn oft geht es ja darum, dass ein Bug nur in manchen Konstellationen auftritt und dann habe ich lieber einen guten Debugger im Browser als einen guten in der IDE, der aber nicht mit dem Browser redet.
Schepp #
Geschrieben am 10.09.2014 um 23:20
Hallo Nico, danke auch Dir für Deinen Kommentar! Schau Dir doch mal Firefox‘ Black Box Funktion an. Mit der kannst Du Bibliotheken wie jQuery aus dem Debugging-Prozess komplett ausblenden.
Mathias #
Geschrieben am 10.09.2014 um 20:01
Hallo, wie immer eine super Folge! :)
Zum Debugging habe ich noch eine kleine Anmerkung, entweder habe ich euch nicht richtig Verstanden, oder keiner von euch benutzt das debugger statement im Javascirpt code, oder?
Weil immer die Rede davon war, dass es doch viel schneller sei ein console.log statement hinzuzufügen anstatt im Browser umständlich einen Breakpoint zu setzen.
Außerdem denke ich, dass es stark damit zusammenhängt ob man eine Webseite, mit nur wenig Javascript grade baut oder ob es eine größere Webapp ist.
Gerade bei Schleifen und wenn nicht ganz klar ist welche property o.ä. fehlerhaft ist, nutze ich gerne das debugger statement.
Dank lifereload geht das superschnell, wenn ich speichere hält der Browser ist eine Sekunde später bei der gewünschten Code-Zeile an. :)
andi1984 #
Geschrieben am 10.09.2014 um 22:33
Danke für diesen Hinweis mit dem debugger statement. Man lernt nie aus :)
andi1984 #
Geschrieben am 10.09.2014 um 22:55
Wieder einmal eine sehr tolle Folge. Vielen Dank dafür! Immer wieder schön auf Autofahrten oder im Fitness-Studio euch zuzuhören :)
Nun zum Thema JavaScript Debugging:
Generell debugge ich auch eher mittels console.log/debug. Wenn es aber um eine genaue zeitliche Abfolge oder eine konkrete Nachverfolgung geht, dann ziehe ich den entsprechenden Debugger zurate. Oftmals wünsche ich mir z.B., dass ich beim Debuggen innerhalb des Debuggers die Bibliotheks-Schichten überspringen kann, sodass mir quasi ermöglicht wird nur die Abfolge innerhalb des eigenen Codes zu überprüfen. Ich glaube dies war auch schon einmal ein geplantes Feature für den Chrome oder FF Debugger, aber wirklich mehr weiß ich dazu nicht mehr.
Zudem fällt es mir vor allem im Chrome Debugger manchmal sehr schwer die passende Stelle im Code zu finden, d.h. das Navigieren durch Dateien und vor allem Inline-JavaScript finde ich noch verbesserungswürdig. Sehr nützlich finde ich jedoch die Nutzung der Browser-Debug Console zur Laufzeit im Zusammenspiel mit Breakpoints.
Schepp #
Geschrieben am 10.09.2014 um 23:09
Danke für Deinen Kommentar, Andi! Welches Browser-Feature Du sicherlich in Erinnerung hattest, ist Firefox‘ Black Box
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.