dev/notes/20170713
13 Jul 2017This 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.