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
.features() call has the same power as one with
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.