Showing posts with label jRuby. Show all posts
Showing posts with label jRuby. Show all posts

Wednesday, February 11, 2009

Ruby on Rails Makes Me Happy

Last year I got to work on my first Enterprise Rails application and although there were some brief moments of coolness, that project was punctuated with a lot of things that just made it suck overall. In fact, I was doubting that bringing Rails to the enterprise would be a good thing. There were just to many other things wrong that had nothing to do with the technology.

But half a year later our enthusiasm for Ruby on Rails hasn't been seriously diminished despite a less than stellar project, and surprisingly our commitment is growing. From three developers doing Rails we've grown it to five and my managers have fully accepted it and are pushing it forward for most new projects.

Excitingly for me, I was recently assigned a small but very high profile project. And this time I think I've been able to do things the best way I know how in a very short period of time. The controllers are RESTful, my routes are appropriately nested, the layouts are clean table-free HTML with CSS and the Javascript is unobtrusive. I really dig Prototype and the app is sprinkled with just the right amount of AJAX and the Scriptaculous effects are not gratuitous.

Quite honestly I'm pretty thrilled with this app. It's only been a week or two worth of effort but it's been thoughtful and extremely efficient. So efficient that I think the app will be fully functional before the TQA and Production Tomcat servers I requested will be provisioned by the server team (remember I'm in a big enterprise). And yes, you read that right I'm deploying to a JEE web container. I'm past any trepidation I may have once harboured about JRuby vs MRI Ruby. To me it's a proven part of my deployment strategy that I can depend on.

Anyway I'm a happy developer again. I'm getting apps written and deployed for my users and I love the look of my code. The cool thing is that Rails keeps getting better. Rails 2.3 is just around the corner. I like the application templates and the integration of Rack. I still have to bring up my testing game but give me another week and I think my tools of choice (RSpec, Remarkable, and FactoryGirl) will have me cranking out better test coverage than I've ever had before.

Anyway let me wrap this up with some of the things I think are wicked about Ruby and Rails and the various gems:
  • pluralize
  • belongs_to, has_many :through (declarative ORM)
  • Model.all
  • Model.paginate (will_paginate gem is awesome)
  • link_to_if
  • select, collect, each (collection methods are cool)
  • statement if expression (statment modifiers rock)
  • distance_of_time_in_words_to_now
  • model_url
  • before_update, before_delete
  • validates_presence_of, validates_length_of (declarative validation is sweet)
  • Ruby, a REAL language, in my view templates!
  • jruby script/console oracle (interacting with Oracle through my models via JDBC)
  • rake war:clean war (Thank you warbler)
  • script/autospec (even better on my Mac when integrated with Growl)
  • ActionMailer with layouts (my HTML emails never looked so good)
  • Ajax.Request, Ajax.Updater (Yay Prototype)
  • case (yeah just a nice simple case statement)
  • auto_discovery_link_tag and builder (yeah I added an RSS feed for good measure!)
  • Railscasts (an exemplary example of a great community, Ryan Bates you rock!)


Thursday, December 11, 2008

JRuby & Rails 2.2

We just started converting things over to Rails 2.2.2 and I thought I should say that the one feature that really kicks some ass is its thread safety. JRuby 1.1.5 (very soon to be 1.1.6), which takes advantage of Java's native threads, combined with this latest version of Rails finally makes for a very good deployment story.

Rails' traditional single threaded model, while conceptually nice for development, never really made things easy for deployment. In MRI-land, you always needed multiple processes, translating into multiple instances of Mongrel. In JRuby we needed multiple instances of the JRuby runtime. While it worked, it was definitely a bit of a memory pig. With Rails 2.2 we can now run with only one JRuby runtime in a JEE web container that was already multi-threaded. Now memory consumption is several fold smaller than what it was before and we now have a much better story to tell everyone. Thanks to everyone on the JRuby and Rails teams!

Now, I shouldn't just end with a big hurrah to everyone without mentioning that we did run into a problem with some thread unsafe code in our own app. It took awhile to find it (a week) so the one word of caution is be careful about any shared state in your application (in our case it was a rather obvious global variable that we seemed to keep overlooking).

In any case, Rails and JRuby are a great match for enterprise web app development. I've been hesitant to say that in the past because of a few rough edges like the one I mentioned before but now I think it's about time everyone should look at this fantastic combination.

UPDATE:
Thought I'd add a link to a recent Ruby shootout. It's reporting on the performance of JRuby vs other Ruby implementations and the importance of threading.

Wednesday, August 06, 2008

Calling Java from JRuby to do the dirty work

I recently had to try and read a UTF-16LE-BOM encoded text file from Ruby. I couldn't figure out how to get Ruby to deal with the double byte characters in the file. But I did know that Java has very good UTF support so I decided to let Java do the heavy lifting for me. I ended up with something like this:
require 'java'

import java.io.InputStreamReader
import java.io.ByteArrayInputStream
import java.io.BufferedReader

data = ''
File.open("text.txt", 'rb'){|f| data = f.read}

#strip the BOM (Byte Order Marker)
data.slice!(0..1)
#let Java deal with the UTF-16 encoding
reader = BufferedReader.new(
InputStreamReader.new(
ByteArrayInputStream.new(data.to_java_bytes), 'UTF-16LE'))

while ((s = reader.read_line) != nil)
puts s
end
It may not be the perfect solution (I'd like to see a regular Ruby solution) but I suppose leveraging the Java libraries was the whole point of JRuby in the first place wasn't it!

(Executing File.open("text.txt", 'rb'){|f| puts f.read} looked fine on my Mac, except for the BOM, but looked terrible in the console on Windows. The solution above actually converts the text from double byte to single byte characters)

Tuesday, May 13, 2008

My first JRuby contribution

I've reported lots of bugs before but this is the first time I submitted a fix back to an open source project.  The fix was to the JRuby-Extras ActiveRecord-JDBC project to allow you to do something like this for a Rails model class against Oracle:  

class Person
  set_table_name "department.people"
end

Accessing the database from someone other than the schema owner and therefore fully qualifying the table with schema is a rule I needed follow in order to deploy a webapp in my current IT department.  

I posted the original fix quite a while ago but nobody really took notice. Then Jesse Hu came along and made it better (and probably independently I might add) and also added a couple other fixes for things I hadn't noticed.  

But unfortunately neither one of us seemed to really know how to submit the fix so it got ignored for awhile.  Originally I created a patch and just pasted the text into the body of my comment.  Jesse attached the entire Java file.  A few days ago when Thomas Enebo asked for things we'd like to see fixed in the next release of JRuby I jumped at the chance.  After I got a hint about what to do from Charles Nutter, I got the latest version of the project from SVN, created a .patch file from Jesse's source, and then submitted it back to the JRuby-Extras Tracker and then finally back to JRuby's JIRA issue.

Today I got notice from Nick Sieger that it'll be in the next version.  Very cool.

Unfortunately I have to admit that I still a need a bit of work on my testing skills because I wasn't able to figure out where or how to insert some unit tests to prove that my fix worked.  Something to save for the next time. I'm just happy I can finally get rid of my custom version of this library.