Tuesday, August 21, 2012

Random thoughts

37 signals drives me insane.  Reading this post almost ruined my day.  Having graduated from one of the most pretentious fine art institutions in the country, I can safely say that a lot of people see themselves at the top of this pyramid.  The problem with self-identifying at the top of such a hierarchy is that it leads to an insidious self-awareness.  I can almost certainly guarantee you, nobody will read your code and think it is beautiful because nobody will give a shit about your code. It's computer code, not poetry.

Twitter freaks me out.  One of the fundamental principals of Newspeak was the inability to express meaningful thoughts.  Twitter is a highly digestible format for a particular kind of reader.  There must be a self-satisfaction in knowing everyone agrees with you and you agree with them.  Scares the life out of me, but I still think Twitter is awesome.

PHK's a Generation Lost in the Bazaar is a good read.  However, the issues he claims are problems will continue to grow (especially since hardware tends to compensate for wasted cycles).  A coworker of mine described programming as mastering confusion rather than understanding processes.  There's a coherent thought here somewhere ... but the kind of personality rewarded by the cathedral tends to be less qualified than the personality rewarded by the bazaar.  What I mean is that the cathedral produces incompetent dictators.  Second, the world is undergoing a technology blitz now so it's better to be wrong than nothing at all.

Saturday, August 4, 2012

backbone.js & couchdb

This blog post is about some code I wrote to solve a problem.  I didn't care for the existing solutions, but I now think that I don't care for the problem.

My initial interest in backbone was as a tool to quickly prototype UI couchapps.  Specifically I wanted an easy way to modify collections of documents in CouchDB on a web page.  Unfortunately, that wasn't as easy as I expected.  So here's some of what I learned thus far.

Using jshint or jslint will save time.  I've spent hours debugging JavaScript in the browser (which is less painful thanks to Firebug and Chrome) and hours debugging JavaScript in PhoneGap projects.  Debugging syntax mistakes in a chromeless browser over ADB is a nightmare.

Writing test cases for async code is a nightmare.  Qunit sucks for async testing, but is a great tool otherwise (haven't tried jasmine yet).  The right solution is to test with node (specifically using mocha).  So, I had to learn a little about node and here's the magic.

setup(function(done) {

The setup function takes a parameter called done, which indicates setup contains async code and is also a callback to indicate the async code is complete.

Separate a ReSTful interface into components.  Don't make one giant method for everything, separate create/read/update/delete into methods invoked from sync: 

    Couch.Model.prototype.sync = function(method, model, opts) { 
        if (debug) console.info(method); 
        switch (method) { 
        case "read": 
            return this._read.call(this, model, opts); 
        case "create": 
            return this._create.call(this, model, opts); 
        case "update": 
            return this._update.call(this, model, opts); 
        case "delete": 
            return this._delete.call(this, model, opts); 
This is good practice for server side code too.  Separate the storage layer from API so that the storage layer can be used outside the API.  The reason I mention this is that most Backbone users will probably implement server side ReST views rather than Backbone.sync.

Why are id and rev sometime prefaced with an _?  Seriously, why is there an _ sometimes?

99% of all applications require a server-side controller with record read access.

Thursday, August 2, 2012

Fire Follows Function

You're looking at the power cord from the original MacBook from 2006.  This elegant design resulted in a short, which caused a small localized flame and a little smoke.  Luckily my wife quickly unplugged it, since she was home and not asleep or busy with a baby or doing any of the things people normally do when they're not expecting their computer equipment to burn their house down.

This connector is an illustration of code douchery.  The form followed aesthetics rather than function.  Ideals about good, elegant design were valued more than the time-tested clunky adapter.  Fire, rather than form, followed function.

Yet Apple sold a lot of these units and settled a class action lawsuit over this very issue.  Apple products are so damn beautiful, yet apparently so dangerous.  Apple got rich on beautiful yet objectively bad design (like burning your house down).  So what gives? Obviously a little code douchery helps the medicine go down.

An old friend told me that artists are often seduced by the image of being an artist rather than creating beautiful images.  So the creative process can diverge into a feedback loop.  Rather than being creative, a lot of creative people spend their creative energy on convincing others that they're creative.  Apple is creative, so Apple is for creative people like you.

I think Apple tapped into the neurosis of creative people.  They sold image rather utility and they got rich doing this for two reasons.  The first is that PC manufacturers and Microsoft are unable to do sexy; Apple is able to make and sell sexy.   The second is that Apple greatly improved the user experience through an operating system and UI, thus delivering on ephemeral appeal.  No buyer's regret.

Apple failed.  They almost burnt my house down.  They got rich by almost burning my house down.  Apple won.  Not everything is absolute, but absolutes might by an indicator of the code douche and Sith.

Code worship

A talk given at PyCon by Jack Diedrich called Stop Writing Classes rang true with me.  Jack's point is that classes are overused.  He demonstrates his point with an obvious example. It's an excellent talk.  However, my favorite lesson is we ship features not lines of code.

I'd get this tattooed on my brain if I could, not because I like writing classes but because I like writing code.  But I'd rather create cool things than write code.  So why am I spending more time writing code than creating features?  Why am I writing about writing code?

My current nice theory is that it's easier to focus on code quality rather than features.  Features aren't very meaningful without a user.  Most development time is spent without users surrounded by other programmers.  Nobody knows what features users want.  User experience is confused by the developer's gestalt of a product.  Features take a lot of time to get wrong and are hard to get right.

My real current theory (the mean theory) is that it's easier to be a code douche.  The defining characteristic of the code douche is that he's more interested in purity than results and more interested in ideals than reality.  This is harsh, but my straw man argument applies to me especially (unless you're a bigger code douche than me).  I love harmony, efficiency, and simplicity but these ideals too often become a liability rather than an asset.