Here's a fun quote about AI

JORDAN POLLACK
Computer Science and Complex Systems Professor at Brandeis University

A persistent belief is that human symbolic intelligence is the highest form of intelligence around. This leads directly to both creationism and good old-fashioned AI which seeks to model cognition using Lisp programs.

Evolution can design machines of such great complexity that the space shuttle with half a million parts looks like a tinker toy construction. In order to explain the design intelligence of evolution, most Republicans are convinced that a superintelligent creator was involved. Developmental intelligence which manufactures machines with 10 billion moving parts without any factory supervisors is another area where nature outstrips the best human performance. Immunological Intelligence, telling self from non-self, is another AI-complete problem. And human intelligence itself is so vastly complex that we've made up stories of conscious symbol processing, like logic and grammar, to try to explain what goes on in our heads.

The mind, like the weather, envelopes the brain like a planet and requires dynamical and integrated explanations rather than just-so stories.

from a fascinating thread over at http://www.edge.org/3rd_culture/thaler10/thaler10_index.html by way of http://www.marginalrevolution.com/marginalrevolution/2010/11/richard-thalers-question.html

flickr fixr

Flickr is great but I am impatient, and strangely aggrieved that the page reloads on each new photo view. And I don't care about user comments, tags, etc., only looking at pictures.

I also needed an excuse to finally try out greasemonkey and lo and behold, flickr fixr is born. It feels a bit snappier than the current flickr photostream, but otherwise is a pretty modest first script (~6 lines of jQuery).

That's right, I was able to write jQuery thanks to Joan Piedra, which was a huge timesaver.

Anyway, try it out, see the difference: http://www.flickr.com/photos/floridapfe/2211054334/in/photostream/

My dev environment

I wanted to describe my dev environment and work processes but it wouldn't make sense unless I describe the shape of my work so let me do that first:

Dev Cycle

Our dev cycle is pretty simple: create and checkout a branch associated with a ticket, make changes to that branch, merge it into a master branch, test it on a staging environment, push it live. It's common for a single developer to have several branches in progress at once.

I'm primarily concerned with reading/editing the stack of html/javscript/python/SQL. When I have questions, I lean heavily on log files, ipython, the mysql command line client, git, grep, testify, and a slew of other odds-n-ends. I also run virtual machines, mostly for browser compatibility testing.

In other words there's a set of varied tasks I need to be able to do efficiently and cohesively. Mental "context switching" is expensive so there's value in grouping related work and quarantining anything not immediately relevant. That's the idea, at least, for how I try to manage to complexity of multiple files, branches, documentation, etc. with minimal overhead.

All of this is done using Terminal on a MacBook Pro:



Dev Environment

So the smallest unit is a solitary file, in a lone buffer, in a single tab in vim, .... No file is an island, however, and if I'm doing anything reasonably interesting I'll probably need to view at least 2 files at once.

The next step up then is a vertical split (:vs in vim). If I'm working on a large screen I may split one more time for a grand total of three files sharing the same space. I've got shortcuts mapped in vim so that I can traverse them using Ctrl+H, Ctrl+J, etc.

As I open more files, I start opening tabs (:tabnew). They may stay open, or I may close them again immediately to reduce clutter (I mapped ,tn and ,tc to tab new/close so it's faster to do so).

I may evict existing screen splits and move them into a new tab if it makes life easier. I mapped Ctrl+I and Ctrl+O for navigating through tabs left and right. Again, judicious closing of tabs can make life easier.

Ctags is also useful for navigating, as are other plugins such as NERDTree. I use a few vim plugins; they should be a separate post though.

I am also doing all of this in a screen session. Each branch I'm actively working in will have its own virtual terminal, which I navigate using Ctrl+a. When you return to the original branch you were working in, it'll be just as you left it, and therefore easier to resume.

I'll also use screen to keep separate terminals open for tailing logs, running ipython/bash/sql commands, etc.

Also, all this work is taking place on a remote machine. If I need to work locally or connect to a different machine, I open a new tab in terminal (cmd+T) and proceed from there. I switch terminal tabs using cmd+{ or cmd+}.

The stack tops out with Expose/Spaces. I rarely need to use it extensively but I'll use different spaces for different browsers and running virtual machines. These are navigated using Ctrl+(arrow keys).

Oh, and I also use terminal in transparent mode (the "Pro" color scheme specifically). You can read documentation or examples without turning your head!

Summary

Here's what it looks like in action:

• 2 files side-by-side


• 2 other tabs open (the gray tabs on the top)


• Another active screen session (green bar)


• Another tab open in Terminal


• Transparent terminal for readin' docs

the full stack / hotkeys:

vim file < vim split screen < vim tabs < screen vterms < terminal tabs < spaces
n/a < ctrl+h/j/k/l < ctrl + i/o < ctrl+a n/p/# < cmd+{/} < ctrl+(arrow keys)

Automated tests saved my project from chaos and ruination

File this one under "Obvious" but I wanted to specifically describe how tests made developing against a brand new platform not just easier, but possible.

Over the past few weeks I've been developing against the spanking new Facebook Open Graph API that was released yesterday (the Like button specifically).

Facebook was developing the API at the same time we were. Many things were subject to change, including feature designs, the external API, and our own API wrapper. Chaos may have ensued, but for one rock upon which I clung: the tests I wrote early on (but not first!) for the Like button.

When when things shifted, it was a simple matter of fixing test failures. If the specification changed, I already had a solid test framework that was easy to reuse in order to account for new or different behavior.

It may seem obvious but those tests were worth their (figurative) weight in gold. We had little time and changes came frequently. We couldn't afford to miss the fact that we left something broken. And manually verifying the feature became infeasible and would take precious hours we didn't have.

Best of all, when Facebook flipped the switch and the feature went live following the keynote, I could breathe easily knowing that I had tested the hell out of it before millions of Facebook users would get to do the same. Yet another reason in a sea of reasons why tests are valuable.