Tuesday, September 12, 2006

RedGreen and rspec

I keep telling myself that I need to do something with RedGreen but to me, it really doesn't itch all that much — and so, I procrastinate. Every once in a while, I read a blog post somewhere about a cool RedGreen trick that someone has done. Then, I think "Wow, I really need to integrate that." or, maybe, "Hmm, maybe they'd like to take RedGreen over." It never seems to work out though.

This morning, I noticed RedGreen over on the rspec mailing list. It turns out that Aslak Hellesoy has added RedGreen functionality to rspec. (You can read his email and the resultant thread starting here.) Pretty cool stuff. If you're using RSpec, this is a great chance to add some color to your tests. Just spec -c your_test and away you go.

Ruby, JRuby, and Java over at Ablog

I do a little bit of blogging over at Ablog, and I try to be a Ruby advocate in that role. This morning I read Cory Foy's post Why Sun’s hiring of the JRuby developers isn’t good for Ruby. It's a provocative title, but I'm not sure it's right. Cory and I discussed it and he posted my recommended alternative: 'Why Sun’s hiring of the JRuby developers isn’t just good for Ruby'. (By the way, Cory also posted this article at his home blog: here — unfortunately that spawned two sets of comments.

Cory's point was that this is a great thing for the JVM, and he's right. I happen to think it's also a great thing for Ruby. But you know what, we're probably both right.

Monday, September 11, 2006

Author Interview: Leonard Richardson

How did you discover Ruby?

Leonard: I'd known about Ruby for many years but only started seriously using it in 2005. My first serious Ruby project was Rubyful Soup (a port of my Python HTML parser), and my first professional project was the Cookbook.

At the time I was working in a Java-oriented job, tired of Java, and writing articles about Python web frameworks, so I probably would have entered Ruby through Rails were it not for the Cookbook.

What role does Ruby play in your day to day work?

I'm working on a book now that's not about Ruby, but that uses Ruby as the implementation language, the way _Design Patterns_ uses C++. I'm also doing miscellaneous Ruby consulting work.

How did you come to write a book about Ruby?

Leonard: That's a good question because I came into this project something of a Ruby newbie, certainly not anyone's top choice for a name on a Ruby book. I think I'd built up a good reputation from my work on the Wrox book _Beginning Python_, and when my agent suggested me, O'Reilly listened. It probably didn't hurt that all the big Ruby names were busy working on their own books. :)

As for coming into tech writing in general, I owe it to a former co-worker of mine, Tony Steidler-Dennison.

What sets your book apart, why should people buy it?

Leonard: I think it's got better breadth than other books (as you'd hope from a cookbook), but also good depth. I tried to make the recipes solve not just the specific problem stated in the title, but also a conceptual cluster of related problems. My idea was that we can't have a recipe for every possible problem you might encounter, but we can group similar solutions together to increase the chance that you'll find what you need.

Of course, some problems are really open-ended and some libraries have a huge number of features. A recipe can only be a few pages long, so for some recipes, all we could write was "solve the problem with this library, here's basically how to use it, good luck". Those recipes contribute more to the breadth than the depth.

My other goal was to write a book that you can use as a Ruby tutorial if you already know two or three programming languages. Most programming tutorials are written as though you've never written a variable assignment before, and it's kind of patronizing by the time you're learning your third or tenth programming language. My plan is that that you can start up an irb session, work the examples in the first ten chapters, and then you know Ruby. As far as I know no one has actually tried this, but I'm really interested in hearing whether or not it works.

What was the most rewarding part of writing your book?

Leonard: Ever since I bought my first O'Reilly animal book ten years ago (it was probably Shishir Gundavaram's CGI Programming on the World Wide Web) I've wanted to have my name on one; I feel like I'm part of an old tradition. Probably not as important a tradition as it was back when O'Reilly was the only publisher putting out books for hackers, but I'm still proud of it.

But really the most rewarding part is that people are using the book. I wrote it to be used, I use it all the time, and when other people use it I'm happy.

What was the biggest challenge in writing it?

Leonard: Coming to terms with my own foolishness. I'd write a huge chunk of code and a reviewer would point out that you could do it in one line, or that there was a gem for it. And that's the stuff that got caught. My favorite recipe in the whole book (14.20, "A Real-World HTTP Client") has a bug in it. It'll be fixed in the next printing, and I think there are actually relatively few bugs in the book because I could automatically test most of the code, but it's still aggravating.

What did you learn from writing it?

Leonard: I learned a lot about Ruby internals, from diving into the libraries and the C code to see how things really work. I learned a huge amount about Ruby in general, since as I mentioned earlier I started out almost a newbie. I think the best way to learn something is by teaching. The next best way is by doing, which is why the Cookbook focuses so heavily on trying out concepts for yourself in an irbsession.

The book was also a good general education in fields I'd never really looked at before: SSL, GUIs, distributed programming... I also enjoyed going through the RAA and the gems on Rubyforge, looking for interesting software to write about.

What are your favorite five libraries for Ruby?

Leonard: Hard to pick just five, but I'll showcase some lesser-known libraries that I think deserve attention:

  • hpricotby _why, which makes me think I should just pack up Rubyful Soup.
  • Starfish, a really simple distributed programming library that Lucas wrote.
  • char-encodings deserves more attention. By which I mean, people should work on it as a way to improve Ruby's internationalization support, and yet I shouldn't have to do any work on it.
  • Ferret is a Ruby port of Lucene, the best Java library ever. It lets you do full-text search on structured data.
  • Finally, ActiveResource isn't a real library yet, and everybody knows about it, but it's going to be awesome.

What do you think is next for Ruby?

Leonard: I'm looking forward to more libraries that use Ruby's idioms to radically simplify entire domains. I think this is where dynamic languages like Ruby and Python show their power: Rails, ActiveRecord, ActiveResource, gserver, DRb, Starfish, Twisted, PyGame, etc. These libraries tackle a problem that's been around for years, and succeed by hiding a huge amount of the work and/or changing the way you think about the problem.

Many Ruby libraries (I'm thinking right now of the GUI libraries and RMagick) are just simple bindings to C libraries. Working with them feels like writing C code except without the performance benefits. Ferret is awesome but, because it's a Java port, you need to instantiate five different classes just to blow your nose.

It's great that Ruby has access to the best of other programming languages, but I think a binding or a port should be a signal to enterprising hackers to radically rethink the whole thing. For instance, just off the top of my head it seems like Ferret could support a simple ActiveRecord-like interface with no loss of power. (There I go, putting work on someone else's plate again.)

What's next for you?

Leonard: As I mentioned, I'm working on another book, which will hopefully be out early next year. I'm also writing science fiction, which might or might not ever be published. Financially, writing science fiction is to writing technical books as writing technical books is to having a "real" programming job.

RubyConf*MI, a Retrospective

In the aftermath of a successful RubyConf*MI, I wanted to check back in with some of the organizers to get their feedback on how it went, and what they learned. After taking a short break to recover from all their hard work Craig Demyanovich, Zach Dennis, Brandon Keepers, and Mark Van Holstyn were kind enough to answer a few questions for me. (You can read my pre-conference interview with Zach, Mark, Craig, and Brandon Keepers here, and a pair of conference wrap-up posts are here and here.


What do you think was the biggest success of RubyConf*MI?

Craig: Some people said that the attraction of the conference was simply that it existed. Imagine it like this: "I couldn't attend RailsConf in July, and I won't be able to attend RubyConf in October. Bummer. Hey, wait! What's this? Another Ruby conference? Only $20? I don't have anything going on the 26th! I'm there!" That we could provide something great, especially for those who, for whatever reasons, couldn't attend the bigger conferences was our biggest success.

Zach: The interaction, communication and sharing of ideas. It is very encouraging and motivating when you get people people together, and those people talk and listen to one another.

Mark: I think the conference as a whole was great. I know I had a lot of fun. I think the biggest success was the ability to meet and talk with others. I enjoyed meeting new people, especially at Grand Rapids Brewing Company afterwards.

Brandon: People came, they enjoyed themselves, and hopefully they left knowing more than they came with.

What was your biggest surprise?

Zach: That people wanted coffee. I am not a coffee drinker, so I never thought twice about having it at the conference. Next year we will have lots of coffee!

Mark: I was surprised how many people we were able to attract, especially those who traveled many hours to get there. I am glad that we were able to spark so much interest and hope to make that grow next year.

Craig: I must say, I was also surprised a few days before the conference to read on the Ruby mailing list a post wherein a RubyConf*MI ticket was offered because someone couldn't make the trip from, I think, Minnesota. I thought it was great that someone would plan to come from that far and offer his ticket when he couldn't make it.

What do you plan on changing for next year?

Craig:Well, some people seem to like a cup of coffee in the morning; we should have some to offer. ;-) Also, I'd like to be able to offer a few prizes to the attendees. Beyond that, I'd have to have a look at the detailed feedback we collected, which I haven't yet been able to do.

Brandon: Next year, we want to step it up a notch all around: better preparation, better marketing, better communication, a bigger variety of topics, better refreshments.

Zach: Personally, I would like to do a two day conference where one day focuses on speakers and presentations and another day focuses on more of hands on training lab. I haven't talked to the everyone else on this yet, but I think that will make the conference more productive for those who attend both days.

There will definitely be more beverage choices, that is for sure!

One thing I don't want to change is keeping costs as low as possible for those who attend, to help encourage and promote the growth of ruby and the interaction between students, hobbyists and professionals.

In hindsight, what do you wish you'd done better in your prep work?

Brandon: I wish we had done a better job of building community leading up to the conference.

Craig: We should've started a bit earlier. However, the idea for the conference was only born sometime in the Spring, if I recall correctly. Given the short time to make it happen, I'd say we did well. Another idea: we should've asked for more advice from people who have planned and executed a conference. We've all been to various conferences. We had some idea what it would take. Doing it, though, was something else.

Zach: Overall things went pretty smooth. I know that we'll try to get more of the correspondence out of the way up front rather then trying to write announcement emails and brochure-like marketing papers as they're needed. Not that we were at Kinko's the day before the conference finalizing and printing things, it was more like 6:30pm Friday. ;)

Any advice for would be regional conference planners out there?

Zach: Have a great time planning your conference, keep an open mind, and get feedback from as many people as possible as early as possible.

Mark: Start planning early, get many peoples opinions, and don't try to do everything yourself! It is very rewarding to be able to bring such a wonderful day to so many people.

Craig: Start early! Many things will take longer than you think. Also, keep it simple. We had many grand ideas for the first RubyConf*MI; I'm so glad we didn't try to implement them all!

Brandon: Zach, Mark, & Craig are right on: start early, get lots of people involved, and have fun. The only thing that I would add is you should have someone that can be the "task master". Most of our planning was by committee, and while that is helpful and necessary, there are times when things just need to get done.

JRuby, what's in it for us?

A lot of words are being passed around on the ruby-talk mailing list about Sun's move with JRuby. Recently, the talk has turned to "What's in it for us?". Beginning (more or less) with James Moore's post, which started out like this:

So I have to ask - is JRuby a good thing for the Ruby community, as opposed to the Java community? To me - admittedly, someone without a huge depth of Ruby experience - it's not an obvious good idea.

James went on to talk about the JVM vs C, but I think he missed the bigger picture. Because of his focus on the JBM, most of the replies clustered in that space as well.

I'd like to refocus the conversation. Here are five benefits I see for the whole Ruby community, and three possible problems.

The Good Stuff

Increased visibility for Ruby — With a big name getting involved in Ruby (and not just Ruby on Rails), there's even more opportunity to push back on the FUD that keeps popping up. It also creates a space to discuss Ruby with co-workers or peers that might not have existed before.

Work on a Ruby specification — One of the problems that many of the Ruby re-implementations face is that there's no formal specification of Ruby. Charles Nutter has been trying to work on this for a while. Now that he's being paid to work on JRuby, I think that this will accelerate.

Ruby, the core library, and the standard library testing — Charles has also been trying to drive for a common testing suite for Ruby, and all the libraries that ship with it. Given a common suite, all the implementations will benefit. Something like this could even grow into some rough performance testing.

Ruby documentation — Much of the documentation written for JRuby should roll right into Ruby. Given that 'bad docs' is one of the most common complaints about Ruby, this could be huge!

Ruby on more platforms — We've seen problems getting Ruby on AIX. If JRuby provides a parallel implementation that's easier to get running there (or on other platforms), it can help speed adoption on those platforms. (E.g., I have three AIX boxes that are slowing the spread of Ruby at my day job.)

Corporate sponsorship of Ruby — Now that Sun has jumped in visibly (and Microsoft in a less visible way), there's some home that other corporations will also step in to help push Ruby (or JRuby, cardinal, etc.) development.

And The (Potential) Bad Stuff

Corporate influence on (J)Ruby — Any time a corporation steps into an Open Source community, there's some fear that they'll exert some undo (and malignant) influence. In the past, this has mostly proved not to be a problem. Having strong developers at the core of the project seems to be the key mechanism to ensure that it doesn't happen. I feel comfortable that Charles and Thomas will be that stron core.

Divergence of implmentations — What happens when the JRuby behaves differently from Ruby? I've already found one (very minor) case where this has happened. The randomizer for JRuby and Ruby >= 1.8.4 give different numbers when they're provided the same seed with srand. (Actually Ruby < 1.8.4 also behaves differently than either of the others, so this isn't an issue unique to JRuby).

Bloat — Perhaps the biggest complaint about Java is that it's become tremendously bloated. Since this has happened under Sun's watchful eye, I think it's fair to ask if this will happen to JRuby too? Again, I hope that Charles and Thomas (and the rest of the JRuby community) will keep this from happening.

Wrapping Up

Did I miss anything? Am I overstating one (or more) of the points above? What do you think?

Digg This