Rubinius Sprint Interview

A There’s been some good coverage of the recent rubinius sprint in Denver (see Brian’s Blog, Wilson’s Blog, and Tim Bray’s Blog for some of the details). I wanted to get a bit more information though, so here’s a mini-interview I did with Evan Phoenix, Wilson Bilkovich, and Brian Ford. (Thanks guys, for taking some time out of your busy days to talk about the sprint with me.

---

What were your personal hopes/goals going into the sprint?

Evan: My goal was to see how we rubinius work would progress in this kind of environment. I was extremely pleased how it went. The 4 of us really tackled things well, and working in a collaborative atmosphere really sped things up. I was also happy to be right there to transfer knowledge of some of the interior of the VM to other developers. That knowledge is more difficult to grasp than almost anything else in rubinius, but probably the most important.

Brian: My primary goal was to have face-to-face time with Evan and Wilson to talk about project related stuff. It was a plus that Charles came over. There’s a fair amount to the project besides just the architecture and details of Rubinius. Although we’ve had a fairly large number of committers, we haven’t had to deal with too many project management or organizational issues. I think we may have to deal with more of these in the future. So, just spending time in person was good, regardless of what we were working on.

My technical goals centered around getting the specs for the core libraries more usable and the CI runner working better. I also wanted to get more into the architecture and potentially do some interviews with Evan about Rubinius architecture details.

Wilson: I happen to still believe that aiming for 100% passing specs is the ‘right’ way to develop Rubinius. However, external pressure (perceived or real) to get ‘real’ applications running has been rising. I was hoping to get irb and Mongrel running during the sprint. As a historical curiosity, here is the rough list we worked up prior to the sprint.

How did you (collectively) do at acheiving them?

Brian: I’m not sure I can speak with relevance to how we did collectively. As with most things, there’s only so much value to organization. Our process ended up being more organic. I didn’t get any interviews done with Evan but I think that’s fine. Evan has mentioned doing some screencasts, which may actually be a lot more useful. Something along the lines of approaches to debugging a segfault, for instance, or adding a core library method. Evan was able to spend some time with both Wilson and I showing us some gdb tricks. He also explained our profiler and debugger architecture more to me. This was very helpful as it gives me a start working on more things that will help the dev process. I guess that’s what I end up spending a lot of time on: specs, the spec runners, the website, etc. Doing things that should enable other people to write more code. It can be frustrating at times, though, because I’d like to just be writing code. Overall, I think the time we spent has enabled me to do more to help advance the project.

Wilson: Technically, we didn’t get irb or mongrel running. However, when we actually sat down and discussed the realities of implementing them, several more important goals came to the surface. Many of those centered around knowledge transfer from Evan to Brian and me. Also, irb turns out to be an incredible nightmare. If it weren’t so hard to type, ‘Eye of Terror’ would be a better name for it. Here’s a fun part of irb. Yes, that’s a method that uses module_eval to define another method that itself uses module_eval to remove methods.

Despite all that, I think we made more progress than I really expected.

Sun provided some sponsorship, do you think they got their money’s worth? Why?

Brian: Absolutely. I, personally, am very grateful for the sponsorship. All in all, it wasn’t much money, but every little bit helps. The fact that Charles is collaborating with us, and that, for instance, I’m working very hard to make the specs implementation agnostic, means that the work we do is helping every Ruby implementation. Based on Charle’s work on the JRuby compiler, I believe there is huge potential for Rubinius and JRuby to share a common Ruby core library. Were that the case, both projects would benefit from it. And I often plug JRuby both publicly and in my work with Rails. Sun’s goodwill won’t go unnoticed, even if viewed skeptically by some folks.

Evan: Judging from Tim Bray’s blog post about why Sun kicked in the cash, I’d say yes. Sun is looking to enrich ruby by not placing bets, but rather push the entire community forward by helping anywhere they can.

Because the sprint was successful for the project, it was successful for Sun.

Wilson: Sun says that anything that’s good for the internet is good for Sun. Rubinius is good for the internet. While I definitely did not expect this a year ago, JRuby and Rubinius turn out to be of great benefit to each other. I’m looking forward to greater collaboration between the two projects. Charles is also vastly less irritating in person than he is on IRC. :)

What are your favorite outcomes/events from the sprint?

Evan: Just the fact that the sprint worked out great is one of my favorite outcomes. This being my first foray into project management, I was a little worried how it would go.

Wilson digging in and almost getting eval working is awesome. That’s definitely non-trivial and he managed it almost entirely on his own.

Brian: I think all of it is terrific, but I’ll name two things and a cool runner up. Evan’s work with Syck shows that our subtend interface really does work well. Wilson’s significant advances getting the machinery of ‘eval’ wired up is hugely important for a ton of code, especially in IRB and Rails. The colored backtraces might not seem like much, but that was a ‘fun’ accomplishment that is actually quite useful. At a glance you can distinguish core code from user code and easily pick out that top item in the backtrace.

Wilson: Listening to Evan implement YAML over the course of two hours was pretty impressive. I’m glad I got to witness that in person. Brian picked up the FFI ball and ran with it. That is an intensely cool part of Rubinius.

My favorite part was probably implementing StringIO, however. Evan wrote the StringIO code while I wrote the specs. We would each check in code, and say “ha ha! take that!” as we either exposed flaws or fixed them. It took about three hours start to finish, uncovered a ruby 1.8 bug that has since been patched, and the resulting implementation is good enough that JRuby is planning to adopt it as their own StringIO library.

Are you planning/hoping to do more of these?

Evan Hopefully before 1.0. It’s already almost October, so hopefully we’ll do a few day sprint on the west coast (LA or SF) in the coming weeks.

Wilson Yes please, and soon.

Brian Absolutely, just a matter of details. I seriously hope I’ll be able to attend, but I can’t know that for sure now.

Reading SICP

I’ve had a long standing goal to read SICP, but it keeps conflicting with other goals, like mastering Ruby or learning Erlang (to name a couple of geeky ones). Recently I learned of a project to ‘translate’ SICP into Erlang (and other languages).

“Great! I can use this to help with both learning Erlang and reading SICP”, I thought and went to take a look at it. It turns out they also have a Ruby translation underway, so I went to look at that first. It turns out that the first couple of examples make me think that they either don’t understand Ruby or don’t understand SICP.

Page 5 of SICP shows that you can start up a LISP or scheme interpreter and type in an expression and it will return that expression, like this:

 > 486
 486
 >

The site recommends the following Ruby puts 486, which is not quite right:

irb(main):001:0> puts 486
486
=> nil
irb(main):002:0>

You see, this prints 486, but returns nil. A much better answer looks a lot more like scheme:

irb(main):002:0> 486
=> 486
irb(main):003:0>

With a problem like this early on, I’m not sure that I trust the Erlang or other translations. I do like the idea though, so I should probably stick with my idea of combining the ideas, and just post my own translations (and let everyone else find my mistakes).

Well, that was disappointing

For last night’s UtahValley.rb meeting (Sep 25th), we had two Microsoft guys come fly in to talk about IronRuby and another hacker come to talk about Ruby.NET. I was deeply disappointed—not by either of the projects or the presentations, but because we only got 5 people to show up, and as we all know “Five is right out.”

So, what went wrong? We (Mike Moore and I) talked things up on the URUG mailing list over the last three weeks, Mike tried to engage the local .NET groups, we even came up with a bunch of schwag to give away (three books and a copy of Halo 3). With all that, we still had one of the poorest turn-outs in a while. I can think of several things that might have been the problem:

• there’s just not a lot of local interest in Ruby on the CLR/DLR—but even if you’re not interested in that implementation (I’m not), this was a pretty cool opportunity to learn more about it and about Ruby in general.
• there’s just not a lot of local interest in Ruby—I really hope this isn’t the case, we have almost 260 people on the mailing list and are looking forward to another regional Ruby Conference in the spring.
• we have a bad meeting night/time/place— if this is the case, please let me know what would be better.
• the local rubyists don’t want to be involved in a users group—I just don’t get this at all. It seems like there are a lot of ruby users in the area who know about the group, but won’t join the mailing list or participate in meetings. To me, local Ruby Brigades are just about the best resource you can find.

I’d really like this to be more than just a rant. Please (especially if you’re in URUG, the UtahValley.rb, or a rubyist in Utah County) let me know what you think, I want to make the UtahValley.rb as successful as it can be.

RESTful Web Services Book Review

Have you ever picked up a book on the assumption that you were going to need it, only to find out that a) it’s a great book and b) you’re not going to need it? This is just what happened to me with Leonard Richardson and Sam Ruby’s RESTful Web Services.

I really liked Leonard’s Ruby Cookbook (shoot I even did an interview with Leonard about it), so when I was looking at doing some Web Services stuff I leaped at the chance to pick up the book. Sadly, I didn’t end up working on the web services stuff so I lent the book out to some co-workers.

They loved it. It’s been passed from one member of the web services team to another, I even think the team’s manager has spent some time with it. It’s easy to see why they like it:

• Richardson and Ruby write clearly and well
• the book has a ton of examples (a lot of them in Ruby)
• there’s a lot of good advice throughout the text
• the coverage of REST and Ajax is timely and solid

Probably the best thing about the book though, is it’s solid core (Chapters 4-9, and especially 4-6). Chapter 4 describes Resource-Oriented Architectures (ROA) as a model for REST implementations. Chapter 5 is guide to designing a read-only ROA. Chapter 6 is a guide to designing a read-write ROA. I also liked chapter 8 (REST and ROA Best Practices).

If you’re planning on building RESTful web services, this book is a great place to start. Even if you’re not, it’s a pretty good book to learn more about them.

Practical JRuby on Rails, Hot Off The Press

Ola’s new book, Practical JRuby on Rails, is out sooner than I expected. I’m not going to write a review of it since I was a technical reviewer, but let me recommend it to you. This is the first book out there about JRuby, it’s got great coverage of integrating Ruby and Java in enterprise settings, and it’s by one of the core JRuby developers. What more could you ask for?

It’s too early for other reviews to be out there yet, but I think it’s a winner.

Book Review: Practical Ruby for System Administration

Apress has been putting out a number of solid Ruby books of late, and Practical Ruby for System Administration by André Ben Hamou is one of two great additions to their catalog.

André has a easy to read writing style, and covers a lot of ground in this book. The book contains a number of good examples, and would make a great book for a sys admin who’s looking into Ruby.

The most important chapter is probably the third, ‘A Practical Look at Performance’. It covers both determining whether Ruby is performant enough for systems administration tasks and analyzing and optimizing your Ruby code. Other chapters of particular note are the ninth, ‘Network Monitoring’, and the twelfth, ‘The Future of Ruby’. (Although I wish André had covered rubinius as well as YARV and JRuby in his coverage of execution environments.)

This book won’t replace The Pick-Axe as the go-to reference for a Rubyist, but it certainly belongs on the desk of your favorite sys admin (even if that’s yourself).