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.