NetBeans Gets AutoTest Support

Not to long ago, I sent Tor an email asking if autotest support was in the plans for NetBeans. Tor has always seemed responsive to user requests, but I didn’t hold out a lot of hope since I admitted to being an emacs user and not too likely to switch over to NetBeans even if it did support autotest. I’m not ashamed to admit that I was wrong.

It looks like Tor and the other Ruby/NetBeans folks have done a bang up job of supporting testing: Test::Unit, RSpec, and AutoTest are all supported (if you install the RSpec and ZenTest gems). They’ve even built this support into a ‘Goto Test’ function.

The editor context menu has a “Goto Test” action which lets you jump quickly between a class and its corresponding test cases. This action is aware of Rails conventions, RSpec conventions, ZenTest conventions and obviously Test::Unit conventions. It is bound to Ctrl-Shift-E on the Mac; check your context menu to see the keybinding on your system.

Yowza!

The AutoTest support also features hyperlinks from failed tests to the implementation code. Check out their screenshot:

More Real World Performance Data

With the new release of JRuby, I’decided to rerun my LogWatchR benchmark for ruby 1.8.5p12, ruby 1.9.0, and JRuby 0.9.9. Neither XRuby nor rubinius can run the YAML library from the Standard Library yet, so neither of them will be included in these benchmarks yet.

In running this set of tests, I ran into some anomolies with last weeks data. I’ve figured it out now, and need to make a quick apology. The 1.8.5 results last week were run with my laptop on battery power (and thus stepped down), while the 1.9 tests were run while it was connected to regular power. This was a bigger cause of the variation in times than improvements in 1.9. I’m reporting both sets of data this week, but will be excluding battery driven runs starting with the next report.

There was a note on programming.reddit.com asking me to publish LogWatchR so that other people could repeat my benchmarking. I will be releasing LogWatchR at some point (hopefully soon), but I’d rather see people run their own applications for each of the implementations. If it won’t work now, work with the implmentors—in every case I’ve seen, they’re happy to help and interested in your results. So, please, give your application a try and let us know how it looks!

Without further ado then, here are the results:

On Battery Power
Ruby Implementation	Time
ruby 1.8.5 (2006-12-25 patchlevel 12) [i686-linux]	31.0 +/ 3.1
ruby 1.9.0 (2007-04-18 patchlevel 0) [i686-linux]	31.1 +/ 3.27
ruby 1.8.5 (2007-04-23 rev 3539) [i386-jruby0.9.9]	67.5 +/ 7.15
On Regular Power
ruby 1.8.5 (2006-12-25 patchlevel 12) [i686-linux]	12.0 +/ 1.2
ruby 1.9.0 (2007-04-18 patchlevel 0) [i686-linux]	12.4 +/ 1.8
ruby 1.8.5 (2007-04-23 rev 3539) [i386-jruby0.9.9]	33.3 +/ 6.83

Update!

The JRuby guys pointed me in the right direction to squeeze some extra improvment out of their platform. Instead of running jruby logwatcher.rb < 20_minute_log, I can run JAVA_OPTS=”-Djruby.objectspace.enabled=false -Djruby.jit.enabled=true”; jruby -C logwatcher.rb < 20_minute_log and take advantage of their compiler and JIT work. Following their advice I got the following results (on regular power):

Ruby Implementation	Time
ruby 1.8.5 (2007-04-23 rev 3539) [i386-jruby0.9.9]	26.7 +/ 3.79

These results are about a 20% improvement. That’s a good argument for really knowing your platform. JRuby still isn’t competing with Ruby’s speed, but it handles 20 minutes worth of log entries in about 27 seconds so I’d have to say it’s fast enough for what I’m doing. (And, I have this sneaking suspicion that the JRuby team has some more optimization work in their plans.)

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

• Some Real World Performance Notes
• JRuby 1.0.1 Real World Performance Notes
• JRuby 1.1 Performance Numbers

JRuby 0.9.9

A lot of people have jumped on the news of the JRuby 0.9.9 release, and deservedly so. This is big news for the whole Ruby community. My LogWatchR benchmark needs to be updated now that the released JRuby will run my application. This release also has all kinds of fixes, additions, and speed improvements.

I think people are missing the biggest story in the announcement though:

In response to all the things that needs doing before 1.0, we have decide to add two new committers to the team. Marcin Mielyski and Bill Dortch have both done some incredibly nice things for the JRuby project, and we’re very happy about them joining up as core developers.

While all the other stuff is good news, it’s all pretty short term stuff. Growing the list of committers by 50%, and with two solid developers with a history of good work means that the pace is going to continue to pick up and that things are just going to keep getting better in JRuby land.

So, congrats to all the developers and especially to Marcin and Bill.

Reviewing Beginning Ruby

I’ve been reading Beginning Ruby by Peter Cooper. I’m really impressed.

The forward (a comic by why the lucky stiff) grabs you immediately, and sets a great Ruby tone for the rest of the book. While Peter doesn’t hit the level of controlled insanity that Why carries off, as a member of the Ruby community he’s able stick to the same high level of “Rubyness”.

There are several things I really liked about the book. Peter hits several topics that you don’t normally see in a book for beginners, including: Benchmarking and Profiling, RubyInline, and Network Programming (including the use of GServer). I also enjoyed his examples. The shorter “building a text adventure” section was great. Chapter 12, “Tying It Together: Developing a Larger Ruby Application”, brings together several ideas and does a really good job of showing how to develop a tool with Ruby. Chapter 16, “Useful Ruby Libraries and Gems”, provides solid coverage of a number of gems and libraries.

Beginning Ruby is a great book for a new programmer, or a programmer new to Ruby. It’s a great alternative to the other beginner’s books on Ruby out there.

Some Real World Performance notes on Ruby 1.8 and 1.9

Update:

The performance numbers for Ruby 1.8.5 (below) are incorrect due to a mistake on my part. For updated in formation, please see my newer performance post.

p>One of the knocks against Antonio's Ruby Performance Shootout is that it uses a synthetic set of tests (the one's Ko1 wrote to exercise the parts of YARV he'd already done some optimization on). In an effort to get a 'more real' set of numbers (at least for me), I decided to use my LogWatchR tool to do some benchmarking.

LogWatchR is a program to watch syslog (we aggregate several hundred boxes' syslog entries to a pair of servers at my $JOB). I wrote it to use catalogs of good and bad entries (with dependencies, number of occurence thresholds, etc.) written in YAML and stored in external files, so that even a Junior Sys Admin could add new catalog entries pretty easily. To keep myself honest, I have a 20 minute sample of log entries and a simple pair of catalogs I use:

• 73607 log entries in the sample
• 1 entry in the good patterns catalog
• 5 entries in the bad patterns catalog

I can use this to make sure LogWatchR is performant, and works as expected.

In order to time LogWatchR, I ran the 20 minute sample through the program 5 times on each implementation of Ruby. Here are the results I got:

version	running time (in seconds)
ruby 1.8.5 (2006-12-25 patchlevel 12)	34.829 +/- .287
ruby 1.9.0 (2007-04-18 patchlevel 0)	12.967 +/- .095

At this point, all I can say is I'm really impressed with the work that the 1.9 team has done to speed Ruby up. Anytime you can get a better than 2.5x performance boost, you've gotta be doing something right.

JRuby 0.9.8 and rubinius don't work yet. They both have YAML related failures. I've talked with Evan about rubinius, and he says he's hoping that YAML will be working soon. I've also sent in a bug report to Ola, and hope that we'll see a fix in 0.9.9.

I plan on rerunning this benchmark periodically, so hopefully we'll see JRuby and rubinius included in the results soon.

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

• More Real World Performance Notes
• JRuby 1.0.1 Real World Performance Notes
• JRuby 1.1 Performance Numbers

Erlang and Haskell Books: First Impressions

I recently picked up a beta copy of Programming Erlang: Software for a Concurrent World to go along with my (paper) copy of Programming in Haskell. I figured if I had both books, I could make quick runs through them as I try to decide between Haskell and Erlang as the FP language I'm going to focus on this summer. What follows isn't really a review of either book, just a few first impressions.

Programming Erlang: Software for a Concurrent World looks like to be a very accessible book, that also goes into enough depth to be worthwhile. The version I got yesterday had 279 pages in the PDF, but an update was released today and my new copy hasn't found it's way here yet. I like what I've read of Joe Armstrong's writing and examples, and have caught on quickly to the initial concepts.

Programming in Haskell surprised me by being really small, only 171 pages (including the index). It on the scale of 'The C Programming Language', and so far it reminds me a lot of that book. I have to admit though, that I've always been put off by the seeming need of Haskell writers to use 'special Haskell characters' in their text, Programming Haskell even includes a table of 15 such symbols and how to represent them in ASCII. Bleargh!

So far, I'm leaning towards Erlang (mostly because of concurrency), but I'm not going to make up my mind for a while yet — too many other deadlines I need to deal with right now. As I get closer to the summer, I'll let you know which way I decide to go. (I'll also get real reviews of the two books up fairly soon.)

XRuby 0.1.4

On Tuesday April 10th, he XRuby team announced the release of XRuby 0.1.4, which can can be downloaded from code.google.com. This release feaures a new runtime (written by Dreamhead) that fixes a number of compatibility issues with MRI. According to their website, this release is also "much faster" than MRI, it will be interesting to see what happens the next time Antonio runs his benchmarks.

Upcoming work looks very promising too, Beanworms is working on the debugger, Yuesefa has a Google Summer of Code project to rewrite the XRuby parser to ANTLR 3.0, and Femto has also joined the team and will be involved in the parser rewrite.

The ANTLR 3.0 parser has a lot of potential outside the XRuby project. Since ANTLR 3.0 includes Ruby as a target output language, this may provide a solid Ruby in Ruby parser for other developers to use as well.

It looks like XRuby is a project that's gathering steam even though it doesn't get nearly the press that YARV, JRuby, or rubinius do.

March Blogging Contest Winner

March's contest had the lowest turnout of any of the contests so far — even April's has almost generated as many entries. That didn't mean it was any less difficult to pick a winner though. There were four top flight entries:

• one from Sean Hussey
• one from Jeremy McAnally
• and two from Phillip Toland (here and here)

I rally liked all of the entries, but Phillip's entries stood out. In fact, we had a hard time picking between them. In the end, we decided to pick him as the winner and to give credit to both of his posts. One thing that Phillip wrote summed up my thoughts about the contest. At the end of his article about Implementing Django's modular app feature, he wrote:

"New and experimental features can be distributed and evaluated by the Rails community at large without needing approval or acceptance from the core team. Some functionality may even be better implemented in plugins than in the core framework."

If this contest has made you think about how Rails might be better, I'd suggest you follow Phillip's suggestion and put together a plugin and some documentation — who knows you might just write the next big thing for Rails.

Phillip picked three great Apress books:

• Pro Javascript Techniques
• Pro CSS Techniques
• Pro MySQL

I'd like to thank Apress again for sponsoring these contests. They've been wonderful to work with through the first three months, and I look forward to the next three contests.

Apologies all around

I'm sure ya'll have noticed that I've not been very active recently. I've had a couple of emails about it, and Sean wrote in a comment on another post: "Any word on when the results will be in for the March contest?" Sadly, I've been more or less flat on my back for the last ten days with a really nasty cold/flu/virus thing. Today is really the first day I've been doing anything real (though I did manage to get a short post out to kick of the April contest). I don't want to make any promises right now, but I'm hoping to get things back on track this week. (And, yes, Sean that should include an announcement about March's contest.)

April Bloggin Contest

Ok, it's time for the April Blogging Contest. Sorry that this is coming out a little bit late. I've been slammed by a nasty cold, and a little behind on everything. Fortunately, I seem to be on the upswing after four days of sleeping 14-16 hours a day and hiding under a pile of quilts.

With Ruby 2.0 and all the alternative implementations in the air, I've been drawn to the idea of changes. This month's blogging contest theme is: "What Changes would make Ruby a better language without making it into something that isn't Ruby?"

Every serious programmer knows that his (or her) favorite programming language has warts. Here's you're opportunity to tell someone about it. All you need to do is post your thoughts on your own blog and link to them in the comments here. I'll accept entries until midnight (MDT) on April 30th. Then I'll work with my to co-judges to pick the winning entry.

As before, the writer of the winning entry will get three Apress books of his choice. So, what are you waiting for, it's time to win some books.