Herding Code 214: Todd Gardner on Tracking JavaScript Errors with {Track:js}

At NDC Oslo, Jon talked to Todd Gardner about {Track:js} and some of the difficulties in diagnosing JavaScript errors.

Download / Listen: Herding Code 214: Todd Gardner on Tracking JavaScript Errors with {Track:js}

Show Notes:

    • What’s TrackJS?
      • (0:20) Jon asks Todd to explain TrackJS. Todd said it’s something he built to help with difficult JavaScript debugging issues a few years ago. JavaScript applications were difficult to debug because it was hard to define the different failure states of his applications. Over time, they worked to add in diagnostic state (e.g. shopping, checkout, etc.). Over time, they added in network state and user state. Over time they came up with telemetry, which defines states and state changes, which can be a lot more helpful than a stacktrace in diagnosing and fixing an error.
    • Why context is more important than stack traces
      • (2:34) Jon agrees, saying that it’s really frustrating to try to reproduce an error as a developer, and context is really important. Todd says that stack traces are limited because applications are so asynchronous in nature now – an error may be from a timeout which was a response to an Ajax event which was a response to a user click.
      • (3:44) Todd says they also track a lot of general information like browser, operating system, and things like date and time information. He once spent a really long time on an error one user was experiencing on a calendaring application because they were stuck in the ’70’s (literally).
    • How TrackJS gathers and exposes data
      • (4:34) Jon asks how developers integrate TrackJS into their applications. Todd says it’s a simple JavaScript include.
      • (4:56) Jon ask more about how he gets access to the reported information when he’s troubleshooting an error. Todd says there are three problems to solve.
        • The first problem to solve is alerting: you get daily rollups on top errors and trends.
        • Second, when you log in, you need to see which errors are which important (filtering out background noise like unsupported useragents, strange Chrome extensions that modify the DOM, etc.). You need to know which errors impact the most people, which cause users to leave, and which are top browser-specific errors.
        • Third, you need to need to be able to dig into and diagnose a specific error.
      • (6:45) Jon asks more about how he’d diagnose a specific error. Todd describes the contextual information TrackJS provides for an error (including things like browser, screen size, user information). For example, one issue they diagnosed recently only occurred at a specific screen size due to a responsive design which modified the page so certain elements were only displayed in a range of screen widths.
    • Common problem: Partial Load Failure
      • (8:14) Jon asks Todd what running the service has shown him are common problems that developers aren’t considering in building JavaScript apps. Todd says it’s partial loading failure – cases where most of the JavaScript assets on a page load, but just one fails. In one instance, they saw everything on a page but the Stripe library load, which caused payment data to be insecurely posted.
      • (10:35) Jon asks about the best way to test for and handle partial load failures.
    • Common problem: Same Origin Policy
      • (11:36) Todd explains same origin policy restrictions in loading loading libraries from other domains, and using cross-origin headers to handle that.
    • Business model and subscription overview
      • (12:30) Jon asks about the business model for TrackJS. Todd explains that they offer free service to charitable and open source projects. For paid accounts, they bill based on page views rather than error count because he feels billing based on errors creates counter-incentives for users.

Herding Code 213: Sean Trelford on Composing 3D Objects with F# and OpenGL

At NDC Oslo, Sean Trelford did a lightning talk on composing 3D objects using F# and OpenGL. Oh, and he’s 8 years old. Sean (and his dad, Phil) talk to Jon about learning coding with Small Basic and F#, and how it’s fun to learn coding by building video games.

Download / Listen: Herding Code 213: Sean Trelford on Composing 3D Objects with F# and OpenGL

Show Notes:

    • Hello
    • Sean’s Talk
      • (1:13) Jon asks Sean whether he showed slides or did live coding.
      • (1:39) Sean made an army from one 3D man model.
      • (2:09) Jon asks how difficult it is to call OpenGL from F#. Sean’s dad, Phil, explains how Sean used a domain specific language – about 50 lines of code. You can use it to create shapes like cubes and spheres, color them, transform them, etc.
      • (3:30) Phil explains how Sean used the F# REPL to create and modify 3D objects interactively, then used functional composition to put the parts (head, arms, legs) together to build the army man, the used functional composition and aggregation to create the army.
    • Learning Small Basic and F#
      • (4:37) Jon asks Sean if F# is his first computer language; Sean says he started with Small Basic. Jon asks if he found it difficult to move from Small Basic to F#, Sean and Phil explain how F# is actually a pretty natural step from Small Basic. Small Basic has no functions with parameters, so when they had a project that ran into that limitation they just moved the code from Small Basic to F# and used the Small Basic library to construct 2D shapes (leveraging WPF).
    • Fun Basic
      • (7:02) Phil said that last year he and Sean rewrote Small Basic as Fun Basic (available free in the Windows Store). It’s an IDE with IntelliSense, code completion, etc. It’s got backward compatibility with Small Basic, but includes function with arguments, pattern matching, etc.
    • Learning programming with video games
      • (8:02) Jon asks about what next for Sean. Recently they went to a game jam and made a platform game. Phil says the REPL environment is huge for game building.
      • (9:04) Jon mentions the IoT lab at NDC and asks Sean if he’s done anything with IoT; Sean says no. Jon says it seems like people try to get kids interested in coding with IoT, but maybe games are more fun to get started. Phil says that Sean’s got a Minecraft channel on YouTube. Jon asks Sean about making videos about making games.
      • (10:38) Phil says he got started on computers with games – he made his first game when he was 11, but his first commercial game was when he was 14 – Flint Eastwood.
      • (11:44) Jon asks Sean if this is his first time in Olso, and his first conference. It’s his first time in Oslo, and his first "speaking" oriented conference.
      • 11:28 Jon asks if they’ve got any last messages, maybe to encourage kids to get started with coding. Phil recommends the Hour of Code, as well as other resources online. Phil says his older son got into programming by adding levels to games, then writing scripts for AI’s, etc. Phil says that’s how he got started – looking at other peoples’ code and going from there. Don’t necessarily get hung up on fancy coding concepts, just script something and have fun!