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.
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
has the same power as one with
and so on - but connecting the one-line-of-course-code dot not only
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
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
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
Use the library when it’s better, not just because it’s available.