Monday, November 12, 2007

The Nerd Handbook

You've probably already seen The Nerd Handbook on Digg, but just in case you haven't, go read it.  It's great stuff.  As a geek (I've always preferred geek to nerd) married to a non-geek, I'm always on the hunt for things that describe us (geeks, that is) that I can point to and say "See?  That's how we are."  Way back in the day, the Jargon File / Hacker's Dictionary came with appendices that described the typical hacker, the sorts of food they ate, music they listened to, and so on.

Then there was Seebs and his classic "Hacker FAQ" where we got the oft-quoted "managing hackers is like herding cats" and "if you get a hacker on a project he really likes, expect him to be 10x more productive than a normal worker."

The Nerd Handbook is different in that it is written for significant others.  It speaks of "The Cave" where your nerd/geek/hacker goes, and why you shouldn't touch his stuff.  Why he hates small talk, and loves a good puzzle.  If it works, the best part of this article is that the author offers advice for the SO on how to optimize interactions with the hacker ("advanced nerd tweakage").  In other words, don't stick your geek in normal situations and say "Be normal!"  Instead, figure out a way to position the "normal" situation as something that appeals to his geeky instincts.  Is there a puzzle to be solved?  Information to be learned?   

Sure, on the one hand it is totally patronizing - "Hacker shy.  Give hacker puzzle.  Hacker happy now."

But in a way, it's only fair.  Because in my experience, most geeks also happen to assume that they are the smartest person in the room, which means we're pretty damned patronizing too.  Start by assuming that no one in the conversation is as smart as you, and talk down to them.  If you sense that someone has some intellect, then immediately the game turns either into a pissing contest to see who is the alpha geek of the room, or else an immediate bond is formed and you've got a friend for life.  But either way, most of the bystanders are left by the wayside wondering what the heck the geeks are talking about.

Anyway.  If you want to see how patronizing the "give a hacker a puzzle" cliche is, try this.  Invite some friends over for a party.  Include a geek.  Now put an unfinished Rubik's Cube in the room.  Watch what happens.  It's like they can't help themselves.  I know I can't - I was just at a party last month where the host set the table around me because I couldn't put the damned thing down until I'd solved it.

Thursday, November 08, 2007

Facebook, IE and IFrames

I test my webapps so rarely in IE that when they break, I assume it is IE's fault.  I'm usually right.  Tell me if this has happened to you:  You're developing in an iframe situation where the master page is at a different domain than the inner page.  This, by the way, is exactly the situation for iframed Facebook applications.  You click on a link in your iframe, and then your frame blows up.

This is because IE's default "medium" privacy setting has an issue with cookies in that situation.  So whatever session you setup for yourself on that first page doesn't exist when you try to click through to the next page of your application.

The solution, as several sites have pointed out, is to set up a "compact privacy policy", or P3P header.  Google for things like "p3p iframe internet explorer" and you'll get all the hits you need for how to do it.

In my Rails controller I added this line:

before_filter  :set_p3p

which is a shortcut for "Before you do anything else, run the set_p3p method".  And, the method:

def set_p3p

   response.headers["P3P"]='CP="CAO PSA OUR"'

end

Presto, it should work.  Right?  Well, no.  At least, not for me.  It stayed broken, and that's where I got stuck, because everything I googled said that should work.

Here's where it got interesting.  Pull up the privacy policy for the page you're on.  IE7, at least, has this over on the far right under the "Page" button, "Web Page Privacy Policy."  This will bring up a dialog box that shows all the URLs that your current page has tried to access, and whether or not cookies are blocked for each.  And it's there that I found something very interesting.  One line - a reference to a Javascript file, of all things - was showing "blocked."  Odd, that, because all my other resources from my own domain were Accepted.

Know what it was?  The Javascript file in question actually didn't exist.  This was a bug that the designer had put in, an old reference to a file no longer used.  So something in IE was saying "You've asked me to include this file, I presumably got back a 404 on it, so I'm going to put it in the blocked category."

Since that file had nothing to do with my ability to login to my application I'm not really sure how it caused the crash it did, but when I took out the include, magically everything began working.  So perhaps IE has a policy that says "If any resources from this domain are blocked, then all are blocked."

Just googling for posterity's sake.  I didn't find anybody mentioning a ghostly blocking of cookies from non-existent javascript files.

 

Ruby Quickies

1)  Whenever you've got a method that returns an array, there's a design question of what to do on no results.  Do you return a zero element array, or nil?  Your code that processes the results will be cleaner if you can always assume an array will come back (that way saying things like "Foreach x in results {...}" will simply fall through if results is empty).  But does that mean that you have to do some ugly conditionalizing inside the method to check for nil and create an empty array?

In Ruby you've got the lovely "to_a" object method.  Run it on an array, you get back the array.  Run it on a single element, you get back [element].  And, best of all?  Run it on nil, and you get back [].  Exactly what you want.

 

2) This is actually a trick that dates back to Smalltalk, but Ruby can do it to so Ruby is cool.  I have a string in my UI, and what I would really like to do, for fun, is replace that with a random choice from N strings.  So instead of just returning "Are you sure?" for instance I might return "Really?" or "Do you want to think about that?" and the like.

Problem - Ruby's array class has no random method.

Solution -  Stick this someplace in your code:

class Array

 def self.random

   self[rand(self.length)]

 end

end

 

And now it does.  Congratulations, you've just extended a system class.  Now you can do this:

["Are you sure?", "Really?", "Do you want to think about that?"].random

and get back a different result each time.

 

 

Technorati tags: