Friday, November 30, 2007

Ruby Tool Survey

Okay, I’ve decided to bite the bullet and convert over to layouts so that I can include a weekly (or so) poll here. I’ve just put up the first one, sort of an extension to the one Tim Bray did a recently (not that mine is any more scientific). Hopefully enough people will fill it out that this little experiment will prove worthwhile.

I’ve got several ideas for upcoming surveys, but I’d love to read suggestions if you’d care to leave ‘em in the comments.

Update: I felt badly enough about not including flog that I've written a little post about how to use it

Wednesday, November 28, 2007

Holiday Blogging Contest

It’s been a while since I’ve run a blogging contest here but, just in time for the holidays, I’ve teamed up with Apress to run another one.

Earlier this month, they released Practical Rails Projects, and in December, they’ll be publishing Practical Ruby Projects. The idea of ‘practical projects’ sounded like a great topic for blogging, and the folks over at Apress agreed.

So here’s the deal, you write a blog post about a project you’re working on. Load it up with cool how-to information. Make it accessible and exciting to someone new to Ruby, Rails, or the specific domain you’re working in. Then, post a link to it in the comments below. After Christmas, the crack On Ruby judges will pore over the entries and pick two winners (one Ruby and one Rails). Each winner will receive three Apress books of their choice (electronic or paper copies).

Enter as often as you like, this is a great chance to build up your library while you’re helping build an online library of great Ruby documentation.

Tuesday, November 20, 2007

November MountainWest RubyCamp

As I’ve told a number of people, I’m trying to ramp down a bit on my involvement with the Ruby community. It’s not because I don’t love ya’ll, it’s just that I have other things that are becoming more important to me. Last Saturday (Nov 17th) was one of the last major events I’ll be involved in setting up, the MountainWest RubyCamp.

The RubyCamp went really well. We had about 20 people show up for 4 hours of Ruby discussion and random geekery. There were five different sessions, with a couple of prepared presentations and some good group discussions. I guess the best measure of its success was that the attendees want to do it again. MountainWest Ruby doesn’t want to let anyone down, so it looks like there will be another RubyCamp in January. Depending on the dates I’ll try to make it there.

If you’re interested in getting involved, you can see the discussion that’s swirling around it over at URUG’s Google Groups site

Good luck to the organizers. I’m sure you’ll have a great time and come up with a great activity.

Saturday, November 17, 2007

2008 MountainWest RubyConf: CFP Revisited

With the end of RubyConf, I’ve seen a couple more talk proposals for the 2008 MountainWest RubyConf. I also got an email from a RubyConf presenter. With his permission, I wanted to share it with you since it’s a question that may be on your mind too.


Hey Pat!

I was wondering how much attendance overlap you (as in MountainWest) have with the general RubyConf? I was thinking about submitting a proposal for the talk I gave at RubyConf, but if the audience is going to have seen it already, it’s probably not worth it.

Probably <10% of the MWRC attendees are also RubyConf attendees.

What do you think? Are you interested in recycled RubyConf proposals?

Sure! Recycled or rejected proposals would be welcomed. (Of course a recycled talk is less likely to be selected compared to a new proposal of equal quality.) In fact, if you’d like to propose something that you already proposed to another conference besides RubyConf, feel free (with the same caveats).


I’ve also been asked what kinds of talks we’d most like to see. Our biggest selection criterea is going to be “How interesting is this talk going to be for a bunch of Ruby/Ruby on Rails hackers?” If you’re thinking of proposing “Why I should write my next web app in Django”, this is probably the wrong venue for you. On the other hand, if you wanted to do a 45 minute overview of why Rubyists should learn to program in Factor/Erlang/Haskell/Prolog/Intercal … well, a talk like that just might work (except for the Intercal variation).

If you don’t think you have 45 minutes worth of material, don’t forget our lightning talks. We’re hoping to open up the floor to eighteen or so 5 minute long lightning talks.

Tuesday, November 06, 2007

JRuby performance numbers

Well, with the new versions of JRuby out, I figured it was time to fire up my LogWatchR benchmarks again. For this test I run 20 minutes worth of syslog entries from the system I work on through a log analysis tool I built in Ruby. There are about 75,000 syslog entries in there, so there’s a reasonable amount of IO to be done, not to mention a lot of regexp pattern matching to find potential events, and a bunch of object creation (a new object for each event that’s found). All in all, it’s a pretty good workout for Ruby.

First the boring news. When I tested JRuby 1.0.2, I found that it performed almost identically with 1.0.1. Over multiple runs, sometimes one would be faster, and other times it would be slower.

Things got a bit more interesting when I tested 1.1b1 against previous versions of JRuby. Here are some sample results:

Version Average Run Time Standard Deviation
Jruby 1.0.2 19.61 Secs 0.26 Secs
JRuby 1.1b1 17.03 Secs 0.26 Secs

So it looks like 1.1b1 is about 13% faster than 1.0.2 and 1.0.1, but the story doesn’t stop there. It turns out that regexps are still one of the chokepoints for performance in JRuby. (See also Charles Nutter’s comments.) So if a regexp heavy application is already seeing a 13% speed increase, and the JRuby team is working on improving things for the 1.1 final release, the future looks bright indeed.

Note: for those of you looking for JRuby vs Ruby performance numbers, I’ll post something soon after the final 1.1 release hits the street.

If you enjoyed this article on profiling, you might also want to look at these: