In my ongoing attempt to keep myself honest, here’s another piece I wrote, again played by Mike Springer. I’m not sure how to categorize this one—I wanted to play around with 7/8, and ended up with what I think are some interesting patterns. 

I’ve known Chad Fowler for almost ten years. He’s a seriously good guy: musician, developer, leader, and friend. So when he came to me some years ago with an idea for a book, I jumped at it. I was hoping for something good, but what we got was something truly great.

Andy and I wrote The Pragmatic Programmer over 10 years ago. It was a book full of advice on the job of programming, from low-level coding to teams and projects.

Well, Chad had written the companion book. Where our book looked outward at the job you were doing, The Passionate Programmer looked inward at the person doing the work. It’s a book about finding fulfillment in what you do. It’s a book about rekindling the fires that you felt when you first entered the profession. It’s a book about creating a career, rather than turning up for a job.

I was blown away.

And then I did something really stupid. The book came out about 5 years ago, and outsourcing was big on everyone’s mind. So I thought “let’s make a jokey title that’ll grab people’s attention.” I called the book My Job Went to India (And All I Got Was This Lousy book).  I’ve already blogged about how stupid that was—it was probably the single dumbest thing I’ve done since I got into publishing. The title put people off; it gave them the wrong idea. The book was really nothing to do with outsourcing, but you wouldn’t know it from the cover. This book deserved so much better

So, four years later, we revisited the book. Chad’s given it a spring cleaning, revising and updating it. And we gave it a new title and a new cover, both of which do a better job of conveying the energy and enthusiasm that lie within.

I’m not into selling: my philosophy with our books is “if they’re good, people will buy them.” But this book is different. I really think it can make a difference. So I’d love for you to read the extracts and maybe take this book home with you. I honestly think you’ll thank me (and, most importantly, Chad) if you do.

Twitter Should Move Away from Ruby

Oh dear. The chattering classes are at it, talking about how the Twitter folks are dissing Ruby by announcing the replacement of some Ruby code with Scala code.

Please stop.

At the kinds of volumes that Twitter handles (and with what I assume is a somewhat scary growth curve), Twitter needs  to improve concurrency—it needs an environment/language with low memory overhead, incredible performance, and super-efficient threading. I don’t know if Scala fits that particular bill, but I know that current Ruby implementations don’t. It isn’t what Ruby’s intended to be. So the move away is just sound thinking. (I suspect it also took some courage.) I applaud Alex and the team for this.

Instead of defending Ruby when it’s clearly not an appropriate solution, let’s think about things the other way around.

The good folks at Twitter started off with Ruby because they wanted to get something running quickly, and they wanted to experiment. And Ruby gave them that. And, what’s more, Ruby saw them through at least two rounds of phenomenal  growth. Could they have done it in another language? Sure. But I suspect Ruby, despite the occasional headache, helped them get where they are now. 

And now they’ve reached the status of world-wide wunderkind, it’s time to move on. 

I for one wish them luck. I look forward to the day when our online store reaches the kind of size where we have to move away from Rails. I’ll tweet the fact with a tear in my eye, while my yacht sails me off to the sunset.

I decided a while back to publish the music I’m writing, if nothing else as a way of keeping myself honest. So, here’s a little piece of fluff I wrote just to play with time signatures—alternating 5/8 and 6/8 has a nice drive to it. It’s played by my music teacher.

Like the rest of our publishing business, I like to keep our covers simple and easy. But now I realize that these covers fail to capture the true epic nature of our books. Joey deVilla posted some reworkings of book covers last year, but I only came across them today. I’m inspired…

The strange thing is: I’m not sure where he got hold of the image. After we posed for the picture, DHH and I thought better of it. We thought we had destroyed all the copies…

Ruby 1.9 can check your indentation

All Ruby programmers regularly encounter the mystical error “syntax error, unexpected $end, expecting keyword_end.” We know what it means: we left off an end somewhere in the code. As Ruby compiled our source, it keeps track of nesting, and when it reached the end of file ($end), it was expecting to see one more end keyword, and none was there.

So, we trundle back through the source, and after a while discover we’d deleted just one too many lines during that last edit.

Ruby 1.9 makes that easier. For example, here’s a source file:

class Example
  def meth1
    if Time.now.hours > 12
      puts “Afternoon”
  end
  def meth2
    # …
  end
end

Run it through Ruby 1.9, and you’ll get the same old error message:

dave[RUBY3/Book 8:26:48*] ruby t.rb   
t.rb:10: syntax error, unexpected $end, expecting keyword_end

But add the -w flag, and things get more interesting.

dave[RUBY3/Book 8:26:51*] ruby -w t.rb
t.rb:5: warning: mismatched indentations at ‘end’ with ‘if’ at 3
t.rb:9: warning: mismatched indentations at ‘end’ with ‘def’ at 2
t.rb:10: syntax error, unexpected $end, expecting keyword_end

It’s the small things in life…

Forking Ruby—my RubyConf Keynote is now up

Link: Forking Ruby—my RubyConf Keynote is now up

There’s a sound that no presenter wants to hear, and that’s dead silence. And that’s what greeted me when I made the suggestion in my RubyConf keynote that the community should fork the Ruby language. I think by the end of the talk, though, most people were convinced.

Am I anti Ruby? no.

Am I suggesting Matz is doing a bad job? Not in the least.

But I do think the complexity of the current language inhibits experimentation with language features. Want to implement parallel Ruby? If you do it with the current syntax and semantics, you’ll be struggling with the integration of global variables, the non-threadsafe nature of require, continuations, and so on, and so on. So before starting these kinds of experimental projects, I’m saying we should fork the language. Produce variants that let us focus in on the aspects under test. Make the new language a rich-enough subset that you can do useful work with it. Then let people play with it. Maybe the ideas are stellar, in which case we can all talk about integrating the changes back into the mainline language. And maybe the idea didn’t pan out, in which case we can quietly forget it, and we’ve done no damage to the language itself.

A mutation is an altered fork of the original. And mutations are essential to the diversity and strength of a genetic line over time. Let’s not be afraid to create Ruby mutants and let them compete.

The keynote is available from Confreaks.