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

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).

Archaeopteryx: Euruko Presentation Well-Received

I've just heard from Pablo Formosa Estrada, who did a presentation on Archaeopteryx at Euruko in Barcelona. I wanted to go to that conference, and now that Pablo reports his presentation had people "jumping and dancing", I really wish I'd been able to make it.

(Ultra)-Miniapp: Hello World On Seaside

This took a minute, max, to code in GNU Smalltalk and even less again to rewrite in Squeak - which I had to do, after several hours of failing to install GNU Smalltalk on my Slicehost slice. I followed that up with a few hours of failing to install Squeak on my Slicehost slice. Finally I resorted to Seaside Hosting, which was quick and painless.

I was already uploading to Seaside Hosting when Monty Williams told me about this blog post explaining how to set up Gemstone GLASS on Slicehost. That's what I'll use next time.

Saturday, May 9, 2009

What Killed Smalltalk: My Balls

People are talking about this.

Everybody else loves it, but I don't like it at all.

He calls C++ "a man's language" and says Java is an "estrogen" language. He later compares them, saying you have this "manly" language on the one hand and this "insipid" language on the other. Because the opposite of manly is insipid? And we get this right after a huge fight about sexism at Rails conferences? Is that epic sexism fail? Or is it merely regular sexism fail, mixed with timing fail? There's no doubt it's a dick move. The only question is, how big a dick move was it?

He goes on to this idea that C++ punishes you for fucking up, and that's a good thing. It's only a good thing for people who fuck up a lot. This is the same bullshit argument people had about Java vs. Ruby in 2006 and 2005. Before that, it was the argument against Python. It's the argument people used when they said nobody should use Lisp ever, and the reason superstitious programmers are afraid of lambda and eval.

The central assumption of Java was that you should remove dangerous features from languages so that the programmer can do a minimum of damage. It also makes Java a language where a framework like Rails could never happen, but the theory was that this tradeoff was a win. It's the chastity belt design principle, and it was trashed several years ago, back when nobody considered Ruby mainstream. I forgot who delivered the coup de grace, but that idea is deader than Subversion. Uncle Bob endorses it.

He also fails to grok that obscurity is not failure.

Uncle Bob spends at least 12 minutes explaining that TDD makes it easier to refactor. He cajoles the audience to use TDD. IN 2009! Every other conference has people arguing about which test or spec framework is the best; RailsConf wants to introduce you to the amazing new concept of TDD. He name-drops RSpec like that scene in American Pie where the dad tells the kids "keep it real, homies." This is why I skipped RailsConf. Last year they had us sitting through Joel Spolsky's Windows jokes, in a room dominated by OS X and Linux geeks. This year they wanted you to sit through an introduction to TDD.

Of course you should write tests. And he's right when he says that people need to stop hating on other languages. But most of his other points are tiresome bullshit, and wrong.

Like I said last year, RailsConf has taken a bad direction. It serves powerful, evil demons: the Sandpaper of Averageness and the Nyquil of Safety.

Bob's idea that we are becoming a profession is completely insane. Professionalism itself is ceasing to exist. Programming isn't turning into a profession - it's turning into a form of pop culture. That's why people use the term "rock star" to describe programmers.

Here's a quote from Alan Kay:

"Once you have something that grows faster than education grows, you’re always going to get a pop culture."

That's programming in a nutshell. Why else would we have this phenomenon of "rock star" programmers? What else could explain it? Why else do people joke that working in technology means working in a fashion industry? Alan Kay, one of the inventors of Smalltalk, hits the nail on the head here. Knowledge from wild young hackers grows faster than any educational system for structuring or preserving that knowledge, and the inevitable result is a pop culture. But a pop culture is no breeding ground for professionalism! That's absurd!

Professionalism in action

Here's a quote from Bob Martin in the Q&A after his keynote:

"Can you be too professional? No."

Oh, yes you can.

All you have to do is look at history. Programmers then:

Programmers now:

And Bob Martin says we're becoming more professional? This is bullshit on wheels! The only way programmers are becoming more professional is if time is moving backwards.

Uncle Bob's presentation was only appropriate for RailsConf at all if you disagree with what DHH said in the widely hated Tim Ferriss keynote - that programming in Ruby is just one step in doing unconventional things that make life better on every level. Uncle Bob argues for the Nyquil and the Sandpaper, saying things which are either obvious or false - and a few which are obviously false - while DHH goes off on a tangent and faceplants at a conference organized around his own framework. Was that fail? Yes. DHH's fireside chat with Tim Ferriss failed miserably as a keynote presentation, with people abandoning it in droves. But maybe it's good to fail every now and then. People who are afraid to fail never do anything interesting at all.

Of course when DHH built a Web framework in Ruby, it was unconventional. A lot of people at RailsConf jumped on a bandwagon, and that's not unconventional at all. But DHH's failed interview was in the spirit of what made Rails and Ruby big.

Uncle Bob, however, is trying to create a world where nobody ever got fired for writing a unit test. He doesn't just serve the Sandpaper of Averageness and the Nyquil of Safety; he worships them. RailsConf is turning into a haven for demon worshippers!

OK I'm done.

No, wait: Hitler! FUCKING HITLER!

OK. Now I'm done.

It's great to be a dynamic speaker who gives a thrilling presentation. But it's better if you can do it while saying things which are true.

Here's another quote from Bob Martin:

"Wolverine was pretty good. Great effects. Engaging plot. Good acting."

I rest my case.

Friday, May 8, 2009

Van Gogh: What The Fuck?

There's this thing making the rounds about historians with an alternate theory about Van Gogh's ear: that he lost it to his turbulent friendship with Paul Gaugin, an excellent fencer who these historians believe removed the ear with a sword or a knife. It's out there on the Web and I highly recommend reading it, because overall, it swayed me. I believe these historians now.

However, what's fucked up about these historians is, they came up with an alternate theory about Van Gogh's ear, so in a way they're his defenders or apologists, because they're saying he didn't cut off his own ear. That makes him less crazy than everybody thought. But not much less crazy. They're not disputing at all that when the ear came off, he went over to this brothel and he gave it to this hooker. Which starts up at least as many questions as it answers. Was this some love triangle? Was Van Gogh just out of money, and figured, shit, I lost my ear, maybe I can get a blow job for it? Did it work?

That would make a great movie. The love triangle that ended with a severed ear. "It's too much drama, baby. If this happens again I'll be deaf. I'm done, I'm out, I'm gone - but I'll always love you, and I want you to have something to remember me by. Take my ear. It doesn't work any more, but maybe you can use it as a coaster and reminisce about me fondly while you drink your morning coffee on a lazy Sunday." Or: the hooker who accepted body parts as payment. Maybe she was working for Dr. Frankenstein. That would be a cool movie too. Actually that would be better as a sitcom. A really fucked-up sitcom. Like The Addams Family meets Showgirls.

Thursday, May 7, 2009

Murdoch vs. Arrington: Both Wrong

This makes sense but it isn't going to work. Everybody on the Web knows why it won't work; let me point out why they're trying. Journalism is worth doing, it costs money, and a huge portion of the blog world makes its money off the inefficiencies in the journalism industry - they fund the actual journalism but burn money doing it because the Web makes their distribution systems obsolete.

People predicting that blogs will fully take over are mostly right but partly full of shit. Blogs kick ass over newsprint, but the blog economy parasites off the journalism industry. You can't keep parasiting off a dying host. When newspapers truly die, they'll stop all their research and fact-finding, and bloggers will have less to re-tweet.

Journalism will move to TV and blogs. Blogs can't really fund the research, but TV can, and a lot of TV pundits already come from the blog world. TV is already taking over the Internet to some extent.

Screenwriting: Witness

Witness is a good movie. I watched it last night because it's a canonical example in screenwriting books. However, I think that makes it over-rated. There are two major flaws in its script, in my opinion.

The first is that there is no reversal, or change-up, in the third act, where the character's main goal changes based on new information. This is sometimes represented as the stage in the third act where the character's plan goes wrong and he has to change it to reflect a changing situation. Representing it this way makes it easy to segue to the next flaw, because the second flaw (in my opinion) is that the lead character has no highly personalized goal. He has a goal of avoiding getting killed, but there's no strong tie between that goal and his personality. It's a goal anybody and everybody would have under those circumstances. There's really no clear link between what the character needs emotionally and what he needs in terms of the action, and this is why the third act has no reversal. The character doesn't need to change his plan to fit the changing circumstances because the character really has no plan.

He appears to be an active character, but he's not. He goes on the run not because of his discovery but because the bad guy tries to kill him. He stays at the farm not because it's a brilliant idea but because he passes out and the Amish save his life. The most crucial decision of the first two acts - the decision to hide among the Amish - gets made for him while he is unconscious, which is the absolute apotheosis of the passive character. He triggers the final showdown by attacking the bullies who were harassing the Amish, but the bulk of the activity triggering that showdown comes from others: the old man who reports him to the sheriff, the sheriff himself, and the corrupt cops who called the sheriff looking for him. You can't have protagonists who don't drive the story, for the same reason you can't use passive voice if you want people to enjoy reading your sentences.

In terms of economy and structure I can see why people refer to it so frequently - pretty much everything that happens sets up something else to happen, the dramatic payoffs are very good, and the structure is classic and easy to spot - but I think as a canonical screenwriting example it's a little bit over-rated. You can certainly learn from the structure, but if you wrote that script today, its passive protagonist wouldn't get you past the first reader.

Archaeopteryx: MIDI File Export

I've added a new feature to Archaeopteryx, one I've been intending to add for a very long time: the ability to export MIDI files. Technically it's not export, it's create, but it'd be insane to create a MIDI file without using the live-coding to hear it first, so it might as well be export.

I often get questions like "how do I use Archaeopteryx?" so I put together a screencast where I demonstrated how to use this functionality and why it was cool. I recorded it twice, and even ended up creating a little music in Reason just to demonstrate why and how this functionality comes in handy, but both screencasting attempts failed due to some unknown fuckery and I'm too tired to make a third attempt at the moment.

Until I do that, here's an example mp3.

The code is on GitHub.

For a brief overview of how I created the mp3, I started with Archaeopteryx auto-generating 32 measures of original drum & bass rhythms. Then I chose a few of those rhythms, cut and pasted them, and made them the foundation of the track. Then I chose a couple loops by David Carbone for keys and a bass line. Last I added some effects to the remaining, unused beats Archaeopteryx had auto-generated, and used them as a dubby background layer to add complexity to the arrangement.

Wednesday, May 6, 2009

Archaeopteryx: Recursive Lambda, Weird Refactor

Archaeopteryx uses a recursive lambda to schedule beat generating.

Working on something else in Archaeopteryx, I realized this was hard to read, so I moved it around a little.

At that point it occurred to me I might be able to make it into a method call. And it's true, you can - sort of.

But it's kinda ugly. My goal in the refactor had been to make the code easier to read - but I don't think that &L{method_call} is easy to read. Arx aliases lambda to L so the way you'd normally see that (if anybody normally used it) would be &(lambda{method_call}).

The parentheses seem to make things better.

The tradeoff: more Lispy, less Perlish.

I think on the whole this refactor improves things but it's hard to say for sure. The code is unusual enough that I don't even know any guidelines or rules of thumb for a situation like this. Honestly, the difference between an instance variable lambda and a def method_name is almost entirely a matter of syntax sugar anyway. Sometimes I think Ruby is just a language for people who want to write Lisp they can share with non-Lispers.