Recently
This month I made ration, which rations items in intervals. GPSTile does pretty OSM GPS tiles. osm-auth auths osm, osm-live-map is a live map of osm. osm-stream provides it with streaming data. an ironic entry to the 100 lines or less contest to use Esri’s ‘trade secret’ Javascript API. A nice browser for OSM tracing imagery. basicrequest does super-simple ajax. leaflet-pip does points in polygons in Leaflet. I’ve been using browserify a lot, and it’s making tiny modular Javascript components like those in osmlab possible.
The Code
This was a big, big month for the DC Code, thanks to Carl Malamud, who did the heavy lifting, scanning, OCRing, ordering, and so on to get the code from paper to PDF and even a bit to text. There’s so much more to do, but having real and available files for these pages that have occupying so much of my mind for months feels like the start of something.
There are more photos on Flickr, a unboxing on Vimeo, and, of course, the PDF-format code as a bulk download on Public.Resource.org.
Elsewhere
- DC’s Laws Aren’t Yours on Greater Greater Washington
- Quietly Announcing osmlab on talk@openstreetmap
Soon
Listening
Ava Luna, Doseone, darkhalo, Young Rapids’ Day Light Savings, Snowden’s The Beat Comes.
Reading
Thinking
when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create. - _why
this is the quote of the last two years.
One of the most satisfying experiences in this industry of making short lived things is when you make an idea that lives beyond the first implementation. Like books written in dead languages and read in living ones, or a million similar versions of the same clever design for bike lights. There are a few instances of this I really like - how certain ‘recent inventions’ like Atkinson dithering or Perlin noise can seem like fundamental algorithms despite being quite young.
Clean APIs aren’t easy, easy APIs aren’t clean. The clearest example I can see here is syntax sugar: methods only a line or two long that give a concept a name. A markers API that provides a single .features() call has the same power as one with clearMarkers(), addMarker(), removeMarker(), and so on - but connecting the one-line-of-course-code dot not only enables naïve developers who don’t know Javascript (there are many), but it also plays into a desire to have a single method-per-thought-concept. Those in the know understand that there are a handful of core concepts and you can have a complete system with a tiny API - but the concepts that APIs need to worry about are the ones users think are atomic, not those that are atomic.
What is easy is what is familiar. Familiarity is the most underrated usability factor. And what’s familiar is what is learned early.
Always demonstrate the potential of abstracted ideas. While it’s very useful in programming terms to write code that does on this perfectly and is completely tested and extremely useful for some certain case, a lot of people don’t know what that case is. Show them - demonstrate the ‘art of the possible’ by creating an example for absolutely every thing you make. Sometimes I think we’ve done this right - the mapbox.js examples just grow and grow, and Mike Bostock’s little experiments are the raw ingredients of most d3js hacks.
The thing about big libraries and frameworks is that the availability of an ‘app for that’ or a ‘method for that’ soon becomes a dictate that ‘if there’s a method for that in that library, you must use it’. Case in point should be jQuery, which introduced an honestly web-changing selector engine and monadic API, coupled with a lackluster and not-recommend $.each method. But a lot of jQuery programmers used it for selectors and felt guilty using for() loops when there was a ‘library way’ of doing them, so went the $.each route. Use the library when it’s better, not just because it’s available.