Friday, May 29, 2009

Thursday, May 28, 2009

Recursion Is Easy To Understand

I got tired of all these blog posts explaining simple concepts in unnecessary detail, so I wrote up the simplest possible explanation of recursion.

Want to know what recursion is?

Click here.

Thesis Paper On Algorithmic Composition

I don't think I need this now, but I might need it later, so I'm posting it to archive it. 219 pages.

Wednesday, May 27, 2009

Arson Graf

Dominik Eulberg "Sansula"

Tuesday, May 26, 2009


Whenever I use Prototype's PeriodicalUpdater, I run up against an annoying limitation: the URL you give it to periodically update against is a string, not a function. However, if you're using RESTful or even just old-school id-centric Rails routes, hitting the exact same URL every time means you can't encode any information in the URL which might change over the course of the page view.

For instance, say you're writing a Twitter client. You want to track status IDs and only pull tweets older than a given status ID, since you can safely assume that anything earlier is already on your page. The easy way to do that looks like this:


But with PeriodicalUpdater, you can't ever change 12345 to 67890 (or whatever the most current status ID is). Your options then become either tracking on the server side what tweets the page has already seen, which is a nightmare; or downloading a whole batch of tweets, both good and bad, which you then have to filter through to determine whether or not you want to display them; or giving up and going home. These options all suck. Your one good option is to cut and paste the PeriodicalUpdater code and set it up to take a function instead of a string. Boom, suddenly all your problems are solved, the world is a happy place, and you put it on GitHub.

In terms of code changes per hour of stress averted, lambdas nearly always rock. This class for me today sent away loads of aggravation just by adding a pair of parentheses. I changed a variable name too, but that was strictly icing on the cake.

Speaking At Future Ruby

See you there!

Monday, May 25, 2009

Egotistical Daydream Graf

Haunted Graf

Sunday, May 24, 2009

Vivid Graf

Splotchy Graf



Full-Size (648K)

Friday, May 22, 2009

Bring Power Strips/Squids To Conferences

The Future Ruby web site includes this offhand comment:

We recommend a spare power bar, or an extension cord! Always a great way to make friends.

This is such an easy win I'm going to make it a conference packing rule for every conference from here on in (except conferences outside the United States, where my power squids will be no use anyway).

Thursday, May 21, 2009

Wednesday, May 20, 2009

RMM Will Never Be Able To Leverage Collective Intelligence; Ruby Toolbox Already Does

I feel bad about harshing on Obie's project all the time, but Pete Forde is right:

The reason Ruby Toolbox beats RMM:


RMM makes the same mistake as Hacker News.

Neither RMM nor HN leverages collective intelligence.

Ruby developers can choose from a variety of tools to get their job done.

The Ruby Toolbox gives you an overview of these tools, sorted in categories and rated by the amount of watchers and forks in the corresponding source code repository on GitHub so you can find out easily what options you have and which are the most common ones in the Ruby community.

Ruby Toolbox leverages collective intelligence. By counting watchers and forks on GitHub, you get an objective measurement. RMM surveys people, which means it obtains a subjective measurement. Ruby developers participate in Ruby Toolbox without being aware of it, while each individually pursuing their own goals. RMM users participate in RMM with full awareness and with a collective goal.

Nice Work If You Can Get It

...and you can get it if you try:

We Are Hiring Non-Sexual Male Escorts Now!

The Perfect Date Escort Agency is currently expanding its services to the Los Angeles area. We are in need of sociable and successful men from a variety of backgrounds to work as non-sexual male companions! This might be one of the most interesting and challenging part time jobs you ever take. Not to mention well paid.

Our clients are looking for companionship only and do not expect any other services. Most of our escorts accompany interesting and fascinating women to business and social functions. Our clients enjoy the image our escorts help them create along with the no pressure atmosphere our escorts provide.

The Craig's List ad

The web site

I Loves Me Some Smalltalk

Despite barely understanding it, everything I do get about this language is pretty fantastic.

Concentration FTW

The only time multitasking does work efficiently, Meyer says, is when multiple simple tasks operate on entirely separate channels—for example, folding laundry (a visual-manual task) while listening to a stock report (a verbal task). But real-world scenarios that fit those specifications are very rare.

This is troubling news, obviously, for a culture of BlackBerrys and news crawls and Firefox tabs—tools that, critics argue, force us all into a kind of elective ADHD. The tech theorist Linda Stone famously coined the phrase “continuous partial attention” to describe our newly frazzled state of mind. American office workers don’t stick with any single task for more than a few minutes at a time; if left uninterrupted, they will most likely interrupt themselves. Since every interruption costs around 25 minutes of productivity, we spend nearly a third of our day recovering from them. We keep an average of eight windows open on our computer screens at one time and skip between them every twenty seconds. When we read online, we hardly even read at all—our eyes run down the page in an F pattern, scanning for keywords. When you add up all the leaks from these constant little switches, soon you’re hemorrhaging a dangerous amount of mental power. People who frequently check their e-mail have tested as less intelligent than people who are actually high on marijuana.

Also covered here and here.

Tuesday, May 19, 2009

God's Epic Spreadsheet Of Hats

Many religions prescribe rules for headgear. In some religions, you must wear some kind of headgear at all times. In other religions, you must wear headgear at all times, but only if you're a man. In others, you must cover yourself in a bag, but only if you're a woman. (This isn't a pure headgear rule, but you have to cover your head also.) In other religions, you can wear a hat at any time you wish, or not - it's optional - but you cannot wear a hat in a place of worship. Some religions require a hat, but they don't care what kind of hat. Other religions specify the hat very strictly. A few even use hats to mark rank and status throughout the entire hierarchy of their worldwide priesthoods.

It's easy to see this as an argument against religion in general. But I don't think that's a lot of fun. I prefer to see it as an argument in favor of hats. If there's one thing the religions of the world agree on, it's that hats are more important than a secular person might think. What power lurks in the hat?

Western religions all refer to the same eponymous God. If you take the rules on headgear from Western religions at face value - combine the fact that Orthodox Jews say God wants them to wear a hat with the fact that Catholics say wearing hats in church is rude to God unless you're a Pope - then it makes you wonder what it is that makes hats so powerful, and why God wants these people to only wear this type of hat, while these other people can wear any hat they want.

Does God have a spreadsheet of hats? An epic Excel file with a column for every person who has ever lived, and rows for the hats He wants them to wear? Or I guess the Devil uses Excel, and God is on GOogle Documents. But why do they care? Is there some secret to it all? How awesome would it be if the Devil spent centuries trying to destroy the entire universe by tricking Amish people into wearing yamulkes? Or is it just some weird side bet? Kind of like the book of Job, but for smaller stakes? Maybe at the end of the world they're going to count all the people wearing hats and one of them will give the other one fifty bucks.

The power disparity between man and deity makes this interesting. I wouldn't sell my soul to the Devil for all the riches in the world. But I'd consider wearing a hat if the price was right.

Monday, May 18, 2009

Beware The Broken-Hearted Mechanic

We've all been there. Your client will pay you to develop new features, but they won't pay you to refactor. It makes you nuts.

Here's the worst-case scenario.

This isn't just a worst-case scenario because the client fires the developer. It isn't just the worst-case scenario because the developer suffers a nervous breakdown and decides to work on the app for free. It's the worst-case scenario because the developer utters the words "overhaul the entire codebase." Once you go there, you're fucked.

How do you avoid becoming this guy? One way is to simply have clients and managers who trust you when you say the dreaded word "overhaul." But that's hard to predict. At best it'll vary on an overhaul-by-overhaul basis, and overhauls cause terrible stress and boredom at the same time. There has to be a better way.

I read something interesting on the Web which said that Toyota introduced the model of regularly scheduled maintenance which all auto manufacturers now use, and Ford engineers resisted adopting it. The common modern maintenance schedule is based on easy-to-remember milestones, rather than an exact calculation of the exact point at which each and every individual part in the car will experience its peak statistical likelihood of needing service or replacement. That's what Ford was using.

Toyota's schedule was based on regularly scheduled intervals that were easy to remember. The Ford marketing department discovered this and copied it. That drove the Ford engineers nuts, and for many years people remembered Toyota as the cars that didn't break, partly because of superior manufacturing, but partly because Ford's maintenance schedules exceeded the complexity threshold of the average human being, while most Toyota owners followed the standard, simple, easy-to-remember Toyota schedule.

Two issues make the broken-hearted mechanic: first, your clients may only want to pay for development, not maintenance. Second, your clients may not anticipate maintenance costs. If your client doesn't care about the quality of the motor oil, you can't badger them for it or steal their app and go on the run with it. It's up to them how smoothly they want their app to run. But if your client fails to anticipate maintenance costs, that's your fault, because as the expert, it's your job to warn them.

How do you warn them? The exact point at which each and every individual line of code in the app will experience its peak statistical likelihood of needing service or replacement is difficult to calculate. It might be fun to shave that epic, infinitely hairy yak, but it would cost you years of your life. A simpler course of action is to provide a predictable maintenance schedule.

A predictable maintenance schedule for application development should center around regular, easy-to-remember intervals: every three months, every six months, every year. For example, don't upgrade to the latest version of your framework the day they release it. Upgrade on a regularly-scheduled interval that makes sense for your framework, and the pace of development in its community. That makes the upgrade easy to plan and invoice - both for you and for your client. Neither your shop or your client needs to care whether a given version is early or late; just upgrade the framework every six months (for example) and planning becomes easier, whether you're planning the cost or the work.

Consider Rails. It moves quickly. You may want to implement a new feature as soon as you upgrade your app to the latest version, because the latest version makes the feature easy. But then it falls on someone to do the upgrade, and that may require overhauling a few things. Then you end up balancing the pain-in-the-ass factor of the upgrade against the pain-in-the-ass factor of not being able to use whatever new hotness the latest version gives you. Balancing one pain in the ass against another encourages frustration and burnout. But if you know for a fact that the next upgrade is scheduled for a particular date, you have nothing to worry about. You know exactly when it'll happen and you can plan for it in a relaxed way.

One important caveat: I don't actually know if this works. I thought it up in the shower. I think it's a good idea, though.

Excellent Blog Post On 37Signals-Style Side Projects

I think we have a serious problem in our industry.

I believe it generally started when Basecamp became quite successful and 37signals started to talk about their theories on the subject. Their basic mantra was “Don’t quit your day job to build a web app. Build it in your free time and use your day job to pay the bills until your new app brings in enough money to quit your day job.”

I used to agree with this, but now I think I’ve come full circle.

I’ve seen a lot of web apps launched recently which haven’t succeeded. They’re not failing miserably, and they’re not wild successes. They’re just kind of puttering along, sapping just enough resources to be a problem, but not succeeding enough to really take off.

Saturday, May 16, 2009

Archaeopteryx: Music Production Use Case

I made a drum & bass track this morning, in about an hour, that I think is pretty good. I have no doubt that it's good for something I made in an hour, but I think it also stacks up well against similar or equivalent drum & bass I made a few years ago to which I devoted a lot more time.

I started with drum sounds and Amen samples from a previous sketch, and generated an Archaeopteryx MIDI file. I then generated three more MIDI files with Archaeopteryx, gathered drum sounds for those MIDI files, and added several loops.

Here's the sequencer window, from Reason:

Since many people who read my blog don't use Reason, I'm showing you this just because it looks cool.

Here's something a little more useful:

This is the sequencer window. The first four channels - regular, amens, glitchy, and vocoded - represent Archaeopteryx-generated drum MIDI. The last four channels - Dr. Rex 1-4 - represent loops. If you focus on the loops it's pretty obvious there's a very regular grid going on. Dr. Rex 1 plays a loop at the end of every 16 bars. Dr. Rex 2 rests for 32 bars and then plays for 32 bars, and the pattern repeats every 64 bars. Dr. Rex 3 rests for 64 bars and then plays for 64 bars, and the pattern repeats every 128 bars. Dr. Rex 4 throws a little variety into the mix, but not much, by resting for 64 bars, playing for 128 bars, and then resting for the remaining 64 bars.

It's less obvious, but the Archaeopteryx channels use a similar grid. I've forgotten the details, but I believe it goes like this: vocoded repeats a rhythm for 32 bars, and then generates a new one; regular repeats a rhythm for 16 bars, then generates a new one; amens repeats a rhythm for 8 bars, then generates a new one; and glitchy repeats a rhythm for either 4 bars or 2 bars, and then generates a new one. I could have gotten some details wrong, but the principle is obvious.

You can't see the grid there, because it's all in the details of the MIDI, and at this viewing level the sequencer just represents that MIDI as a thick red line. Since music requires both clear rules and violating those rules, I also added some edits to break the regularity of the grid. However, the Archaeopteryx channels all come from very nearly the same code.

It all changes based on just one magic number.

One major goal of Archaeopteryx: it exists to help me get better at making music. Ramon Leon told me about an amazing talk at a Smalltalk conference where one of Smalltalk's originators - I believe it was Alan Kay - explained his belief that if you want to understand something, the best way is to automate it in code. If I recall correctly, he also gave some examples from his experiments where he first taught children basic programming and then taught them how to use their programming skills to learn other skills.

Anyway, the goal: get better at making music. One way to do that is to use new tools of analysis to understand music better. If you look at the sequencer window picture, you don't see any evidence of the regular pattern driving all the drum patterns at a fundamental level. You don't even see it if you zoom into the next level of resolution.

No music software exists, to my knowledge, which can perform the sophisticated visualization and analysis necessary to reveal the meta-pattern that all these drum patterns share. However, if you reduce it to code, it's easy to spot. The only thing that changes is the magic number.

Of course any time you've got code which only changes by one value, the smart thing is to parameterize that value, and the fact that I'm using a magic number at all suggests a refactoring in itself. But refactoring Archaeopteryx will have to wait. Archaeopteryx is a sprawling, Perlish mess, and I say that with pride. You could replace most of its lambdas (at this point) with more traditional OO structures, but that's a tangent. It's that way because I needed the power of lambdas and flexible programming to get to the point where I had anything worth refactoring in the first place.

Likewise, I'd prefer to make music that was better than the music I made five years ago, as opposed to making equally good music in less time. However, all this serves as a good example of why I've stopped thinking about Archaeopteryx in terms of live performance. I always pay attention to the 80/20 rule. Archaeopteryx live fails that rule: there's a lot that could go wrong. Tools like Ableton Live win. But Archaeopteryx as a tool for rhythmic complexity wins. This track contains around ((256 / 32) + (256 / 16) + (256 / 8) + (256 / 4)) distinct rhythms, which is to say 120. The actual number I don't know - it could be 256/2, not 256/4, plus you'd have to figure out how many I threw away with edits and added with loops - but the point is, use a tool for what it does well. Archaeopteryx does rhythmic complexity well, right now, which wins out in some important ways over its hypothetical ability to do maybe-useful things with live performance someday.

Friday, May 15, 2009

You Don't Know Extreme Programming

At ENTP, we practice programming so extreme we need headgear for safety.

You won't find that on RMM.

Thursday, May 14, 2009

What It's Like Being A Ruby Rock Star

There's nothing more ridiculous than job ads requesting a Ruby rock star. First because nobody really wants a dude with metal hair and a pierced tongue showing up at your office and throwing your 30" display out the window. Yeah! Rock and roll! Second because these job ads usually define a Ruby rock star as "minimum 1 year Ruby on Rails." However, I can't make fun of this phenomenon too much. I'd get in trouble at work. A few weekends ago, the founder of the company I work for got together with the CEO and this Python guy and shot a music video for their band.

Like it or not, rock star programmers is what we are. It weighs heavily on us. Sometimes we have to stop and take a minute to ponder our own awesomeness.

I'm a cowboy / On a steel horse I ride

Unfortunately, while my co-workers and bosses have busied themselves being awesome and pondering the awesome responsibility of their own awesomeness, I've been dicking around getting into meaningless flame wars left and right. I've been swearing at people, telling them their ideas are bullshit, and generally foaming at the mouth from one end of the Internet to the other. There were even threads about my balls on both Reddit and Hacker News.

It's interesting to see the reactions my posts and blog comments get.

I'm sure an oh so self consciously smart guy like yourself can now see the actual point of my comment: many ruby programmers are pompous buffoons who deserve mocking at every turn. Judging from your strange hostility and concern with intelligence so far displayed, that certainly includes you.

It's not just all over Twitter. It's not just all over Reddit and Hacker News, either. There has not been a recent Ruby flame war that failed to turn into a discussion about me to at least some extent. Obie Fernandez wrote a post about me in the first of several flame wars over his RMM idea. The discussion on Uncle Bob's post about his keynote contains 17 comments about me (21 if you also count comments by me). Matt Aimonetti's post apologizing for his sexism only contains one or two comments about me but I'm still in there. There are also plenty of comments and posts that might be about me.

These are great, because it means people are talking about me without me actually having to do anything to to make it happen. It's kind of like passive income. I can go to sleep and wake up in the morning to find that new people are saying new things about me. And these circuitous, possibly-implying-something, maybe-about-Giles posts are actually much more fun than the obviously-about-Giles posts.

Obie Fernandez awarding me a certificate from Strawman University is over in seconds. You agree or you disagree. You laugh or you scowl. It's a fleeting thrill. Rich Kilmer and Chris Wanstrath mmmmmaaaaaaybe dissing me is like an episode of Lost. It's got mystery. It's got intrigue. You can hatch theories. "You know something, I saw them talking at this conference, and they seemed to get along just fine." "Noooo! Look. Don't you know? The most important part of reading is reading between the lines!" The suspense gives it more oomph. You can even see us hanging out together having a good time after the post goes up and everybody reads it, and wonder in the back of your mind: is Locke really the Smoke Monster? No, wait. Is this a real peace in the community? Or is it just a truce?

It amazes me to see so many people say so many different things about me. I'm a superhero! I'm a douchebag! Giles is wrong! Giles is right! Giles needs to shut up! We need to have a conversation about what Giles is saying! We need to have a conversation about how we don't need to have a conversation about Giles! And then there's the people who are like, "well, maybe. I think before we have a conversation about how we don't need to have a conversation about Giles, we should first have a conversation about whether or not to have that conversation in the first place." I love those people.

What none of these people talking about me ever brings up is that they're talking about me because I decided they would. In 2001 I left the tech industry to live in a forest wilderness and take art classes. In 2004 I came back, and I was disgusted. You spend art classes coming up with ideas. You spend a career in technology becoming an expert in implementation. But no matter how good your ideas are, most people just want you to churn out some bullshit that they can sell to whoever is one step higher up the food chain. The market for ideas is different from the market for using Language X efficiently, and it's hard to get into. If you want to sell your ideas, you first need people to know that you have them. There is absolutely no value in a great skill set or a great idea if you can't turn it into something real.

So I made sure people knew I had ideas. I made damn sure. I read Purple Cow and Free Prize Inside! and My Job Went To India, now reissued as The Passionate Programmer, which is fitting, because I am the most excessively passionate programmer around, and everybody knows it. I became the greatest troll the Ruby community will ever see, and also the greatest threadjacker. A troll hijacks a conversation and makes it worse. A threadjacker hijacks the conversation and makes it better. They're the same thing, which is why it's easy to be the best ever at both of them - and make no mistake, I am. The best Ruby will ever see, at least. I am the Michael Jordan of threadjacking (in Ruby).

Let me give you some examples. Here, I'm an epic troll. This piece of trolling completely obliterated discussion of the matter at hand and focused conversation almost entirely on me.

Here I am making with the threadjack.

It's not the best example of a threadjack, but it got some notice. Laurent Sansonetti stopped talking about Matt Aimonetti's sexism problem to talk about me instead, and Rich Kilmer posted a comment about "people offering you ‘advice’ on what to do in this situation that I would NEVER take advice from."

Now you might wonder, am I a hero? Am I a douchebag? No. I'm neither one. There's two parts to this, and the first and most important is simple as fuck. I'm great at writing sentences. I'm good at paragraphs, I'm good at blog posts, I'm good at turns of phrase, structuring an argument, several aspects of screenwriting (but not all), and at one time in my life I was even OK at sonnets. I suck at novels, because they take too long. But I am great at writing a fucking sentence.

You can complain about the swears, but I don't give a fuck. I'm undisciplined, it's true; I use adverbs constantly, and passive voice is indulged in from time to time. But if I say some shit, you're going to react. You don't have a choice.

Try it.

Try not to react.

Most guys have only one dick. I have two dicks. Both of them can sing. One of them can speak.

It's not that I'm good. It's not that I'm evil. I'm just this guy. But when I talk, people form strong opinions. They cheer or they want to attack. I'm not a champion or a villain. Anyone who says so overcomplicates things and overlooks the simple explanation: powerful sentences are powerful. I've worked hard at my writing, and it provokes strong reactions.

My writing shocked and horrified a few people enough that they banned me from speaking at or even attending RubyConf. I could have avoided that, but it wouldn't have made me a better writer. I say controversial things because I form great sentences, and that's what great sentences are made of. There's not much else to it.

Now all this stuff about being amazing at sentences and the greatest threadjacker ever and so on and so forth completely fits the profile - "unbelievably egotistical, moderately incoherent, a certain dangerous freneticism" - which one commenter laid out as his reasons for believing I was experiencing a manic episode. But like Salvador Dali, the difference between myself and a madman is that I am not mad. And that brings to me the second reason for all this incredible over-reaction.

I blog about, and talk about, my interest in acting. I've been studying acting for several years now. I've started to develop the personality type. One great acting coach in Los Angeles, named Ivana Chubbuck, makes her students focus on extracting a win from every situation they act in. Your character, even if they face defeat in the script, must win somehow. The audience must see them tackle some obstacle and triumph over it. If you dedicate your energy to this approach, it affects your personality as well as your acting. One way to interpret it: the actor must make every scene about them.

I don't study directly under Ivana Chubbuck. Ivana Chubbuck coaches stars like Charlize Theron. In her studio, I studied under a teacher for beginners, and right now I'm in a completely different studio anyway, studying a different technique. However, after a lot of time studying this approach, I now find myself waltzing into every Ruby soap opera and taking it over. I make every scene about me. If you find some ridiculous turf war or circle jerk underway in our community, you can guarantee that I'm in there, and that for some amount of time, the topic will shift from the matter at hand to the topic of me.

This doesn't make me proud. I think it's funny, though, because I only just noticed how pervasive the phenomenon is, and how unusual. It's going to work well for me as an actor, but it's a waste of time for me as a programmer. It wastes time for a lot of other people as well, but I only feel a little bit of guilt about that, because the truth is, those people were wasting their time anyway. I haven't made Rails Core about me. I haven't made GitHub about me. Taking over every circle jerk and turf war does not disadvantage anyone who was using their time well to begin with.

I'm probably going to step this down a bit. The initial problem I had, that nobody listened to my ideas, does not exist today. If anything people criticize me for only presenting ideas and never building anything permanent from them. Likewise, my fame in this tiny, tiny world serves no purpose at all for my acting goals. I can direct that energy better places.

I may shut down this blog, or scale it back. I spent 2005, 2006, and part of 2007 reading everything I could find about how to become a better programmer. I've documented most of what I learned, maybe all of it. I'm not sure about shutting down the blog, or about what I would do instead, or even about scaling it back, but I think I'm wasting a lot of energy on this drama and getting nothing valuable out of it. Something will change.

But I'm still a rock star, dammit. If you don't like it, you can lick my balls. All four of them.

Speaking At LA Web Dev Meetup Next Tuesday

There are two Ruby meetups in Los Angeles: LA Ruby on the east side and an older meetup on the west side which merged into the more general LA Web Dev meetup. I helped start up the meetup on the east side. Next week I'm going to the west side to give a presentation:

Towelie: An IRB refactoring console

Smalltalk and Eclipse automated some refactorings, but that's impossible in Ruby - or so people say. In fact, people are already developing refactoring tools, including Reek and Flay. Towelie (a work in progress) is a refactoring console which detects repetition in your Rails and Ruby applications. Every refactoring should start by discovering where you've repeated yourself in your code base. Towelie does that for you.

One Way To Escape The Cargo Cult

Testing frameworks proliferate in Ruby: RSpec, Test::Unit, Shoulda, Stump, RR, Matchy, Context, minitest, test-spec, Bacon, Cucumber, Watir, and the inevitable one-liners. It's really getting out of hand. Seriously, Bacon? Cucumber? What's next, Lettuce and Ham? Why don't these people quit coding testing frameworks and just make a sandwich already?

Presenting Sandwich: a new TDD gem which combines Bacon and Cucumber

This proliferation frustrates me because it makes cargo-culting very tempting. If you want to work on a wide variety of projects, you are guaranteed to run into some testing code you've never seen before. You may be tempted to guess how it works, rather than figure it out, simply because testing frameworks are becoming so balkanized that it's hard to justify the effort to really learn any particular one.

Don't do it! Don't cargo cult anything, ever. You'll regret it. Bugs you can explain always win over bugs you can't.

A few days ago I discovered what I believe is a limitation in RR, although again, given the sheer number of gems and plugins involved, it's hard to say for sure.

This started life as a Twitter client test. It morphed into a "what is this testing framework doing?" test. I was copying and pasting like a script kiddie when things went haywire. One of my real tests gave me bizarre, inexplicable behavior, so I coded this up to test what the testing framework was doing. It was, as they say, metaprogramming.

I remember when RSpec became the new hotness, and everybody said Test::Unit was old and busted. People said Rails should move to RSpec, but it didn't happen. At the time I thought that foolish, now I see a lot of common sense in it. Test::Unit might not be perfect, but it's good enough to get a lot done, and getting a lot done is much more valuable than discovering the One True Testing Framework.

I can see two explanations for this excessive biodiversity. One is simply that the ideal testing solution hasn't been discovered yet. The other is that Rails is a test-obsessed culture (which is good) that is not above endlessly debating minutiae (which is bad). I think both these explanations are true. Obviously all this experimentation will give us better and better testing frameworks as time goes on, but I wish the process was smoother. "Test all the fucking time" is truth. "Test in a different way every fucking time", less so.

Wednesday, May 13, 2009

Upcoming Presentations (In The Fall)

I'll be speaking at ESUG in France about Smalltalk's Image Problem, in late August/early September, and in early October at Aloha On Rails in Hawaii about How To Work Less.

Monday, May 11, 2009

@djgoatboy Experiment: Going On Hold

For a few months now I've been posting a new beat every day on Twitter. I'm putting this on hold. I've just found it makes it extra difficult to get off the habit of being on Twitter all the time. The experiment has huge benefits, which is why it's going on hold and not just ending outright, but Twitter doesn't do much to help my productivity at all. I've also been wanting to switch from beats every day to tracks every week, or something like that, so that's something I'll be thinking about how to organize.

Update: This is a testament to the power of habit. I tried to put it on hold and failed. Now I feel weird if a day goes by without uploading an mp3.

Sunday, May 10, 2009

Won't Somebody Think Of The Noobren?

Some people have disagreed with, or criticized, my rant about Uncle Bob's keynote saying that there are lots of Rails developers outside my little social bubble who still don't TATFT. Meanwhile, Obie Fernandez is still pushing RMM despite continuous and consistent opposition. Uncle Bob's keynote and Obie's maturity model effort have something in common: they cost energy and time, and that expense becomes less worth it the more skilled you are.

If you're doing well with Ruby and Rails, Uncle Bob's keynote - whose message is just a recap of "Test All The Fucking Time" - is as obvious as obvious gets. If you already use unit testing or BDD or any of the varied options available to you in that space, there's really no value in watching the keynote. You've either heard it before or you figured it out for yourself. However, if you haven't figured out that a culture of unit testing is one of Ruby's most valuable assets, then of course I have to give credit to anything which wakes you up to this.

Uncle Bob is a fireman.

Obie's RMM is similar: useful for noobs, valueless for so-called "rock stars." If you're starting up a company and you want a way to model your company on companies you admire, a web site which collects practices and techniques for lots of different companies will help you do that.

However, let's take for example the place where I work. We're all prolific open source contributors, and/or frequent conference speakers, and/or creators of various and numerous interesting side projects. What would a noob learn from attempting to model us? Well, a few months ago, a noob would have learned that RSpec is awesome. More recently, a noob would have learned that RSpec has all kinds of foibles, and we use Context and Matchy instead. We frequently declare "everybody should be doing X" or "nobody should ever do X", and sometimes we're using the same value of X in either case.

What do you bet that a unanimous "everybody should use yaml" from us is only a matter of time? Trick question - that's what we were all saying a few years ago when everybody was on XML.

Last month a noob would have learned that we're in Campfire all the time, including Saturdays at 4am. This month a noob would learn that we're experimenting with "blackout days" when people are completely and deliberately inaccessible to the outside world except via telephone.

Whiteboard from Flickr founder's new startup.

Do you use remote work at your company? Is that a best practice? We're all telecommuting from disparate conferences one week. We're all co-located in a remote cabin without Internet access the next week. Oh, and we never use pair programming, except sometimes we do. Meanwhile our side projects include screenplays, professional photography, short films, iPhone apps, mini-apps, open source libraries, several different music projects, and, if I recall correctly, a now-defunct fashion design firm.

Not a pic from anything we did, just awesome.

Is it good for us that we do all this other shit? Of course it is. It keeps us creative. But does this mean your company should go out and start their own fashion label too? Where does that rank on the RMM list of best practices? How many endorsements does that have?

The moral of the story is that the story has no moral (and the key to the treasure is the treasure). There's nothing to learn here and a noob would lose their marbles trying. An RMM practices page which tracked every one of our "best practices" would include hundreds of entries, and very few of those entries would have any endorsements, and those few which did have endorsements would be practices we tried out a year ago and decided against for one reason or another. It would be ridiculous. We change our practices so often and over such a wide range that a bar graph wouldn't cut it; you'd need a particle-cloud visualization just to determine what practices we're committed to and what practices we're experimenting with. Depending on the time frame of your analysis, you might discover that we're not committed to any practice and we consider every practice experimental to some degree. Depending on your point of view, you might even think that's a good idea.

⌘N > ⌘C

Well OK. So it would be impossible for a noob to learn from us on or whatever. Couldn't they still learn by finding out which experiments worked and which failed? Wouldn't it still be useful for us to learn what our competitors are doing? Yes, of course. That's why we have blogs. (And for that matter Twitter.)

It's a very good thing so many people think RMM's a bad idea. Our community is contentious enough to begin with. Can you imagine what it'd be like if people took RMM seriously? Every downvote or upvote would set off a cascade of tweets and a blog war. RMM mistakenly assumes that what the Ruby and Rails communities need to do is spend even more time blogging, arguing, and in many cases splitting hairs over the best way to run a Web shop. This is kind of like McDonald's new McCafé idea, which is based on the theory that the world needs a Starbucks with even more sugar, as if the one thing Starbucks didn't have enough of was sugar.

Now listen. I'm not saying we shouldn't help people. I'm not trying to be all "fuck you, I'm an anteater."

Helping people is nice.

However, I already do things to help people. I blog, constantly, and in between my rants and jabbering you'll find lots of helpful tricks. I speak at conferences, and proselytize not just my own projects but also ideas and techniques that I think matter for everyone. And I think it's better that way. After all, you can lead a horse to water, but you can't make him drink.

It's very draining to battle mediocrity.

Why bother? So Rails is full of programmers who don't test and maybe even companies who don't use version control. That's their problem, not ours. We don't even use Rails any more anyway. At ENTP, we're switching to Potion. Everybody should write all their code in Potion (except nobody ever should).