Wednesday, October 31, 2007

You Must Unlearn What You Have Learned

People don't realize that the hardest part of being a Rails programmer is being humble.

When I decided to learn Rails, I said to myself, OK. Here's this thing somebody younger than me made, which is much more successful than anything I've ever done. (And already at that time it was.) So this guy must know some things I don't, and more than that - this guy's way of thinking about the Web works better than my way of thinking about the Web. So what I really have to do is stop thinking about the Web the way I used to, and instead learn to think about the Web in the way that DHH thinks about the Web. So how can I figure it out?

I think most people wouldn't be able to do that. I had to re-examine all my assumptions about how to build a Web app, and that's a lot to do. To really re-learn what you already know? It takes incredible humility, and most people just aren't as humble as I am.

(thankyouillbehereallweektrytheveal)

How To Make Blogger Less Horrible

Blogger isn't the best blogging software out there. If you've started a blog here, you already know that.

Eventually I'm going to move everything somewhere better, but in the meantime, there's one very powerful anaesthetic technique which removes a lot of the Blogger pain. Neal Ford blogged it, referring to James Gray's TextMate book: the TextMate "Edit In TextMate..." feature. It's almost like an emacs client for Blogger. It's not - it's just a TextMate client - but it sure beats the hell out of Blogger's UI.

I got this book when it first came out, but I think I must have skimmed parts of it, because I'm constantly surprised by "new" things TextMate's always been able to do.

Tuesday, October 30, 2007

s3 & irb ftw

Jeff Atwood posted a link to a gigantic graphic of the entire first level of Super Mario Brothers. Unfortunately, because Jeff Atwood gets a ton of traffic, the link is now dead - bandwidth exceeded.

My Seaside screencasts are doing the same thing for people who go to see them, but I've got a solution ready, and I'm already using it on images.

This is me uploading two images to Amazon S3 for my blog:

%w{amazon_email.jpg amazon_customer_service.jpg}.each {|jpg| upload jpg}

All in one line. Nice. It could be probably be even terser with Raganwald's String#to_proc.

In a few weeks I'll be packaging up my absurdly-customized .irbrc file - nearly 350 lines of code - as a gem. For now, here's an abridged version which makes it clear how easy this particular blend of special sauce is to cook.

(Ironically, the images in the example are screengrabs of Amazon's customer-facing systems counterbalancing S3's awesomeness with equally intense lameness.)

Why I Love The 37 Signals Idea That Developers Should Do Customer Service





Update:



There was a time when a major part of my working life was convincing other people that one day the Web would be a place where people did business. Priceline and Amazon made this part of my job amazingly easier at one time, and for years I've been grateful to them. As of today, that gratitude officially ends with Amazon. I'm going to favor Borders over Amazon every time I can. (Priceline already made me an enemy for life a few weeks ago.)

Update 2:



Update 3:



Update 4:



Thank God.

The gigantic corporate behemoths are the part of the tech industry I don't like. It's really got nothing to do with tech per se, though. There's no economic disincentive to polluting my inbox, so, tragedy of the commons, everybody's inbox gets polluted. QED, etc.

Update:

It's impossible to log into my Amazon account now. The "forgot password" page requires you confirm with your credit card number; it doesn't recognize my credit card number. It seems to have actually transferred my account to this other guy when he told them my e-mail was his.

I bet that's an interesting way to find things out about strangers.

Los Angeles: Takashi Murakami Exhibit



The greatest artist in the world opened an exhibit in Los Angeles last night (with a musical performance by one of his most famous fans). I missed it, but it runs through to February 11th next year.

Rumsfeld Flees France, Fearing Arrest For War Crimes

Former U.S. Defense Secretary Donald Rumsfeld fled France today fearing arrest over charges of "ordering and authorizing" torture of detainees at both the American-run Abu Ghraib prison in Iraq and the U.S. military's detainment facility at Guantanamo Bay, Cuba, unconfirmed reports coming from Paris suggest.

U.S. embassy officials whisked Rumsfeld away yesterday from a breakfast meeting in Paris organized by the Foreign Policy magazine after human rights groups filed a criminal complaint against the man who spearheaded President George W. Bush's "war on terror" for six years.

Under international law, authorities in France are obliged to open an investigation when a complaint is made while the alleged torturer is on French soil.

So far this is only appearing in the real liberal media. Hopefully it shows up on the mainstream radar soon.

Monday, October 29, 2007

TextMate Footnotes: Ultra-Tiny Patch For Rails 2.0 Compatibility

Duane Johnson's awesome Footnotes filters footnote visibility on file extension. Use this ultra-tiny patch to enable Footnotes on Rails 2.0 preview.

Update: George Anderson significantly improved on my patch and Duane Johnson added our changes to Footnotes edge.

Desktop Tower Defense: Win With YouTube

Desktop Tower Defense is a crazy-good, crazy-addictive game. I used to play this game all the time, but I never actually put any effort into winning. Yesterday I beat Easy and Medium for the first time, and got to level 50 in Hard. (Of course I also played Easy yesterday for the second time ever.)

If you're stumped on how to win, go on YouTube and google it. You'll find a gazillion short videos of winning strategies. You can also check the DTD winning maps page for winning strategies in their final form.



Go to DTD and play in Fun/10K Gold mode. This will give you the ability to precisely re-create any winning strategy you want, tower by tower. But it doesn't actually give you enough towers and upgrades to guarantee a win. So, you copy successful strategies, and then see how long you can stay alive copying somebody else's strategy. This makes it easy to figure out what makes the strategy successful.

Then copy that strategy in a real game.



Then modify the strategies you're copying, because they won't work for you exactly. I did this and pretty soon ended up with a unique strategy that had nothing to do with the models I was copying. To make those models work, I found I needed sniper towers; after a few more games, my system for winning revolved entirely around sniper towers and long mazes, with a little support from centrally-placed typhoon towers, plus a few anti-aircraft towers and freeze towers.

(By the way, the essential uselessness of the above description really demonstrates why beating DTD is a killer use case for YouTube. Sometimes showing is much easier than telling.)

Sunday, October 28, 2007

Political Identity Linked Directly To Neurobiological Variation

Frank Sulloway of the Institute of Personality and Social Research at the University of California, Berkeley, who was not involved in the study, said results "provided an elegant demonstration that individual differences on a conservative-liberal dimension are strongly related to brain activity."

...

Pollock saw another benefit to the findings: if political attitudes are tied to neurobiology, it would make bashing conservatives — or liberals — pointless. Perhaps they are not making a choice. Perhaps it’s how they’re built.

Link, link, link.

Science Fiction: Risk-Taking Geopolitics?

Anybody know of sci-fi that takes risks with geopolitics? I would love to read something good set in an Africa heavily populated by the Chinese, with Japanese military robotics playing a key role.

Just wondering.

Saturday, October 27, 2007

Everything You Think Is Wrong

Yes, you. That's right - you.

(Just in case there's anybody still reading who I haven't offended yet.)

Latest Idiotic Screenplay: Tuna Mammal Sandwich

This one's only two pages long. It's got absolutely nada in the way of description, characterization, or location. That's deliberate; it's supposed to be ultra-simple, more an acting exercise in ludicrous dialogue than anything else.

Download it here

Friday, October 26, 2007

Apple's Ruby: Communities, Not Features

Apple supports Ruby and Rails very enthusiastically, and Laurent Sansonetti makes an awesome liason between Rubyists and Apple. There's definitely real belief in Ruby at Apple, and that's awesome.



But everyone who uses Ruby on OS X knows that you can't use the version that ships with your machine. Apple's upgraded its Ruby support for Leopard, and that's cool - it's good that they finally fixed the problem people were complaining about in 2005 - but there's a fundamental flaw with the whole idea. Nobody's complaining about that problem any more, because we're all using up-to-date installs, in most cases thanks to MacPorts. Apple tried to fix the problem from 2005 and just created a different problem for 2007.

Apple's latest OS ships with an improved Ruby, but it's not an un-crippled Ruby - it's just a less-crippled Ruby. Apple set up a custom install so they could get the latest Ruby into the latest OS X. They included features in their build that were not even part of any official release, as of that build. But they also skipped over the gem_server function of Ruby gems - which gem server replaces in the next release. I'm already using a pre-release version of that next release on my machine; that release is not far away. They installed Rails 1.2.3 as well, and the next release of Rails (2.0) isn't far away either.

The next release is never far away in fast-moving open source communities, and the Ruby and Rails communities both fit that profile. The Ruby and Rails schedules operate totally independent of the OS X schedule, and lumping the three of them together in any way at all is illogical wasted effort. This happens because Apple thinks they're adding a feature to a product. They need to realize that isn't the case. What they're actually doing is supporting a community which uses their platform.



As a feature on a product, the improvements to Ruby support on OS X might have looked great before the product shipped - it must have seemed brilliant a year ago when they were planning it - but in real life, the only people who want this "feature" on this "product" are the members of a community who will modify the platform if it doesn't suit their needs. And obviously, it won't suit our needs. Giving us something functionally useless which still requires manual package management is really just silly.

Compared to what they gave us last time, what they're giving us this time is great - but that comparison is a mistake. They shouldn't compare what they're giving us to what they gave us before. They should compare what they're "giving" us to what we're actually using. What they would realize if they did that is that we never use the Ruby they provide us, because it's always inferior to the Ruby we can install ourselves. Therefore, "giving" us anything (except real package management support) is just a silly waste of time.

What Apple really needs to do is say, some of our customers are regular humans who want a product with features, and some of our customers are open source power users who want a powerful platform. By failing to recognize the existence of this second group of customers, they've released an OS which provides shiny new features for open source power users. But open source power users build their own features - by definition - and this shiny new "feature," Ruby and Rails support, is almost already out of date, on the day of its release. Over time, it's absolutely guaranteed to not meet the community's needs, because the basic assumption Apple made was wrong.

Apple needs to make a fundamental distinction between features they provide and communities they support.

If they had made this distinction before they released the iPhone, they could have avoided an utterly correct class-action lawsuit as well.



Steve Jobs is very, very smart, but if you think about it, it makes perfect sense that a company founded in the 1980s still thinks of software as something that comes from big companies and goes out to itty-bitty consumers. This is basically the broadcast model, and nearly every tech company in business today knows that the broadcast model lost a lot of ground when the Web became mainstream. There still are millions and millions of consumers out there who want products with features, but that doesn't apply to anybody who buys a Mac so they can develop Ruby apps. Supporting a community is fundamentally different from providing consumers with features. In 2007, that should be obvious.



We shouldn't have had to write our own package manager, either. It's awesome that Apple embraces open source, but it would be cooler still if they understood it. In practice all this is easy to circumvent, but we shouldn't have to work around our computers to be productive. If we wanted that kind of frustration, we'd be on Windows.

Update: Chad Fowler says I jumped the shark. His note about updating Rails is true, and kinda obvious, actually - whoops - but in terms of the things in the comments about user control of the upgrade path, I think I've actually got a point. Both Chad and Apple (with Leopard's Ruby support) have done great things for the Ruby community, and I hate to be arguing with either him or Apple's awesome engineers, but I think fundamentally my critique stands. Apart from anything else, it applies equally well to the battle Apple fought and lost over third-party apps on the iPhone. The iPhone is primarily a consumer product, but it is also a powerful developer platform. Apple failed to recognize the second part of that, and made a lot of their own customers and developers angry in the process.

If you're just reading this to figure out whether or not you should use Ruby on Leopard, by all means, go with what Chad says. He's installed Leopard. I haven't. He's talking about Ruby on Leopard, and nothing else. I'm not. Apple definitely deserves kudos for the Ruby support, I called it awesome like ten times. But it's not perfect, and the imperfections highlight something deeper and more important.

Apple has a decades-long history of issues with third-party developers. That's what I'm talking about. It's not a new thing, and it's not constrained to Leopard's Ruby support. I remember reading similar anti-Apple screeds before I even got to high school. (I had weird reading habits as a child.) Apple has always had this attitude towards developers. It was bad in the 80s, but in a day and age when the line between customers and developers has grown much more blurry, it's really time for them to rethink that.

Update part 2: Rich Kilmer posted a very awesome and useful correction on the ruby-talk list. I stand corrected.

What I Learned From The Series Of Tubes Today

Sinatra looks kewl.
Scriptaculous 2.0 will r0x0r.

Thursday, October 25, 2007

Ruby Iterators And The Law Of Demeter

When you iterate over a collection, you're interacting with the collection in an OO manner. Using integer indices to access a collection's contents sequentially violates the Law of Demeter.

Here's a simple Ruby collection iteration:

collection.each {|element| do_something.with(element)}

Of course this comes straight from Smalltalk:

Collection select: [:each | each doSomething]

Compare this to a typical JavaScript iteration idiom, which has very close parallels in Java, C, and many other languages:

for (i = 0 ; i < collection.length ; i++) {do_something_with(collection[i])}

Obviously as a Rubyist I'm going to say the Ruby/Smalltalk approach is much cleaner than the classic Algol-style syntax, which tangles the implementation of iteration into the act of iterating itself. But syntax doesn't matter here. It's what syntax gives you that matters. In this case, what matters is the habit of mind this syntax trains you in.

Nobody sits at their desk going, hmm, Law of Demeter. Should I break it? Or obey it? The value is in the fact that once an object conforms to the Law of Demeter, you can start to think of it as self-contained. Which means that you don't think about it at all - you think with it.

In practical terms, Ruby programmers generally only step through collections sequentially, using integers, when the problem space involves integers. If the problem space requires you to go through an array, you just say "go through an array" and let the Array handle the details. It's kind of like subliminal training to always write clean code. The more you build the habit of matching problem space to terminology, the cleaner your code gets.

Wednesday, October 24, 2007

Use Case for Automated Anonymity

Opponents of anonymity protection online tend to think that if you're not a criminal, you can't benefit from anonymity.

However, anonymity also protects people who fight spam:

researchers who have managed to glean facts about the [network of hacked machines and system for hacking it] are reluctant to publish their findings. "They’re afraid. I’ve never seen this before," Korman says. "They find these things but never say anything about them."

Technical Certifications: What Kind Of Bullshit Are They?

Attention-grabbing title, but it's a real question. Technical certifications are either offensive BS, or funny BS, and your answer to that question will determine whether or not you get any.

In Japan there's now an official Ruby language certification, backed by none other than Matz himself and prominent Ruby contributor Shugo Maeda. I think it's very likely that Matz' certification isn't any kind of BS at all. It's pretty safe to imagine that the Japanese certification backed by the language's creator carries more weight and operates with more honesty than American certifications, which are usually backed by some large corporate vendor with a serious vested interest.

But wait! Behold my hypocrisy. I have two certifications, both American. And I'm actually planning to get a couple more.

My existing certifications are in Java and XML. The certifications I'm planning are in Final Cut Studio Pro and Adobe After Effects. The reason I'm looking into more certifications is not out of some cynical pro-BS attitude. I'm going to look into getting side work on weekends doing editing and motion graphics. A certification's less valuable than actual work experience, but more valuable than nothing.

I got my Java cert because I needed some cash, I had just moved to a beautiful but utterly backwards part of the United States, and some idiot recruiter for an Air Force contract told me they couldn't offer me anything because I didn't have a Java certification. I thought, okay, how hard can that be? And I went and got one. It proved to be utterly useless in terms of getting a job, but I enjoyed it, so I went and got another one, this time in XML.

Certifications are lame, it's true, but if you're a big enough dork, they're also fun to get, they're an entertaining little ego boost, and they give you good perspective. I wouldn't recommend taking them seriously, but I definitely would recommend getting them if you want to understand the technologies involved. They almost always have some weird corner case you won't see in real life but you could see on the exam.

Obviously, I see no harm in certifications, but many people do. I think the real reason for hostility against certifications has absolutely nothing to do with their usefulness or non-usefulness. I think they're useful, although less authoritative than they claim to be. I think the reason people hate certifications is that an attempt to be authoritative implies an attempt to be an authority, and for a big fat corporate beauraucracy to assert authority over independent programmers is total bullshit.

The question is, is it funny bullshit, or offensive bullshit? People who think it's offensive BS hate certifications. I think it's funny BS, so I get them anyway, every once in a while.

The reason I get them is that they're educational, especially if they make you study and they ask difficult questions. If it makes you learn the language in detail, it can be good. It was over a year after getting my XML certification that I actually used XPath in a real-life work situation, but when that time came, I did it from memory with no problems at all. It was all still in there.

Also, I recently took the Pragmatic Studio's TDD with Rails training. Joe O'Brien asked, "how many people use XPath?" and a few hands went up. The next question was "how many people know XPath well?" and I think my hand might have been the only one still in the air.

Not only that, the number one reason I liked Rails when I first saw it is because I had looked into getting a J2EE/JSP certification. They make you learn all of the JSP APIs, and it's like this archaeological dig. You go down a layer, there's a terrible API that you wouldn't be able to use
in real life. You go down another layer, there's an even worse API that you wouldn't be able to use in real life for the same reasons, plus additional reasons. Then you do it all again. There's this whole sequence of terrible APIs stacked on top of each other, where Sun came up with something, it sucked, and then they came up with something completely different instead, which sucked only slightly less, but still continued supporting the earlier thing, because they couldn't admit it sucked, and they had customers on it. And the funny part is, you don't just have to learn all these crap APIs. You also have to learn Sun's excuses for them. I'm serious. Those are questions on the exam.

As long as you actually think about what you're reading, studying for the JSP cert is an incredible education in how to fuck up Web APIs really, really badly.

After a certain point, of course, I decided against getting that particular certification, but I definitely think studying for it made me a better Rails developer a year or two later. There's a lot of Rails developers who never learned Java in their lives, and never will, but who sneer at it and laugh about it when they really don't even know what it is. The problem is, Java's mistakes are history. Those who don't learn history are condemned to repeat it, and that's exactly what uninformed developers do. I've seen it happen a million times. Even programmers who know Rails internals well sometimes don't have similar knowledge of any other system.

Anyway - many developers disagree on the question of whether technical certifications are offensive bullshit or funny bullshit, but a third group doesn't think they're bullshit at all. This group is way off. The members of this group tend to be inexperienced, young, and/or originally from a country where people in positions of authority act with greater integrity than American corporations do.

Long story short, if you're taking certifications seriously and at face value, you're getting ripped off. But if you just say look, here's this cheap little test, it might be fun to take but it won't be fun to take twice, then you learn something and you enjoy it.

Tuesday, October 23, 2007

What "Hating America" Really Means

One of the interesting differences between the two groups of people in the American political system who spend lots of time talking about each other and very little time listening to each other is that the "conservative" ones usually want to make their audience angry and the "liberal" ones usually want to make their audiences laugh.



The "liberal" ones have a really easy job, because the "conservative" ones are so into making their core audience angry that they don't even care about making sense to anybody else. If they speak to the other side at all, it's only to pick fights.



One of the crazier statements to come from the "conservative" side is that various Americans hate America.

This group of people which claims this, they've kind of always had a weird denial that their interests are specifically their interests. It's kind of like how Christian fundamentalists angrily protest that teaching evolution threatens their society. They never actually do it accurately. They always say that teaching evolution threatens all American society, as if their religious beliefs - and indeed, their seriousness about religion in the first place - were a universal American thing. Teaching evolution is no threat at all to American society, but it really is a very serious threat to their particular sub-culture.

I think the idea that their sub-culture is a sub-culture would offend them tremendously, but I can't figure out why. It seems pretty obvious, just in terms of sheer numbers. I've also never been able to figure out whether this was a malicious denial or merely a foolish one. Are they actively opposed to acknowledging other Americans are also American, or do they just really not know?

Either way, the key to understanding the "XYZ hates America" madness is that it's never meant for XYZ to hear. These people aren't interested in communicating with XYZ. What they're doing is saying to their core audience, "XYZ is an enemy. Don't pay attention to anything they say." It isn't about making sense. It's about spreading panic and fear, and drawing a line in the sand. This is why the "liberal" commentators like to be funny. Laughter dismantles panic and fear.

As far as I can tell, the biggest point of argument between "liberals" and "conservatives" in American politics is whether to laugh or fight.

I would say that the "liberals" win absolutely, except for the fact that the "liberals" never seem like they want to make the "conservatives" laugh too. And that really makes the entire thing massively dysfunctional. There is no voice of reason; there's just insane paranoia and dismissive laughter.

I think the "conservatives" are wrong about everything, except that we should take this division seriously.

No RubyConf For Me

Pretty terrible news for me, but I had to cancel my RubyConf registration. (The good news is some lucky waiting list person is now going.) The reason is simple. It's a Kathy Sierra situation. The flame war about my debuggers post got so violent that I'm scared to leave my house. I've even received death threats.



Just kidding. Actually, my whole "consult and then do art; lather, rinse, repeat" lifestyle requires more financial common sense than I actually possess, and I ended up hosed. Spent too much money; can't go.

Just in case anyone was wondering.

Monday, October 22, 2007

Ruby Language Extension: with "keyword"

Dan Yoder posted something really neat and compact on the ruby-talk mailing list:

module Kernel
 def with(object,&block)
  object.instance_eval &block
 end
end

with([1,2,3]) { length } # => 3

The usage comes from Pascal and JavaScript. The performance cost of eval means you should be cautious about overusing this idiom in production code, but I definitely dig it.

7 YouTube Use Cases Unrelated To Viacom

Not a rebuttal to Jeff Atwood's claim that copyright violation is the only reason anyone uses YouTube. Just several counterexamples I've seen in my own usage. Some of them do involve copyright infringement, but in unexpected ways, or ways which are obviously beneficial to the copyright holders.

1. Tutorial Videos

For instance, how to make a reece in Reason. I watched this, and found it very useful, although I think he leaves out an important step, which is adding a Subtractor with low sine wave oscillators to generate sub bass, which is ultimately even more essential to drum & bass basslines than texture. There are pages and pages of these things.

2. Weird Inventions

Particularly popular in the Ableton Live and Lego Mindstorms communities.

3. Actor Demos

I posted about "the iocaine powder defense" in Werewolf the other day. (As far as I can tell this a term Jim Weirch made up.) While googling for pictures of the actor who played Vizzini, I came across a kid re-enacting the entire scene. Although his "English accent" is a bit off, when he's playing Wesley/The Dread Pirate Roberts, he captured some of Vizzini's facial expressions with uncanny accuracy.

There's copyright infringement here, it's true, but it isn't the copyright violation Viacom's talking about, and nobody's going to make a YouTube re-enactment which outsells the original.

4. Funny Animals

Copyright infringement was the YouTube killer app for me, not too long ago. Then two things happened. First, Viacom got all the Daily Show clips taken down. For months I didn't go near YouTube. Second, the breakbeat producer Miyagi posted on a breakbeat discussion board that when he gets bored he googles YouTube for "funny animals." This just about changed my life.

5. Teenage Girls Dancing

I don't really understand this, but it's a whole subgenre. They usually can't dance, and they record the music with their webcams, so it sounds awful. I'm not saying it's a good use case, but it's certainly a popular one.

6. Music Videos & Just Music Itself

Like re-enactments, there is copyright infringement here, so technically it supports Jeff's argument, but the music companies never pull videos. They know it sells. Like re-enactments, a music video on YouTube is more likely to advertize a piece of music than to replace it.

7. Amateur Music Videos

Some of these involve copyright violation, some of them don't. Either way, they're very popular: people love music. In some cases these lead to CD sales.

Long story short, Viacom, by valuing their lawsuit at $1 billion - close to YouTube's $1.65 billion purchase price for Google - is asserting that most of YouTube's value comes from their content. I think Viacom - and the entertainment industry in general - does have a very argument to obtaining some portion of Google's advertizing income from YouTube clips made out of their material, whether remixed or not, but probably not as much as they think.


Update: bonus use case: making people think about Web 2.0. Michael Wesch's videos for the University of Kansas media literacy program are groundbreaking.

Large Corporations Do This All The Time



From Bug Bash (written by a Microsoftie)

Unfinished Novel: How I Died

I wrote most of a novel in 2001 and 2002. I'd say I got about two-thirds of the way there, although I'm including the work of outlining and figuring out the story. In its current formatting the actual text runs only 76 pages.

The name of the novel is "How I Died." It's based heavily on the history of Ecstasy and the rave scene of the early 1990s, and set in a world with elves, minotaurs, and dragons, where pirates will steal your monkey, all dwarves are born impervious to hangovers, and vampires stalk the city at night. Although it's unfinished, it's only the actual text that's unfinished; the story itself is finished, so I added a short overview of the missing chapters at the end so that anybody who wants to read it will in fact get a complete story out of it.

This sat forgotten a long time. I realized recently that a lot of people read my writing these days. They come for useful programming stuff, not fiction, but I thought what the hell. I decided to put it out in PDF format, with a Creative Commons license. It's hosted on Amazon S3.

Download it here in PDF format (328KB).

Sunday, October 21, 2007

Legacy Terminology Considered Harmful (Debugger Flame War Aftermath)

Things we lost in the flame war:

My post
Avi Bryant response
Avi Bryant Reddit comment
James Robertson responses (1, 2, 3, 4, 5)
Patrick Collison response
Rob Teitelbaum (Weekly Squeak) response
Reddit hivemind responses (1, 2, 3, 4)

Fair warning, most of it is not actually worth reading. I got a lot of angry comments from programmers who apparently use debuggers in a lot of languages. I won't waste anyone's time going into detail. I'll just skip to the interesting part: every blog response came from a Smalltalker.

Here's the dumbed-down version of the Saphir-Whorf hypothesis: names matter. Smalltalkers don't like me any more because their "debugger" isn't really a debugger, any more than emacs is really a text editor. Similarly, the most obnoxious blog comment I got wasn't just rude - it was also completely ignorant of the purpose of [T|B]DD, and still misunderstood "testing" to imply checking completed work for errors.

In either case, the problem was legacy terminology.

Calling the Smalltalk "debugger" a debugger is legacy terminology. Calling emacs a text editor is also legacy terminology. Referring to automated specification verification as "testing" is, you guessed it, legacy terminology. Industry-specific jargon is, in a vernacular sense, code. Therefore, legacy terminology is legacy code for humans.

The flame war is probably over by now, but just in case, I'm closing comments on this entry. I know this makes some readers angry, but it saves me a lot of time. Flame wars don't involve a whole lot of learning, but this, at least, is a useful thing to extract. Legacy terminology probably causes as much trouble as legacy code.

Erlang: Pragmatic Studio In 2008

The Pragmatic Studio is giving an Erlang workshop sometime next year - Erlang training from Joe Armstrong and Dave Thomas.

Saturday, October 20, 2007

Attention Does Not Guarantee Income

Radiohead criticized in BoingBoing for misusing mp3 giveaway to generate CD sales.

Silicon Valley criticized in the New York Times for conflating users with revenue.

The issue in both these stories is that Internet people believe getting users' attention is enough, and nobody else agrees.

There's an ancient Latin saying that translators are traitors. It has its roots in a similarity between the two words in Latin, but it's survived the ages, because even though the pun has disappeared, the meaning hasn't. Anyone who can see both sides of an issue will turn out to have divided interests. I frequently translate between geek language and business-speak in this blog, and I side with the business people on this one.



Business people can find the Web a weird, even occasionally demented place:

The past few weeks we've felt a lot like the owners of a restaurant that gets a five star review only to have the reviewer rant on about how the restaurant is planning to charge for its delicacies. Shouldn't the restaurant owner just line his walls with advertisements and be happy?

Of course, this sounds silly for an offline business but it is just as ridiculous online. The only difference is that there aren't billions of dollars lined up waiting to fund a bunch of new restaurants. No, restaurant owners are forced to deal with reality right from the start as every business should be - no matter how much capital is available in the short term.

But this "reality distortion field" was probably inevitable. History does, after all, have a silly habit of repeating itself. And so only a few short years after the bubble burst all kinds of private equity is flowing freely, elaborate parties are being held, the froth is building, and once again web companies (and web bloggers) are forgetting that to stay in business there needs to be revenue beyond investor capital and Google ads.

That's AuditoriumA, responding to reviews which praise their application but criticize it for not being free.



Here's the BoingBoing criticism of Radiohead. The part in bold is my emphasis:

Radiohead's "groundbreaking" decision to let fans choose what price to pay for 160k MP3s of "In Rainbows" was just a promotional tactic to boost CD sales, according to the band’s management.

'If we didn’t believe that when people hear the music they will want to buy the CD, then we wouldn’t do what we are doing,’ Bryce Edge of Courtyard Management told Music Week, the UK’s industry magazine.

Whoah, way to ream the trust and goodwill of your entire (online) audience.

BoingBoing might have reconsidered that last part, because for me the bold sentence is only showing up in my RSS feed - I don't see it on the Web site - but there's something kind of insular about this. I think you'd have a very hard time explaining that sentence to somebody who wasn't involved in geek culture in any way. As best as I can translate, they're saying that giving music away free on the Internet with the intention of selling it later in physical reality constitutes some kind of betrayal.

As far as I can tell, that only makes sense if you assume that giving music away for free was an ideological gesture.



I'm not even sure that's what they're saying. It's just the only way I can make these numbers add up. Putting a CD in a store after you let listeners hear your music on the radio for free doesn't mean you've "reamed" anyone's trust or goodwill. If you're just Joe Music Fan Who Loves Radiohead, and you can download their album before it becomes available in stores, that sounds pretty awesome.



If, however, you're Joe Ideologue Who Doesn't Really Care About Radiohead But Is Thrilled To Have A Big Name In Music Jumping On The Free Music Downloading Bandwagon, finding out it was just a promotional ploy could indeed involve a sense of betrayal.

It adds up, I think. One thing I know for sure, it's unusual to use the metaphor of anal violation to describe a band selling their music in a store. That's the kind of genuinely insane bullshit that could only come from somebody really smart thinking some thoughts that make perfect sense but just ain't so. Whenever anyone is angry about something cool which made a lot of people happy, ideology is one of the first things to look for.

Ideologies are basically systems for converting difficult decisions into effortless knee-jerk reactions. They're very, very efficient, and they give you the power to reduce endless complex mental activity to a few simple steps, which is why they're so popular with programmers. But just because you subscribe to an ideology that says "downloading music for free makes the world better for everyone" doesn't mean you actually speak for everyone. I think it's pretty likely that Joe Music Fan Who Loves Radiohead isn't complaining about getting "reamed."



The madness in Silicon Valley isn't ideology, however. It's irrational exuberance. Irrational exuberance is easy to explain. You're fresh out of college, you got your first job without any effort or concern, and you know somebody really smart who became a millionaire for reasons that don't make perfect sense. You gloss over the reasons not making sense, because you know those same illogical forces could make you a millionaire too. What you don't know is that those same illogical forces can also hang you and everyone you know out to dry. (And by the time you've learned, there'll be a fresh batch of kids right out of college.)

Just remember, if it seems too good to be true, it probably is.



What's interesting is how these two strange ideas on the Web align themselves with each other. Musicians should value trust and goodwill over CD sales. Internet businesses should concern themselves with getting users' attention, not making money. These ideas are both huge in tech culture, but they're both variations on the same bullshit theme, that attention matters more than income. Let me tell you plain and simple: it isn't true.

BoingBoing's vulnerable to this fallacy because you can't be icons of a culture without picking up that culture's conventional wisdom, and if the conventional wisdom is flawed, yours will be too. The RIAA were such despicable assholes about peer-to-peer filesharing that the tech culture adopted a staunch pro-filesharing ideology in response. Silicon Valley's vulnerability, however, is essentially an economic version of NIH (Not Invented Here) syndrome.

Silicon Valley has failed to adapt to the economic innovations of open source. It is now several orders of magnitude cheaper to launch a successful technology company than it has ever been before. But venture capitalists are basically giving the same amount of money to the same amount of people, even though more people, by orders of magnitude, need less money, by orders of magnitude. This concentrated overspending is why companies in Silicon Valley buy so many toys. They have to spend it somehow.



The problem really is NIH, in an absolutely literal sense - the origins of open source are more in Massachusetts and Helsinki than Palo Alto. Although the culture of Silicon Valley encourages a free-wheeling, cryptoanarchist libertarianism, the region got its start as a tech hub through government subsidies and military research. Venture capital is actually very much oriented to big money, and presumes long, expensive manufacturing and release cycles that to a large extent are irrelevant today (or will be until the robotics boom). People in the tech culture often make fun of the entertainment industry and its total failure to adapt its big-money assumptions to economic realities which are infinitely more agile. What we very infrequently notice is that venture capitalists are making a nearly identical pig's ear of a nearly identical transformation in their own industry. They're doing exactly the same thing.

I think the real reason that Internet companies chase users rather than revenue is that Silicon Valley - or more accurately, Sand Hill Road - is still expecting long journeys to profitability, and simply can't cope with the reality that you can build something in your spare time and get it profitable all in the space of a few months. A few brave startup founders go their own way and skip the VC money, at least until they have revenue and they can call the shots; most take the easy way out. VCs are almost desperate to give out money these days - they even advertize on Google - and turning down large sums of money is hard. You get VC money with users, not revenue; and so it goes.

There are many, many times where going along with bullshit gets you into less trouble than pointing it out, but I do want to point out that this idea, that getting users' attention is better than getting their money, this idea is totally unique to the tech culture, and it's the number one reason everybody else thinks our business people are insane. With my adventures in music, art, acting and screenwriting, I spend a lot more time interacting with people outside the tech culture than the average geek, so, in classic translator/traitor fashion, I'm here to tell you their secrets. The big incredibly useful secret that people outside the tech industry know is that getting money is more useful than getting attention. Now you know, and knowing is half the battle.

Friday, October 19, 2007

Selenium: Self-Documenting Bug Reports

Heard a cool story. A group had a nontechnical business user doing QA. Every time the user discovered a bug, they reported it to a programmer. The programmer asked the user for more detail, and used technical terminology the user didn't understand. The user could never answer the programmer's questions, and the programmer could never reproduce the user's bugs. Nothing got done.

Somebody installed Selenium, and taught the user how to record Selenium macros and save them to files. From there on in, the user attached a Selenium macro file to every bug report. Reproducing bugs became trivial, and communication issues disappeared.

This isn't even what Selenium is for, but apparently they all lived happily ever after.

Ruby Equality: Useful To Remember

>> [1,2] == [1,2]
=> true
>> [1,2].equal? [1,2]
=> false

TDD Quote

Camille Palmer Bell: "Testing is a vaccine, not an antibiotic."

Marketing Is Not Deceit

I've posted many times about programmers and marketing, and especially marketing yourself as a programmer. Many people, in the wake of my "Debugger Support Considered Harmful" post, have been generally furious with me. I have no idea why; however, in the context of this anger, people have often said things like, "His blog is just marketing anyway; he doesn't care what he's saying."

Saying that does not indicate an accurate understanding of my philosophy of marketing, or, in cases where my philosophy of marketing is understood, it indicates a very different philosophy. Marketing is not about lying; acquiring attention for its own sake is not useful from a marketing perspective.

Obviously the idea that marketing would be about lying does not reflect a high opinion of marketing. Prejudice against marketing is strong in the world of programming, and for a good reason. The tech industry pits marketers against programmers. It's actually an incidental effect, in that the old-school "boxed software which ships to stores" model required marketers to push for bullshit features and meaningless releases, and programmers, who generally regard integrity and logic very highly, to say nothing of avoiding inefficient busywork, inevitably resisted that. This created a culture of conflict within high tech, and to some extent that culture persists to this day, even when new Web-based software business models have obviated it.

Frankly, if your philosophy of marketing requires lying to people, I think pursuing that philosophy will inevitably involve some serious disappointment, failure, or frustration for you. Likewise, using that philosophy as an excuse for avoiding marketing yourself at all really just results in a particular type of marketing. You end up marketing yourself as somebody who is "too pure" for marketing.

But in reality, somebody who presents themselves as "too pure" for marketing actually appears as if they don't know or care about business. Marketing is really just communicating information about yourself. The only way to communicate nothing about yourself is to be invisible, or somewhere else. Even standing in a corner being quiet communicates something. The only way to be not marketing is to be not there. So if you say "I'm too pure for marketing," business people perceive you as simply not being part of the picture. In some cases that's a good thing, but in many cases it's a very bad thing.

Marketing yourself as a programmer means drawing attention to something useful that you've done. That's it, and that's all.

Thursday, October 18, 2007

Werewolf: The Iocaine Powder Defense

If you ever want to cause serious confusion in a Werewolf game - good for werewolves, bad for villagers - use the iocaine powder defense.



Everything you could possibly say in Werewolf could be a bluff. Any possible evidence for any possible conclusion - body language, tone of voice, every vote and accusation - could also be a bluff. Therefore any conclusion you come to in Werewolf could be a conclusion you were led to.

If you consider this out loud, and people follow your line of reasoning, you end up so far down a rabbit hole of infinite recursion that it functions like a black hole of reasoning, from which no logic can escape. The only sane thing to do is to abandon the line of reasoning.

You can scuttle any arbitrary line of reasoning this way, as long as people are willing to listen.

(Realize, however, that if a werewolf is putting forward a deliberately illogical line of reasoning, and you point out its flaws, you could be accused of using the iocaine powder defense, even when you're not.)

Rails Debugger: Use RCov With Selenium, Watir, Or Just In Real Life

Jim Weirich and Joe O'Brien came up with something cool today at the TDD w/Rails studio. If you're using RCov to keep your test coverage total, it's useful to realize that rcov is just a command-line tool.

You might be using Selenium or Watir for browser testing. If you want to use RCov to figure out how much of your app actually gets run by your Selenium or Watir tests, it just requires using a few command-line options:

rcov script/server -o server_coverage --rails -x config/boot.rb -- -e test -p 3002

open server_coverage/index.html


Red: rcov command
Blue: script/server args (the -- means "end rcov args")
Black: OS X command to view the output

This will start a Mongrel instance, wrapped by RCov, which will find out how much of the code actually runs, and give you a detailed, color-coded report. Obviously, this technique can be very useful if you're dealing with a legacy Rails code base. Any time the path of execution through the code is unclear, using tools which can easily determine that path makes your life easier. For anybody who wishes Ruby had kick-ass debugger support, congratulations: now it does. In two lines of Unix. (And unlike even the Smalltalk debugger, this debugger only works if you use automated testing.)

Ruby Hashes: Good Programming Habit

When you're making a hash in Ruby, you can add a trailing comma with no problems.

E.g.:

>> h = {:x => :y,}
=> {:x=>:y}

The benefit here is that you can then add subsequent key-value pairs without ever getting those lame "oops I forgot a comma" errors.

Wednesday, October 17, 2007

How To Be Trapped Forever

Street Use is a fantastic blog, almost as great as Street Tech - and undoubtedly inspired by the same William Gibson quote - but this remark just boggles my mind with how fucking wrong it is:

The poor have time but no money; and the rich have money but no time.

If you want something, but you can't get it, you're not rich. If you want something, you can't get it, and you call yourself rich, you're wrong. Being a well-paid serf is not the same thing as being rich. (Also, I can easily find you legions of poor people with no time.)

By this logic, I, personally, am both poor and rich. When I want time, I get time; when I want money, I get money. The above quote is a prime example of how your beliefs control your reality. Believing in a false dichotomy traps you in a false dichotomy.

False dichotomies are easy to spot. They always give you absurd "paradoxes" - for example, rich people who can't get what they want, and people who turn from rich to poor and back depending on their mood. I've been a fan of Kevin Kelly for a decade, maybe more, but this reasoning really freaks me out. It's just so completely wrong.

Debugger Support Considered Harmful

Jim Weirich made a great point today at the Pragmatic Studio's TDD with Rails workshop. He said that when he first discovered Ruby, people asked him about the inadequacies of the debugger, and his response was, "What debugger?"

He was unfamiliar with the debugger because he had been writing tests.

Asking why Ruby has weak debugger support is like asking why a dolphin doesn't have gills. Ruby has weak debugger support because Ruby programmers shouldn't be using a debugger. Ruby supports TDD and BDD better than any other language except possibly Smalltalk. Debugger support is for languages that you can't run tests against gracefully.

Debugger support is like nail-biting support, or farting-in-public support. Its absence is a feature. You want to avoid supporting bad habits. If programmers have to break their bad habits, that's a good thing.

It's also like asking why Lisp doesn't have design patterns. There are definitely design patterns which are only necessary in the absence of particular language features. If you're used to a crutch, you think you need it. Ruby lacks debugger support because it's not limping.


Update: Comments are now closed. I deleted several rude comments and several comments about deleting rude comments. Many comments on this post were aggressive and/or rude. Even the most lucid response I've seen on another blog calls me crazy. Apparently this is a more emotional subject than I realized.

One deleted comment stated that tests were for finding out when things went wrong, and debuggers were for fixing them. I cannot emphasize enough how totally and completely I disagree. Tests have absolutely nothing to do with checking to see if something went wrong. The mere fact that anybody could even think so in 2007 shows the strength of the Sapir-Whorf effect which is the primary argument for referring to tests as specifications rather than tests. Tests are absolutely not for checking to see if things went wrong. They are for articulating what code should do, and proving that code does it.

Another deleted comment referened an excellent screencast on the Smalltalk debugger, custom-created for the sake of this discussion, which I had to delete. Please understand, if your comments are rude, I will delete them, no matter how well-reasoned they are, no matter how polished their presentation, no matter how much I might respect you. Rude discussion doesn't belong here.

For a quick summary, the screencast demonstrated that the Smalltalk debugger works with TDD. Although this was a very cool demo, anyone with any knowledge of Smalltalk's history or the history of TDD knows that, since TDD originated with Smalltalk, and the Smalltalk debugger is famous. So my opinion persists that debuggers work backwards.

Debuggers are based on the idea that the code base has enough places bugs could happen that the work of locating the bug is involved enough to justify machine assistance. This is not true of well-tested code. It is not true of code you understand, either. More importantly, the whole point of [T|B]DD is that you identify the bugs before you write the code. As tools which track down bugs in existing code, debuggers presume and encourage a workflow which is exactly backwards.

It is my opinion that clean, well-tested code renders debuggers unnecessary, and that debuggers arose in the historical conditions which predated [T|B]DD. In that context, debuggers were a useful tool. In the context of well-tested code, specification of the system's behavior can be very atomic, to the point where a debugger is no longer necessary. It was and is my opinion that debuggers are a historical relic of C, and specifically of C pointer mechanics. It was and is my opinion that this historical relic belongs in history books, museums, and Wikipedia screenshots, and that adding a debugger to Ruby would be actively counter-productive to Ruby in the same way that adding C pointer mechanics and re-introducing goto would be.

I think the most important points here are:

1. Debuggers encourage a backwards workflow
2. Debuggers are a historical artifact of C pointer mechanics and primitive flow control

I definitely still consider debuggers harmful. Sorry about the closed comments, and the comments deleted for rudeness, but how much time am I supposed to have? I don't need people stressing me out. I got angry and lost sleep last night. That's absurd overkill. One way or the other, it's just a technique. It's not as if I was talking about your mom or something.

Yet another update: Debugger fanatics might also be interested in an earlier post on Gyre, a Rails debugger written in Rails, a subsequent post on building a ghetto "debugger" out of RCov and Mongrel, and blog responses.

And again: There are definitely smart people who disagree with me; Uncle Bob's similar post in 2003, unearthed in a blog response to a blog response, demonstrates there are also smart people who agree.

Tuesday, October 16, 2007

Build An ActiveResource Schema Dumper

ActiveResource looks just like ActiveRecord, but a lot of the things you get for free with ActiveRecord aren't there with ActiveResource. One major weakness is the lack of association classes.

It's actually pretty easy to add custom methods on the server side which allow you to use find(:include) to return ActiveResource objects with their association class objects attached - for instance, if you write methods on the server side to support it, and patch ActiveResource's find(), you could easily call User.find(1) and get back a User with that user's Widgets attached. ActiveResource find() can do pretty much anything if you just have new keywords dispatch to new get() methods. It delegates to get() methods on keywords already, so you just follow that pattern and you can more or less send it anywhere. The key is the server-side methods that the get() methods call, but those aren't hard. All you really need on the server side is a reasonable understanding of routes and a #to_xml call on a collection which consists of both the User and their Widgets.

But there's a danger there. You might write code which assumes that ActiveResource models, like ActiveRecord models, will return [] or nil for association classes with no content. If a User has no Widgets, @user.widgets should return []. In fact, an ActiveResource application built on this assumption will raise a lot of NoMethodFound exceptions during development. This is especially true if you use ActiveResource models in form handlers. In fact the real danger isn't writing code with that faulty assumption but using it. You're in a controller, using a popular plugin, when suddenly everything blows up because you're missing methods on your models, but you didn't see it coming because they're only missing in some use cases. Even in the context of good TDD, code built on convention over configuration can blow up pretty badly if you're disregarding convention.

ActiveRecord attaches those methods automatically, but ActiveResource doesn't. Remembering to add them manually is pretty counter-intuitive. There's a simple way to handle this. ActiveRecord generates these methods when the application loads. ActiveResource can do the same thing. You need two parts - a server-side part and a client-side part. On the server, you need a method which generates a schema dump from the database, and on the client, you need code which attaches methods to model classes based on this schema dump. This is exactly how ActiveRecord generates these methods under normal circumstances; the only new addition is the translation to XML, for the sake of using a common network format.

On the server side, generating the schema is easy:

ActiveRecord::SchemaDumper.dump

This gives you Ruby. There's a schema_format class attribute on ActiveRecord base; you might think the cleanest way to get XML from here would be to define a new option for that attribute:

ActiveRecord::Base.schema_format = :xml

Unfortunately, schema_format doesn't seem to actually do anything any more. In fact, if you want to dump your schema to a SQL file, you don't even use SchemaDumper; check out railties/lib/tasks/databases.rake for more detail. To dump your schema to SQL, you don't use rake db:schema:dump at all. You use rake db:structure:dump.

Obviously, the correct solution here is to change that. There should be a SqlSchemaDumper and a RubySchemaDumper, each instances of SchemaDumper, which should become an abstract superclass, and Rails should dynamically determine the specific subclass to use based on the schema_format class attribute. But I'm not going to lecture about it; there's no excuse for lecturing about it instead of just fixing it, and I'm not actually going to fix it, so my lecturing isn't worth much.

However, if I was setting up that fix, I'd then add in a third subclass - XmlSchemaDumper. Obviously, this would be the option to go for when writing a server-side Rails controller action to return an XML schema to a client Rails app using ActiveResource.

If you're doing this, fixing the schema dumping process is probably worthwhile; if not, you could do it all ghetto-style and just churn through the Ruby schema dump with regular expressions. That'd be lame, though. In fact this whole thing has me thinking pretty seriously about refactoring this stuff, just out of a general neat freak vibe, but we'll see what happens.

Anyway, on the client side, just to finish up, you get XML (in one way or another) which gives you tables and columns. Obviously, you can map this directly to resources. If your ActiveResource objects correspond directly to your ActiveRecord objects, you're basically home free. The only thing left to do is write a simple bit of Ruby metaprogramming whatnot that takes a list like this:

:users => [:widgets, :other_widgets]

And adds User#widgets and User#other_widgets association methods accordingly. I'm going to skip the details. It's an interesting subject but the post would get too long. In brief, use String#constantize and attr_accessor, and read the final four chapters of "Ruby For Rails" if you don't understand what's going on.

The assumption here is that you're mapping ARec server models directly to ARes client models. This isn't always the way to go. Resources aren't objects, and there are pitfalls involved in treating them as such. Mike Mangino said some pretty interesting things at Rails Edge about how making this distinction, between objects and resources, significantly clarified application design on some of his projects. However, there's a lot of pragmatic benefit in a one-to-one mapping - apart from anything else, you could in theory auto-generate both your ActiveResource and ActiveRecord models/foo.rb files from your schema, eliminating a great deal of repetition. So, if you are doing it this way, model your ActiveResource application load phase on the app load phase from ActiveRecord.



Update: I can't think of any excuse for not implementing this refactoring, except for lack of time, so I may in fact give it a whirl.

Monday, October 15, 2007

Blogspot Line Spacing Gotcha: blockquote, div and line-height

For Blogger users: If you use the quote marks in the GUI, or manually create a blockquote or div HTML element, your line spacing settings will be discarded and the result will be an unreadable mess. The solution is inline CSS. The specific code may vary, depending on your template, but if I open a new div or use blockquote, I then have to wrap all the remaining HTML in another new div and give it inline line-height like this:

<div style="line-height: 1.7em;">

(I am, of course, eventually migrating from Blogger, but I never seem to find the time.)

I'm Bad, I'm Nationwide: Job Security vs. Career Security

Living in New Mexico will do strange things to your brain. For instance, I use Spanglish in irc. I don't even speak Spanish particularly well, and nobody on irc understands it. It's just this weird side effect. Another weird side effect: living in New Mexico can hook you on ZZ Top.

ZZ Top owns the radio in New Mexico. They're on the classic rock stations, the hard rock stations, the 80s stations, the country stations, and even the Spanish-language stations. I have several times in New Mexico changed the station during a ZZ Top song only to land on another station playing another ZZ Top song. I have even more than once changed the station in NM during a ZZ Top song only to land on another station playing the same ZZ Top song. New Mexico radio belongs to ZZ Top. Everybody else is just visiting.



"I'm Bad, I'm Nationwide" is a ZZ Top song. Hopefully you can figure out what it's about, but just in case, the singer's point is that he is bad, and he is nationwide. I also am bad, and nationwide. I'm off to Ohio tomorrow morning, I was in Philadelphia last month and Chicago the month before, and I live in Los Angeles, New Mexico, and Silicon Valley.

This proves I'm nationwide. Let me tell you how I'm bad. I've twice refused to do work because it was boring. Saturday I turned down work this way, and earlier this year I got fired for it. But my baddest moment in the Rails community came when I was banned from the Rails list.

The list moved to Google Groups, and did it without warning or announcement, which bothered some people. I was one of those people. I had the Rails list filtering to the trash based on the email address. The migration broke my spam filters and fuxored my productivity. (For contrast, right now I have four messages, total, in my Inbox. This is normal for me. It takes some serious effort.) So I reported the list admin to Google Abuse for signing me up to a Google Group without warning me. Turns out the list admin was DHH, and a lot of people on the Rails list thought I shouldn't have done that. They expressed this to me with the maturity and good manners many of us have come to expect from the Rails list, I responded at the same level, and DHH banned me from the list.

Speaking of DHH:



There can be no doubt that DHH is both bad, and nationwide. In fact, he's one further: he's bad, he's worldwide. Speaking all over the world about Rails makes him worldwide; responding to enterprise critics with a simple "Fuck You" makes him bad.

It's good to be bad. It's good to be nationwide. It's even better to be worldwide.

How can we apply the lessons of ZZ Top in the workplace?

Obviously if you walk into your boss' office, jump on his or her desk, pull down your pants, and perform toilet functions all over the place, that would be bad. But it would not be nationwide, and it would not encourage becoming nationwide. In fact, it would not really be bad, it would just be stupid. But this silly example highlights a deeper paradox: that which is bad is usually local, and that which is nationwide is usually good.

It's also important to remember we're talking about being bad and nationwide (or worldwide). George Bush, for example, might seem to be bad, and worldwide, but in reality he is merely evil, and worldwide, which is not the same thing. This, of course, gets into the question of the fundamental nature of badness, and such paradoxes as "not bad meaning bad, but bad meaning good." If this confuses you, just remember: Run-DMC and ZZ Top are good role models. George Bush is not.



The reason it's good to be bad, and nationwide, is that job security does not exist any more. Job security, in reality, was never important; it was a proxy, in an earlier version of our society, for income security. Obviously, as much as our society has changed, income security remains important.

Job security no longer gets you income security, but career security might still be a valid goal. Personally, I want to have more than one career, but unlike a lot of people, I don't want to replace the career I currently have; I want to add on a few additional careers that are also interesting to me. This brings up questions like what a career even is any more, and these are valid questions, but that's for another post. Right now I just want to show you how being bad and nationwide (or worldwide) make for career security.



Being bad and worldwide was great for DHH's career. In fact, he was bad and worldwide when he made his "Fuck You" slide, and being bad made him more worldwide. This happened because people notice when you're bad, and being worldwide, or nationwide, or any kind of wide, is closely linked to being famous. I say "closely linked" because being wide is not the same thing as being famous, but it is a similar thing. Wide people are not always famous, but famous people are always wide. When DHH told the enterprise people "Fuck You," he was already famous and wide; this notorious act made him more famous, which in turn made him more wide.

Notorious acts can, however, backfire. When I told the Rails list something similar, it made me more famous, yet it also made me less wide. This is because being bad makes you skinny unless you get away with it, in which case it makes you wide. This brings us back to the toilet functions paradox. Being bad and nationwide at the same time is not necessarily easy.

In fact, at the time, the weirdest criticism I got on the Rails list was that I would never get a job. Several people said it, or something like it. One person said this event would come up in job interviews. (It hasn't.) Another person said that if I didn't like DHH signing me up to receive emails, I should program in Java. Still another person said that if I didn't like DHH signing me up to receive emails, I should program in PHP. I have to wonder how DHH must feel about the idea that choosing to program in Ruby and/or Rails represents a decision about his personality, let alone his email signup technique, more than any other factor. I wouldn't want that kind of responsibility, and fortunately for DHH, I'm not giving it to him. (I also think there's some pretty faulty logic involved in conflating the guy's personality with an inherently impersonal move like migrating a mailing list.) But the important point here isn't rehashing an ancient argument; the important point here is that many people thought what I did would be bad for my career.

Of course they were wrong. There are many people, in fact, who do not feel comfortable hiring Rails zealots. Many companies prefer to hire someone who is aware of shortcomings in Rails. Anybody who's been in technology a long time has seen somebody with stars in their eyes waste a ton of money by using a fantastic technology for the wrong reasons in the wrong context. Experienced managers want to make sure this won't happen to them, and they can't do that by hiring an unquestioning true believer. To a hiring manager in their forties, a hero-worshipping Rails fanatic looks like a starry-eyed teenager with posters of a rock star. Experienced managers don't respect that, because it doesn't lead them to expect reasonable conversations or pragmatic decision-making. You have to remember, rock stars always look silly later on.



In the short term, this little fracas made me skinnier, but in the long term, it made me wider. It encouraged me to further question DHH's wisdom, and I ended up with specific techniques to work around limitations in Rails. That's been useful in projects.

Likewise, when I got fired for refusing to do boring work, that made me wider as well. In fact I ran into the manager who I refused to do boring work for, just the other day, and he invited me to hang out with him. The same company that fired me for refusing to do boring work still let me keep the RailsConf ticket they bought me.

If that seems weird, here's a contrast. Many years ago I was one of the only people to still have a job after the dot-com bust. But I quit that job, moved to the middle of nowhere, and learned to draw. I knew people in technology who wrote me off as a failure because of this and laughed about it. Some even refused to believe I had quit.

The moral of the story is pretty simple. If you walk away from something, and go on to nothing, people think you were wrong to walk away. If you walk away from something, and go on to do well, people think you were right to walk away. (Although learning to draw in the forests of New Mexico was a wonderful experience, there are very materialistic people who will never respect that kind of thing, so as far as they could tell, I walked away and went to nothing.)



Anyway, this is exactly why being bad and nationwide works. Being bad draws attention; if you go on to succeed, lots of people know you're successful. Jay Phillips is bad, and nationwide: he speaks all over the country, and he names Ruby techniques after dangerous drugs. He's got a cool project called Adhearsion, which he may or may not be disillusioned with. Whether he continues the project or not, he's got career security. He's established himself as a leader and an expert, and many, many people know of the methodphitamine.

Like DHH, like myself, Jay Phillips' career security derives from being bad and nationwide. Thus is the wisdom of ZZ Top verily shown. Quod erot demonstrandum, amen. You might be satisfied with the exposition, but if not, you might want to know how you, too, can become bad and nationwide. I'm going to show you, but first, let's look at a half-naked woman in a bear suit with a toy bear.



Apologies to anyone offended, btw. I just like that picture. I have no idea wtf is going on there. I'm not even sure where I found it. I wanted to work it into the conversation logically, but you try that.

To become bad and nationwide, you need to give people something else to talk about besides your badness. Coming up with bad things to do will be easy and fun; the hard part is coming up with something else for people to talk about as well. Nobody would remember the methodphitamine if it hadn't been a powerful technique. If you tell everybody you have a Ruby technique called "The Crack Whore Factory," and your technique turns out to be puts :hello_world, nobody's going to take you seriously. They're just going to think you're an idiot. You have to have something useful and/or valuable to justify the attention.

(This is what Paris Hilton doesn't understand. It's not enough to get attention. You have to do something to justify it as well.)

In a sense, being bad and nationwide is really just a special case of Seth Godin's Purple Cow philosophy of marketing. You get more business, and better business, by being unique; being bad is one way to be unique. But if you're unique, yet not particularly valuable, that's like the pet rock. Your uniqueness may power sales, but only for a brief time. Staying power comes from uniqueness and value.



Speaking of cows, the notorious screenwriter Joe Eszterhas once wrote a screenplay about the President of the United States having sex with a cow. Although Eszterhas had a great track record of writing hits, and an army of powerful friends in Hollywood, nobody bought that screenplay or made that movie. See the pattern? Usually bad and nationwide, Eszterhas was in this case merely bad.

Long story short, the key to being bad and nationwide is to do something useful. Create something new, that definitely came from you, that other people value. Rails, Adhearsion, or even just a blog. This simple step is much more important than most people realize. It has to trace back to you personally, or it's useless for your career. As programmers, we are in the position of working for people who do not have the ability to determine whether or not we are good at our jobs. Even other programmers sometimes have trouble figuring out who is or isn't a good programmer. For potential managers and/or potential clients, the hiring and firing processes are both essentially random, unless you have some obvious distinguishing feature. That makes marketing yourself essential.

I once heard a story about a company where one dedicated programmer did all the real work, and all the other programmers were coasting off his efforts. (One of them even ran a porn site from his desk instead of working.) This programmer usually came in around 10 or 11AM, scruffy and unshaven, so, after a while, management fired him for being unprofessional. Every other programmer there immediately realized that management would eventually learn that they hadn't been doing anything for months, so they all quit too. Management was left with nothing. Nobody would come back unless the guy who did all the work came back, and he wasn't coming back. Even though this sounds like a farce, it's a true story, and it happens all the time.

You might wonder why I'm telling you this, when my best bet for career security is to hunker down and create some wonderful new thing. There's a couple reasons. First, talking about it is easier than doing it. Second, this blog is a wonderful new thing. Third, I'm studying acting and visual FX programming, I'm looking for some time to work on my drawing skills again, I want to finish one of my attempts at writing a novel, and I have a very interesting idea for a side business in hypnosis. (I have very good training in that field.) Long story short, I don't have the time, and this blog gives me all the career security I need in technology for the time being. (Also, at the moment I'm just more interested in learning Seaside, Processing, Rubinius, and Mindstorms than creating something new.) But for those of you ambitious enough to want something more, or cautious enough to want to avoid any career obstacles during the next bust, there are your steps: Be bad; be nationwide; make something cool. They're simple enough to understand. Doing them is the hard part.