Don't use defaultCStringEncoding

It isn't exactly news that this innocuous-sounding parameter is "considered harmful."
But this fact needs a bit more SEO-juice, so here's another voice speaking out against defaultCStringEncoding:

(from NSString.h):

/* User-dependent encoding who value is derived from user's default language 
and potentially other factors. The use of this encoding might sometimes be needed
 when interpreting user documents with unknown encodings, in the absence of other hints.  
This encoding should be used rarely, if at all.  Note that some potential values 
here might result in unexpected encoding conversions of even fairly straightforward 
NSString content --- for instance, punctuation characters with a bidirectional encoding.
*/
+ (NSStringEncoding)defaultCStringEncoding; //Should be rarely used

write about a song in 400 words or less

Coast to Coast is the first track on Elliot Smith's final, posthumous album "From a Basement on a Hill," and it sets the tone for the rest of the album: disjointed, dense, fraying and beautiful.


http://www.youtube.com/watch?v=bAvqZsRhjwk&fmt=6

Coast to Coast begins with a portion of the song played in reverse. Enter twin lumbering drum tracks and an out of tune slide guitar lead. I've listened over 50 times and just now realized that Elliot's whistling along with the guitar track. His first line: "Last stop for a resolution."

The lyrics are juvenile, but cognizant and self-examining. Elliot has no new ideas and is therefore useless to those who are expecting more (including you!). Instead of deliberate invention, he takes a "kitchen sink approach," and shovels all of his recording and songwriting reserves into the studio cauldron (did he know beforehand that this would be his final effort?).

This "kitchen-sink" approach explains why there's at least 3 guitar tracks, a piano track, a distorted bass, 2 drum tracks, 3 separate vocal tracks, several additional "background" tracks featuring a lightning-speed poetry reading (and whistling). It's chaotic, but its beauty is evident in the way "Coast to Coast" grows and reveals itself with every subsequent listen.

At any moment, the wheels could detach from the wagon and the barely-together instruments which compose the song could careen into the abyss. Yet "Coast to Coast" marches ahead with minor regard for refrain or repetition, as Elliot bemoans that he's "got no new act to amuse you." Its structure is unconventional, and the rapidity of changes suggests a songwriter who is easily bored, or seeking to outdo himself. The droning piano, which would normally have a centering effect, somehow edges us closer to the brink.

At around the 4 minute mark, the poetry track which was submerged in the mix bubbles up. Is it the outside world leaking in? The spoken words supplant us from a musical trance, especially if we reacted to them by yanking off our headphones.

As the instruments slide into a black hole, these voices take over, and the track ends. We missed the last stop; nothing is resolved.

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.

What's wrong with PHP?

Just as it's easy to completely write off a band you don't care for (because they sold out? or their singer meets with world leaders and has a terrible op-ed album in the New York Times), the same often happens with technologies and languages.

For example, there was some point in my life where I told myself I would avoid any project heavily involving PHP.

But why? What's wrong with PHP? Yahoo and Facebook use it...and I haven't used it enough to warrant such strong feelings.

I wanted to explore this (baseless?) apprehension further, and I thought of this characteristically absurd/profound quote from Perl creator Larry Wall:

"Perl is worse than Python because people wanted it [to be] worse."



Larry Wall

The goodness of Perl v. Python is a common religious argument. The above quote squelches the debate once and for all, but begs further questions.

Who is they? Why did they want Perl to be worse? Do the words I added ([to be]) change what Larry actually meant?

Consider this Mind Hacks post about trends and their origins; the concepts extend to any sort of idea that can grow legs. Trends in technology are the same way, and spread because a distant idea reached some critical mass of connectivity and settled in with your own circle of peers.

Developers can vote for or against any technology by speaking for or against it, but their most powerful influence is in choosing which technologies to devote their energies toward learning and improving. Enthusiasm for a project leads to expertise contribution, and contribution leads to enthusiasm.

Conversely, people who have a distaste for a technology will discourage others. They (the technologies) will languish if their community does not grow.

In other words, labeling a technology good or bad is a self-fulfilling prophecy given enough influence and/or critical mass. Soon companies using the "good" technology will flourish with resumes and job postings for "bad" technologies will receive lesser attention, serving only to reinforce existing stereotypes.

I'm largely paraphrasing Paul Graham. He wrote a great essay on this phenomenon, which he calls "The Python Paradox".

I believe this is what Larry was getting at. And it explains my own PHP aversion, as my experiences were underwhelming at worst, but the number of developers I've heard lament PHP convinced me to stay away, as if it's the bad part of town.

Arguing over which language is better or worse is a waste of time; what matters is the consensus of the larger community (see wikiality). Even if it's unjustified. But just like a neighborhood can turn around, opinions change, and that's why phrases like "JavaScript Renaissance" are thrown around. And although I can't shake all the PHP prejudice, I wouldn't make a point of avoiding it (PHP that is), either.