I finally made a website for simple-statistics on Max Ogden’s sage advice, and finally realized how much of a problem it is to have a GitHub project as the only landing page for something. While it’s a familiar sight for core developers, to the uninitiated, it’s over-complex and overfilled with information that’s unrelated to just understanding and using a thing.
Then I did the same for Big and have started to think about how I should handle the maturity of a project that was and still is sort of a postmodern joke.
I joined the Raspberry Pi club and am currently pretty darn impressed by it.
Big thanks to Erin Kissane, Charlie Lloyd and crew for spreading the word about a big sale at the MIT Press, where I got a stack of books. The best so far is Fashioning Apollo, which intriguing and inspiring in so many directions.
Been listening to a lot of the Can’t Tells since playing with them in Baltimore.
One of my big tasks at MapBox the last week has been making a series of 6 dashboards that run 24/7 on big displays. It’s one of those odd internal projects with a elliptical purpose but in the meantime: glowing things.
The most annoying of which has been WMATA DC’s transit system, which gives bus and train predictions, amongst other information. Unfortunately, the city uses Mashery to ‘manage’ the API frontend, which leads to an artificially low limit on API requests (alas, not the only example of DC making bad contractor decisions).
That said, I’ve gotten pretty good at jumping from problem to solution without the annoyance stage. It’s an odd technique, but wmataapiapi is an API on WMATA’s API that currently has an instance on Heroku that you can build things on that would consume your API limit very quickly otherwise.
While wmata-client which makes some computation local and fast and will eventually hit
wmataapiapi as soon as it supports more things. This deserves a real post of its own when I have more code to demonstrate the abstract.