thoughtwisps One commit at a time

dev/notes/20170713

This is a completely unedited stream-of-consciousness (most certainly not the kind produced by Woolf and Joyce) style braindump of today’s development progress, questions and general wtf moments. Content may not make much sense. You have been warned!

I am back in the world of frontend web development. My goal is to put together a frontend for my London underground simulation. Because I am literally hopeless when things come to Javascript (um, Node, Ember, D3, Angular, React - things have moved on quite a bit since late 2014 early 2015 when I last touched JS ), I’m going through some newbie tutorials (mostly examples from D3.js By Example by Michael Heydt ) and trying my hands at visualizing [London air quality data] (https://data.london.gov.uk/dataset/london-average-air-quality-levels). The examples in D3.js By Example make calls to data hosted in gists, so lo and behold - things don’t work out of the box when I try to call d3.csv on a file stored in my local file system. Chrome surprises with a ‘No ‘Access-Control-Allow-Origin’ header is present.

A few moments of search-engine-ing tells me that perhaps I should not be calling to the file system directly, but using an http server to serve up the raw data file. In goes python -m SimpleHTTPServer and things move along just a bit before grinding to a halt with a ‘Cross-Origin Request Blocked’. As this article explains, a resource within a website may try to load additional resources using a different domain, protocol or port (which is the case when the D3.js script tries to read a file served by the SimpleHTTPServer). This StackOverflow question recommends creating a customised version of the built-in SimpleHTTPServer to send back the correct headers. Solution works, problem avoided, but not fully understood, yet.