When Speech Shouldn't be Free

I've just read Kathy Sierra's latest post (warning: not pleasant or light reading). I'm sick at the thought that anyone thinks that's legitimate speech. I'm pained for her, and for her family. I'm also pained for the who know how many other people suffer through this kind of harrassment without a way to speak out about it.

Kathy has been an inspiration (and favorite read) of mine for a while now. I hope that by taking a stand about it, she can make a difference.

Kathy, let me know if there's anything I can do. I hope you're fear free soon, and that we all get to keep reading the wonderful, thought-provoking posts that have kept us coming back to your blog.

Jolt Congrats

A while ago, I offered a copy of Code Quality as a prize in the RNI naming contest. Now, it's won a prize of its own. Congratulations to Diomidis Spinellis and Addison-Wesley for winning the 2007 Jolt Productivity Award in the Technical Book section.

Approaching RSpec

I'm still thinking about RSpec and how it fits into my testing world (see my other post, but I think I'm starting to build a model that works for me. RSpec is a great design and functional testing tool, it's something that I plan on using as my strategic/longer range tool. Test::Unit still feels like the right way for me to handle the nitty-gritty of TDD and commit to commit work.

I think the right model is something like this:

1. Write out the specs for an iteration — as text first, then convert them to RSpec
2. Look at the spec I'm going to work on and write the simplest test_ method to start making it work
3. Write just enough implmentation code to make my unit test pass
4. Repeat steps two and three until the first spec passes
5. Pick another spec, and repeat steps two and three until it passes
6. Refactor
7. Repeat steps five and six until all my tests and all my specs pass or I run out of time during the iteration

I think this creates a good balance between decoupled testing of what the program does (RSpec) localization of problems (to aid TDD and refactoring). It's more work, but I think I see the benefit. Just in case this wasn't clear enough, I've got a little project that will make a great example.

My son, Mike, just finished writing his first useful Ruby program. It prompts the user for a series of chores (preceded by an arbitraty priority), then prints out an ordered chore list. It's completely procedural and was written without specs or tests, but it's a pretty good effort for a twelve year old.

I'll be writing a series of posts around it as follows:

1. Create a specification for the existing program, and refactor the program to be testable.
2. Write unit tests for the refactored program.
3. Write a specification for a new feature.
4. Implement the new feature in a TDD style, with my backing specification.
5. Review the process

I hope they'll provide a clear example of my thoughts.

Post Conference Notes From All Over

Just a couple of quick things to get out of my system as I recover from the 2007 MountainWest RubyConf:

• The conference was great! I loved (almost) every minute of it — it took me an hour or two to get past my anxiety about whether or not it was going to come off.
• I'm working with RubyCentral to organize our participation in the Google Summer of Code. If you're interested in submitting a project, check out our page of ideas (don't worry, you're free to run with your own ideas if you'd rather) then go fill out an application.
• I've started working on an Amazon hosted book store — I'll only be putting books there that I really think are worthwhile. I don't make a ton of money from Amazon, but it certainly helps me justify spending time on this blog and my other (unpaid) writing.
• I'm getting back in to the swing of tumble blogging over at my tumble blog. I just flat out didn't have any time over the last week or so.
• I'm also in the middle of tech reviewing two great looking Ruby books. Neither publisher has announced them yet, but as soon as they do I'm ready to tell you just how cool they are.

Okay, it's time to get some real work done. I'll be posting again (and more substantively soon.

More About SoC and Ruby (Get Ready for the Proposal Window)

Google hasn't announced their final selection yet for mentoring organizations, but I'm operating under the assumption that we will be. Given that, this is the time for people to start putting together proposals for student projects. The window is only about a week long, and is opens up in just a couple of days.

We've got mentoring volunteers from the JRuby, RoR, rubinius, ruby, and Xruby communities, so don't feel constrained to any particular field. On the other hand, projects that are liable to benefit the largest possible group of users are certainly going to get some extra karma.

If you're not a student, but have a great idea, feel free to toss it out for discussion. Who knows, maybe someone will pick it up and run with it.

Ruby in Google's Summer of Code 2007

Google's Summer of Code is almost upon us. Ruby Central is once again planning to act as the mentoring organization for Ruby.

For Ruby to be represented again this year, we need mentors. If you're interested in helping a college student work on a project using (or benefitting) Ruby, Ruby on Rails, Jruby, rubinius, or any of the other insanely cool Ruby environments please send me an email right away. We need to get our application turned in this week (before March 12).

Google will post the list of mentoring organizations on March 14th. Google will be accepting student proposals March 15-24, so, if you're a student, this is the time to start putting together a proposal.

Check out th Summer of Code FAQ, Advice for Mentors, and/or Advice for Students.

Evangelizing Ruby

Man, it's just my luck. Here I am, happily ensconced in a great job doing something I love (and using Ruby to do it) in a situation that's nearly perfect for my family, and along comes a job announcement fit to make me drool. It's kind of like a mini mid-life crisis. Oh well, since I'm not planning on chasing it, I thought I'd share it out here for all of you folks.

CodeGear, a Borland startup, is looking for Ruby evangelists. They're looking for people with:

1. Intense experience with Ruby Ruby on Rails
2. Strong knowledge of the World Wide Web technologies including XML, SOAP, WSDL, AJAX, etc.
3. Ability to present in front of groups of people
4. Exemplary writing, blogging, and product demonstration skills
5. Good organizational skills
6. Ability to follow through and prioritize

Here's their "Detailed Outline of Responsibilities":

• Developer community evangelist:
  1. Demo product and present at industry events
  2. Present at User Groups and SIGs
  3. Deliver CodeGear's strategic vision/mission
  4. Give technical presentations, write articles, create videos
  5. Bring community feedback to the CodeGear R&D team
  6. Leverage luminaries and leaders to help our products.
• Direct technical content development:
  1. Write articles on subject topics for the developer community web site and other web and magazine sites
  2. Build case studies, success stories, and developer profiles.
• Tool and Component Builders - CodeGear Outreach:
  1. Help 3rd party tools integrate with CodeGear products
  2. Solicit new 3rd party companies to support CodeGear efforts.

If you are interested, contact David Intersimone. Good luck, I'm sure there are a ton of people who'd love to land this job.

Book Review: Everyday Scripting with Ruby

My son and I have been reading Everyday Scripting with Ruby by Brian Marick since I got my copy of it shortly after the interview I did with him.

I really like Brian's way of teaching Ruby, and plan on recommending this book widely. (I may need to just buy a stack of copies to give out at work.) This is one of the best books from the 'Facets of Ruby' series by the Pragmatic Programmers.

My favorite feature of the book is the incremental approach. In the first two sections ('The Basics' and 'Growing a Script') he writes a very pragmatic chapter showing how to do something, then a 'referency' (I know, it's not a real word) chapter that goes into more depth about the concept just introduced. The third section ('Working in a World Full of People') follows the pattern less strictly, but still pulls in both the pragmatic and the reference material.

If you're getting started with Ruby, or know someone who is, this is a great book for you.

JRuby 0.9.8 Released!

At 5:24 PM (MST) today (March 5th), the JRuby team announced their 0.9.8 release! (Download it here.) This huge news for JRuby and Ruby in general.

On hearing the news of the impending release rubinius developer brixen (Brian Ford) wrote:

"Congratulations to one fine group of folks. 2007 will be the year Ruby breaks out, and YARV and JRuby are definitely leading the charge. I love those JRuby folks for all they're doing for Ruby."

This release includes well over 200 bug fixes, along with a number of enhancements. As of 0.9.8, JRuby is passing better than 98% of the Ruby on Rails unit tests running — according to firebrigade, Rails won't even pass all of it's tests on plain old Ruby; so this is pretty amazing. JRuby's String, Numeric, and Array classes have been rewritten to improve performance and increase correctness. Perhaps the best news is on the optimization front, where number of bottlenecks have been elinated, leading to greater than 6x speed gains. While it's still experimental, the JRuby compiler is also an exciting addition.

The JRuby community is also picking up steam. New to this release is a new core committer, Nick Sieger. Recently, Tom Enebo has been trying out a new bug fixing strategy — I think it's a variation of the Feynman Problem-Solving Algorithm:

1. write down the problem
2. think very hard
3. write down the answer.

(attributed to Murray Gell-Mann). Tom's approach is like this:

1. post a bug report to the mailing list
2. wait a couple of hours
3. Bill Dortch fixes it

This would seem an ideal way to fix problems in Ruby implementations, and I recommend other implementors (of JRuby or otherwise) give it a try.

The JRuby team also called out a non-core developer for his excellent work:

Special thanks to Marcin Mielzynski for his tireless work in rewriting a number of core classes to be much more correct and quick. His attention to detail has rooted out many corner cases.

I think every project has some people like this on it. Kudos to the JRuby team for taking the time to recognize some of them. And congrats to Marcin for his great work.

Programming in Haskell

I just heard about: Programming In Haskell — given the recent call for a good Haskell book over on ruby-talk, this is pretty timely. It's getting good reviews, so I'll have to check it out.

Another JRuby Adventure With Super Bill!

Tom: We need to check ENV (a RubyGlobal) for TZ when calling localtime. Any takers? http://jira.codehaus.org/browse/JRUBY-643

-Tom

Bill: Fixed (I think...). See patch

Uh oh, it looks like trouble in JRuby-land. It took Bill 16 hours to fix this one. Is he slowing down?

---

Tom: Another Rail unit test failure.... http://jira.codehaus.org/browse/JRUBY-654

"%01.3f" % nil should throw TypeError

Please take the challenge and fix this (Bill? :) )

Bill: Fixed, in an ugly, hacky, temporary way. See patch.

Yay! Bill's not a mere human afterall. This fix only took two hours. That last one must have been an abberation.

February's Contest Winner

This month, we (the judges) were a little bit more on the ball, but that doesn't mean our job was any easier. With eighteen entries (and one that was too late), we had a lot of quality writing to work through.

Each judge read every entry and assigned it a ranking of 3 (the best) through 1 (umm, not the best?). I then tallied the scores (the top eight entries were separated by 2 points — one with 9, two with 8, and five with 7), and we had a clear winner. Last month, there were several entries tied at the top, so we went back through the top scorers and re-rated them to select the best entry in January.

After our scoring, we ended up choosing Gabe da Silveira's Ruby Blocks as Closures. I've sent Gabe an email asking about which books we should be sending out.

So, go read this month's winning entry (heck, leave Gabe a message of congratulations while you're at it). Then, take a look at the other entries and see what you think. Feel free to drop a omment here with your thoughts when you're done.

Not Your Father's Pinewood Derby Car

My son designed a pinewood derby car for a 'open class' race we had the other night. He did the basic design, but got some help from Kevin Cole (a mechanical engineer at BYU) and I to tighten it up. Then he set about building the and painting the body, and went over to Kevin's house to put on the starter.

Finally it was time to race. Everything worked as expected. It was incredibly cool to hear the hiss of the car as it hurtled down the track trailing a plume of particulate dry ice. The only problem was the hump in the track — the car went airborne at that point, and didn't touch the ground again for 10+ feet past the finish line.

During the race itself, the car cleared the 30 ft in about 1.2 seconds, which is to scale speed of about 340 mph. (My earlier estimates were a little bit off.)

I hope you enjoy the video as much as we enjoyed racing it.

March Blogging Contest

Why does March always sneak up on me like this?

Now that we've finished the February Contest, it's time to start March's. We'll follow the same rules. Anyone who wants to submit a blog entry can just put a link to it into the comments below. On the 1st of April, Jason Gilmore and I, along with our guest judge(s), will read the entries and pick a winner. The winner gets 3 Apress books (print or PDF) of their choice.

The last two contests have been a bit 'Rah! Rah!' for some people, though I've enjoyed the entries. This month we're doing something a little bit different. No language, and no framework is perfect. Anyone who has more than a passing familiarity with one ought to know about its warts. With that in mind, March's challenge is —

What can Ruby on Rails learn from other web frameworks?

Give this some real thought and tell us about what you think Rails could do better. Give us an example of how another framework (it doesn't even have to be Ruby based) does it. Hopefully, we'll come up with some great ideas for the Rails core developers to chew on.

Write on! (I'm looking forward to your responses.)

---

Update: One of the Rails core developers has expressed some concerns with the topic of this contest. Just to be absolutely clear:

• This is not an official Rails contest ... Rails is opinionated software, and the core developers opinions are the ones that matter. (Of course, you might be able to help them see the light with a well written entry.)
• If you really want to see your ideas in Rails, you'd do well to remember: "Rails has never been about inviting suggestions, we'd prefer patches :)"