Nick Sieger

Which Tool Would You Use?

2009-06-12T20:34:27+00:00

I started in on the twice-yearly task of pruning our hedges today. So confronted with this task:

Which tool would you use?

I used both today, but realized I enjoy using the hand trimmers much more. With the electric trimmers, you can buzz through a lot of hedge quickly, but sometimes this happens:

With the hand trimmers, I can take my time and make precise cuts. The end result may take more time, but it turns out much, much better.

Software tools have similar feels to me. Java feels an awful lot like the electric trimmers. It’s heavy and powerful, but sometimes by the time you’ve finished with it, you’ve cut so far in that you may have missed a simpler, lighter solution.

Ruby feels like the hand trimmers. Precision, less code, more intent, and I can take my time to think through and arrive at a solution without leaving a huge trail of trimmings (code) behind me.

Project Kenai at JavaOne

2009-06-09T02:23:36+00:00

It’s just the beginning and a small milestone, but it’s a goal we set for ourselves by JavaOne last week that we reached: 10K registered users at http://kenai.com/. We were fortunate to be highlighted in the Tuesday afternoon keynote, which, to our collective relief, went off without a hitch. I also had a chance to speak a bit about Project Kenai behind the scenes in my technical session.

My slides are available and contain a decent overview of what we’ve been doing. One slide in particular seems to have surprised some folks: our codebase metrics.

12K lines of application code (everything in app/{controllers,models,helpers})
10K lines of views (HTML + template code in app/views)
1K lines of custom Javascript (public/javascripts excluding jQuery and plugins)
8K lines of test code (RSpec + plain text stories) (yes, we’re upgrading to Cucumber)
73.7% test coverage

If you’re doing Rails, you’re probably not all that surprised by these numbers; hopefully you’ve seen similar ones yourself. If you haven’t tried Rails, consider a site like kenai.com and ask yourself if you could build and maintain a production site like it with these numbers in your favorite language/framework.

Other takeaways from my talk:

Use Java what it’s good for; in this case, long-running server apps. The downtime of the JRuby/GlassFish-deployed Rails application has been minimal for us; the few cases where we’ve had issues, they’ve usually been self-inflicted application problems. Instead of running Monit with a pack of Mongrels that need to be periodically recycled, we run a few GlassFish domains per server and only recycle them when we deploy new code.
For the Java programmers out there, don’t be afraid to use stuff other than Java. We use Python, Django, Memcached, Perl, and anything that gets the job done.
You can build cool stuff quickly with community Rails plugins like attachment_fu, geokit, and will_paginate. Not news to Rails programmers, but I’d be interested to hear of any equivalents for Java-based web frameworks.
JRuby is a big win, allowing co-development on MRI and JRuby with deployment to GlassFish. JRuby’s java integration also allows for neat tricks like image_voodoo, a pure-Java imaging plugin for attachment_fu.

Three Years of JRuby on Rails

2009-05-13T21:21:37+00:00

Just yesterday the 3-year mark of JRuby running Rails passed by. In the intervening period since JRuby first started to run Rails, we’ve seen:

6715 commits to JRuby and counting (via git-rev-list --pretty=oneline 2fc4a18..HEAD | wc -l)
Over 40,000 messages to the JRuby mailing lists
3645 issues opened, 3019 of those already closed
18 JRuby releases (0.9.0 to 1.2), with 1.3 coming soon
The birth of activerecord-jdbc, jruby-rack, jetty-rails, glassfish gem and many other projects to make running Rails on JRuby as seamless as possible
Kenai.com, Oracle Mix, and a growing list of production sites running JRuby
FFI support allowing JRuby to interact with native code
JRuby and Rails running on Google App Engine

And yet, JRuby still has plenty of untapped potential and room for growth and adoption: in the existing Ruby and Rails communities where JRuby is showing promise as a stable, performant, concurrency-enabled, and leak-proof platform; and as a transformative force to capture the mindshare of a huge army of Java developers who aren’t even aware that there’s a language and runtime that allows them to preserve their skills and existing code while developing new applications faster and with much greater enjoyment.

Here’s looking to the future of continued growth for JRuby over the next three years. The best is yet to come!

Stand and Be Counted

2009-04-30T03:07:47+00:00

From _why’s constructive post entitled “A Selection Of Thoughts From Actual Women”:

Noirin Plunkett: (Regarding Mike Gunderloy’s decision to leave the Rails team.) It seems like so often in these things, even the “good guys” just tsk-tsk and shake their heads, without being willing to stand up and be counted. Actions speak louder than words...

I don’t like to use this blog as a soapbox for non-technical content, but I too have been conflicted over the past week. So I’m standing up to be counted. As a father of two girls who are starting to show an interest in computing, I consider it my obligation. If you agree with me, I hope you will do so as well by posting a brief statement on your own blogs. If you do, send me a link and I’ll link to you from here. So here’s my statement:

I want the Ruby, Rails, open source, and web development communities to be a dignified, respectful, inclusive, and welcoming place. Acts like putting questionable imagery in a conference talk are regrettable and harmful to those aims. We’ve all been witnesses to off-color jokes, misogynistic back channel chatter and unnecessary, trolling comments. I pledge to do better to stand up and call this behavior out when I see it in conferences, online and other public settings. I don’t expect it to go away but I’m not going to tacitly condone it any longer.

I think we can have our cake and eat it too. We can have a welcoming community while still courting the creativity, edginess and even controversy that makes us who we are; we also need to actively listen and be open to alternative viewpoints. There’s always another side to any story and we need to seek it out, especially when it’s drowned out by online discussion boards run amok.

I’m looking forward to continuing the conversation at the Women in Rails panel next week. I hope to see you there.

Update: I think the individual at the source of the incident that sparked this debate has been through enough so I’m following others’ leads and have anonymized the post.

Nick Sieger

Other statements (Thank you!):

JRuby on Google AppEngine: First Impressions

2009-04-11T04:10:51+00:00

I was surprised by Tuesday’s announcements as much as anyone else. Ola keeps secrets well. He sent me a pull request for jruby-rack just last week mentioning “some restrictive environments where you can’t start threads”. I didn’t blink, and instead just merged his patch.

Despite the surprise news, it turns out my timing wasn’t bad. Just a couple of weeks ago I was experimenting with the Python version of AppEngine, just to see what the fuss is all about. Even though Google’s had its share of criticism for building a platform that is difficult for developers to leave, the lock-in aspect didn’t bother me. I’m a pragmatist first, and I believe that we as developers are the only ones locking ourselves to a platform. We have a choice, after all. And look at all the developers willfully rushing to develop Cocoa applications for the iPhone. The fact that their code is not useful on any other device isn’t stopping them.

The thing with AppEngine is that it’s a unique platform all unto itself. That may seem brutally obvious, but the point seems to be lost in all the frenzy surrounding the Run-Rails-Struts-Spring-Groovy-Grails-Lift-You-Name-It-Framework on AppEngine this week. I’m not saying it’s a bad idea to try to run Rails on AppEngine; quite the contrary. I’m saying you need to be honest about the trade-offs and constraints. And in the case of Ruby and Rails, boy are there a bunch of them:

No regular net/http, restclient, ActiveResource usage. Google has a URL fetch library, and has hooked up Java’s HttpURLConnection to it, but none of the Ruby URL-fetching libraries use it.
No ActiveRecord. ‘Nuff said. For some folks, that’s a welcome change, but wrapping your head around AppEngine’s BigTable-backed data store takes some thought. You just can’t view it like a SQL engine.
No RMagick/ImageScience/attachment_fu. No ImageVoodoo even (no javax.image APIs). Google has it’s own image manipulation API.
Startup/first request processing time is currently an issue. It’s not clear yet how long Google keeps JVMs warm, so if your application is idle, the first few hits to it return 500 errors. I can only assume Google has a plan to address this.
Crypto. Although java.security and javax.crypto APIs are apparently whitelisted, I haven’t had time to figure out how to leverage them. JRuby’s jruby-openssl gem does not work, which means things like digest aren’t available. That’s currently a blocker for Rails’ cookie session store.
1000-files limit per application. In order to work around this, I ended up jarring up all the Rails gems when deploying a Rails application.

These are just a sampling of some of the problems you’re dealing with on the AppEngine frontier. They’re all solvable; it will take a little time and BST (blood, sweat and tears). The point is you can’t expect a Rails application on AppEngine to behave like all the Rails applications you’ve written previously.

In return for your troubles, you get the AppEngine value proposition, which is actually attractive in a lot of ways: Google runs the platform. You don’t have to worry about it. Transparent scaling, monitoring, logging, everything below your application code is taken care of. Single-step deployment, with application versioning and rollback. Scalable services: BigTable storage, memcached, scheduled tasks. My friend Curt Thompson of Best Buy’s Giftag.com talks about how they leverage AppEngine for a non-toy application. (Curt also helped me get my Python AppEngine experiment up and running.)

In the end, I’m still extremely excited about the prospect of using JRuby and Rails on AppEngine, and can’t wait to see what people build with these tools. If you want a little head start, you can check out the first Rails application I deployed, jruby-rack.appspot.com. The “application environment” page is the main dynamic action in the app, which just enumerates a bunch of request and system environment properties so you can get a feel for how things are set up in the AppEngine Java environment. The source code for the application is linked from the front page. Note that the app was deployed with JRuby trunk and JRuby-Rack 0.9.4; Warbler is not yet using these components but you can build them yourself, drop them in and try them. We’ll be updating JRuby, Warbler and other tools soon to make this process more seamless soon. Stay tuned!

My JRuby Talk at Philly ETE

2009-03-31T01:20:49+00:00

Last Friday at Philly ETE 2009 I gave a talk entitled, JRuby: Agile Glue for the Enterprise. The talk was aimed at the skeptical enterprise developer or architect that hasn’t yet considered adopting a dynamic language. (Unfortunately, most of the folks in the room were familiar with Ruby, so the pitch may not have hit the mark. At least they knew what they were getting into.)

The thesis is pretty concise: If you’re developing on a platform that doesn’t make use of a dynamic language, you’re limiting your development speed.

You’re using a heavy vehicle in the parts of your application where you should be driving a bike. I actually don’t care whether you use JRuby or Groovy or JavaScript or Jython. But you should use the right tool for the task at hand, and using Java to do systems integration or builds or frequently changing application logic is the jackhammer trying to hit a nail.

The great thing about this picture is that you can introduce a dynamic language on the slice on the right side without deploying Ruby code into your production application. You can ramp up Ruby (using JRuby) as a testing tool, a build tool, or a monitoring/deploy tool.

Once you’re a little more comfortable with Ruby and JRuby, you can start to embed it in non-critical corners of your application. Maybe you’ll eventually feel confident enough to even try using parts or all of Rails in your application. And doing it in a way that preserves your existing infrastructure when you need it, or phasing it out slowly instead of completely rewriting it.

JRuby can help you with this transition. It’s there every step of the way, bringing the best of both worlds (Ruby and Java) and bridging them in a way that makes programming on the Java platform fun again.

You can download the slides to see code examples for all these areas.

Video of My RubyFringe Talk

2009-02-10T21:38:35+00:00

If you follow me on Twitter you know that the video of my RubyFringe talk has finally been released on InfoQ!

If you don’t, then please take 30 minutes to check it out and let me know what you think. I had a lot of fun giving the talk, and I’m grateful that it was well-received. It should be watchable by techies and non-techs alike. Enjoy!

JRuby 1.1.6: Gems-in-a-jar

2009-01-10T20:04:00+00:00

As a result of some fruitful hacking at RubyConf 2008, I was able to modify JRuby so that gems can be loaded and used without having to unpack them. The feature became generally available with the 1.1.6 release last month. Gems in a jar!

by splorp on flickr

This opens up a couple new possibilities for running, packaging and deploying JRuby-based applications. Here are some ideas:

Run Gem-based applications with `jruby-complete.jar`

JRuby has bundled Rake and RSpec since version 1.0. As of JRuby 1.1.6 the versions we bundle are Rake 0.8.3 and RSpec 1.1.11. With jruby-complete-1.1.6.jar you can easily run these with java -jar:

$ java -jar jruby-complete-1.1.6.jar -S rake --help
rake [-f rakefile] {options} targets...

Options are ...

$ java -jar jruby-complete-1.1.6.jar -S spec --help
Usage: spec (FILE|DIRECTORY|GLOB)+ [options]

    -p, --pattern [PATTERN] ...

Package gem collections into reusable jar files

One of the features I added was to enhance RubyGems to search for directories named specifications on the classpath and add them to the Gem.path automatically. This means you can package up a whole gem repository into a jar file for easy reuse and sharing of commonly used gems. There isn’t a tool for this yet, but the process is pretty straightforward. (If someone plays with this and can come up with a patch to build this into JRuby, we’ll gladly accept one.)

First, create a gem repository by installing the gems you want into it. Let’s say you want to package the natural language date/time parser chronic:

$ java -jar jruby-complete-1.1.6.jar -S gem install -i ./chronic chronic --no-rdoc --no-ri
Successfully installed rubyforge-1.0.2
Successfully installed rake-0.8.3
Successfully installed hoe-1.8.2
Successfully installed chronic-0.2.3
4 gems installed

With this command, RubyGems created chronic/bin, chronic/cache, chronic/gems, and chronic/specifications directories and installed chronic and its dependencies into it. Now, simply package those directories into a jar file:

$ jar cf chronic.jar -C chronic .

When you inspect the contents of the jar, you’ll see the gem repository structure in the root of the jar file:

$ jar tf chronic.jar | head
META-INF/
META-INF/MANIFEST.MF
bin/
bin/rake
bin/rubyforge
bin/sow
cache/
cache/chronic-0.2.3.gem
cache/hoe-1.8.2.gem
cache/rake-0.8.3.gem

Chronic is now a re-useable jar library that can be easily loaded, either by requiring the jar in ruby code or adding to the classpath:

$ # Without chronic.jar
$ java -jar jruby-complete-1.1.6.jar -S gem list

*** LOCAL GEMS ***

rake (0.8.3)
rspec (1.1.11)
sources (0.0.1)

$ # With chronic.jar
$ java -jar jruby-complete-1.1.6.jar -rchronic.jar -S gem list

*** LOCAL GEMS ***

chronic (0.2.3)
hoe (1.8.2)
rake (0.8.3)
rspec (1.1.11)
rubyforge (1.0.2)
sources (0.0.1)

Note: Unfortunately this technique does not yet work with gems that include Java code in embedded jar files (e.g., hpricot, mongrel, jruby-openssl). See JRUBY-3299. (We’d like to get this fixed for 1.1.7, but could use your help.)

Bundle pure-Ruby gem applications into an uber-jar

Taking a cue from the previous techniques, we can stuff the gem directories into a copy of jruby-complete-1.1.6.jar rather than creating a new jar, and distribute an entire gem-based application in a single file. Imagine something like:

$ java -jar jruby-complete-1.1.6.jar -S gem install -i ./mycoolapp mycoolapp
$ jar uf jruby-complete-1.1.6.jar -C mycoolapp .
$ mv jruby-complete-1.1.6.jar mycoolapp.jar
$ java -jar mycoolapp.jar -S mycoolapp

Bonus points to the enterprising individual who provides a patch to make this a one-step process, including creating a mechanism to provide a default -S script so that java -jar mycoolapp is all that’s needed to run the application.

I hope you find interesting uses for this new feature. Let us know what you make with it!

Warbler 0.9.12 Released, Includes JRuby 1.1.6

2008-12-19T13:46:33+00:00

I finally got around to releasing the next version of Warbler. I try to keep pace with JRuby releases but 1.1.5 had some bugs that I wanted to wait out (in particular, one with Rubygems assuming Etc is always available).

New in this release is better automatic gem detection for both Rails and Merb. In particular, Warbler will use the contents of Merb’s config/dependencies.rb file. As an added bonus, only runtime dependencies are loaded. This detection is done by running the Rails environment or the Merb merb_env Rake task. Usually, loading the application environment requires a database connection. If you don’t want this behavior, you can manually specify dependent gems in config/warble.rb and turn off the framework detection with Warbler.framework_detection = false. See the documentation for details.

Warbler 0.9.12

Allow framework auto-detection to be disabled. Set Warbler.framework_detection = false at the top of config/warble.rb or uncomment the line from a newly generated config.
Add configuration option to set manifest file (thanks Tommy McGuire)
Mitigate RubyGems 1.3 compatibility issue (thanks Jens Norrgrann)
Add experimental war:exploded task. This allows you to deploy your application in an exploded mode, thus allowing continual development without re-warring and re-deploying. Feedback is appreciated if you try this feature; it may not work in all application servers and for applications other than Rails.
Handle Rails gem dependencies better (thanks Laszlo Bacsi)
Auto-detect Merb dependencies (Merb >= 1.0 only). Please give feedback if you try Warbler with a Merb 1.0 app.
Ignore gem development dependencies
Upgrade to JRuby 1.1.6 and JRuby-Rack 0.9.3

My Article for Ruby Advent 2008

2008-12-19T05:04:00+00:00

I wrote an article for Ruby Advent 2008 about using JRuby, RMagick4J, Gruff, and JMX to create a simple JVM memory monitoring application. Go check it out and let me know what you think.

I’ve also posted the source for the article.

Happy Holidays!