Writing helps me think.

As designers, software developers, and business geeks we thrive on a few things. We seek inspiration. We obsess over details. We work long hours. And we need focus. Computers and software have evolved to the point where nearly anything is possible. It’s an amazing threshold, as we are rarely limited by the hardware, OS, and languages. We’re mostly limited by our own ability to produce. We are the weakest link in our productivity. ...

As a software designer, I love to design software. As software developer, I love building software. When I dream of better things, I funnel my ideas into new projects. When I don’t have time for all of my side projects, the projects pile up in a corner and gather dust. And when a side project is an unfinished publishing platform it gets in the way of writing. I’m intensly interested in writing and publishing on the web. There are just so many possibilities for saying interesting things and making the presentation of those things more useful. I’ve dedicated a chunk of my consulting time to making beautiful interactive sites for non-profits, and I use a slice of my spare time for maintaining a number of my own sites (and those of friends and family). I believe that what we’re seeing on the web today is a shadow of what we will publish in the future, and it excites me. ...

I wrote my first computer program when I was 8. It was a simple adventure game written in BASIC, a mess of GOTO and PRINT statements. I saved it to tape a few times, proud enough of my first creation that I didn’t want to lose it. And despite what I didn’t understand my mind exploded with ideas. I continued to write games and curios into my early teens. I wrote text adventures and arcade ripoffs. I hacked at biometric data collection using a busted set of paddles and mixed mode graphics. I designed and built a large (but clunky) side scrolling adventure game using only a set of customized fonts. I plagiarized code from magazines and hacked at my machine until the wee hours of the night. ...

I review a lot of code these days. It’s an incredible way to nudge a team of bright people toward greatness. It allows me to look at problems from the outside with a perspective of experience and distance from the low level design. The perspective is important too, and I see things that I often miss in my own code. You see, we’re easily blinded when we’re too close to the problems we’re trying to solve. ...

You can pass data between the client and server in a number of ways. I like to mirror data structures between my server and client, so that I have the same basic data model available in both realms. There are a few ways to do this, including: Calling an API that returns JSON (or JSONP) Calling an API that returns some UI, which can include some JSON Getting an entire page that includes your data model in JSON Sending a client data is trivial in most dynamic languages, and PHP is no different. You return a response body with the result of a json_encode and your data model. The technique works just as well in APIs as it does in standard HTML templates: ...

PHP is a great language. It follows a long lineage of C-based syntaxes, mirroring much of the C standard library. It performs well, is trivial to deploy, and has been stable for many years. And, it’s almost universally hated. While many people look down on PHP, it’s worth considering where it shines compared to other languages. I find that in many uses, PHP provides a great set of features and elegance. Not only is it competent, but there are places where it is truly a great little tool. ...

A developer asked me a seemingly obvious question today: I have an API GET request that requires a JSON body. Is that okay? It’s a good question too. It turns out the answer isn’t as simple as it should be. On principle the answer is, “No, it’s not cool”. A GET is an idempotent request for a resource. You don’t request a resource with a resource (what would that mean?), you request it with a resource identifier. The HTTP spec, however, is unclear on the subject and does not explicitly disallow it (it probably should). ...

I’ve been busy working on visual design bits for work projects this summer. My method is simple: Sketches and storyboards Static mockups (HTML/CSS, some Javascript) Live mockups (to test integration and interactions) Uncovering what a feature means is fundamental to the method. It exposes the nouns and verbs of the problem, and hints at the useful metaphors. The freeform nature of sketching and developing storyboards based on this language helps me focus on figuring out what the things mean, as well as finding their shape and rhythm. I end up working on several different approaches before it’s obvious which ones are workable for the client and product. ...

Friction works against you. It exceeds your ability to progress. It deflates you, stripping your motivation. It’s the hill you see before starting a difficult project. It’s the gravity that pulls you away when interest wanes. I’m starting a small project for a client today. It’s a simple set of improvements to something I built for them last year, using a toolkit I wouldn’t normally use (but one that fit their uses well enough). I had forgotten a lot about the toolkit when quoting on the work, and by the time I remember it’s clear that there are challenges ahead of me. ...

One of my favourite JavaScript features is its literal object notation. It allows you to declare data structures in JSON, which is a very succinct, C-like syntax. You can use this notation to declare SETs, and the a in b syntax to verify a variable is in a set: /* Declare your set as a JSON constant */ var valid_widgets = { 'widget-viewer': 1, 'special-viewer': 1, 'widget-editor': 1 }; /* Fail if something isn't in the set */ if ( ! (options.widget in valid_widgets) ) return false; /* Profit! */ As the in keyword operates on the index of the referred object, we set the value of the constants to 1 (true). A bit of a hack, but it results in a very clean way of checking if something is part of a set of valid values. ...