This is the blog of Brasten Sager, a software engineer, Mariners fan, guitarist, haphazard philosopher.
Heavily modified, but based on the RubyRobot theme for TextMate (worth checking out).
HTML/XML colors are intentionally higher contrast than normal since, in my experience, I'm often looking for specific attributes/values or Ruby code.
Slight differences between NetBeans and TextMate versions, obviously, due to different syntax colorization rules. NetBeans pictured below:
The top three things Ruby developers SHOULD be paying attention to:
I have to admit, this one has surprised me. I was a big fan of JRuby a while back, but not as a general-purpose Ruby runtime. It was showing some promise as a niche integration project, but nobody was actually going to run Rails applications on it, right?
Oops.
Turns out, running a Rails application on JRuby is becoming more reasonable every day (more on that later). JRuby is making huge leaps in performance and compatibility and, I believe, Ruby-to-bytecode compilation has the potential to be a game-changer.
I'm as big of a TextMate fan as the next guy. One of my favorite side-effects of switching to Ruby was leaving my old Java IDEs behind. Well, time has changed, and as of NetBeans 6 Beta 1 I've pretty much left TextMate behind.
I'm not necessarily saying that you should switch to NetBeans TODAY... but at the pace they're going, it's definitely something to keep your eye on in the near future.
The fact is, current production Ruby/Rails options kind of suck. Yes, it's as "easy" as "mongrel_rails start", at first. But then you need to set up a cluster of, let's say, 3 mongrels. Then you need to proxy requests from Apache in some kind of load-balanced fashion which -- in many installations -- requires a separate application. Then you REALLY need to set up monit because, honestly, Mongrel doesn't stay up 24x7x52.
Then what if one of them gets slashdotted (literally or figuratively)? I had to run 8 Mongrels on one particular application just to keep it running during a traffic spike. Now, the application's developers had NOT designed it for high-traffic, but regardless, it still took frantic manual intervention to keep it running.
... now imagine a Rails server that requires only one instance running... performant enough to bypass Apache in many cases... capable of scaling up or down the number of Rails threads running based on traffic levels, automatically... can do all of this for any number of Rails applications you wish to deploy, and comes with a pretty nifty web console to administrate it all (if desired).
That's the promise of Rails on GlassFish v3. It's still a ways off, but you'd be doing yourself a favor to start thinking about it now.