Posted by Nick Sieger
Wed, 24 Feb 2010 03:58:59 GMT
Synopsis
jruby -S rails newapp -m http://jruby.org/rails3.rb
When creating your Rails 3 application, just add the JRuby-specific template (-m http://jruby.org/rails3.rb).
Details
$ jruby -S gem install rails --pre --no-rdoc --no-ri
Due to a rubygems bug, you must uninstall all older versions of bundler for 0.9 to work
Successfully installed i18n-0.3.3
Successfully installed tzinfo-0.3.16
Successfully installed builder-2.1.2
Successfully installed memcache-client-1.7.8
Successfully installed activesupport-3.0.0.beta
Successfully installed activemodel-3.0.0.beta
Successfully installed rack-1.1.0
Successfully installed rack-test-0.5.3
Successfully installed rack-mount-0.4.7
Successfully installed abstract-1.0.0
Successfully installed erubis-2.6.5
Successfully installed actionpack-3.0.0.beta
Successfully installed arel-0.2.1
Successfully installed activerecord-3.0.0.beta
Successfully installed activeresource-3.0.0.beta
Successfully installed mime-types-1.16
Successfully installed mail-2.1.3
Successfully installed text-hyphen-1.0.0
Successfully installed text-format-1.0.0
Successfully installed actionmailer-3.0.0.beta
Successfully installed thor-0.13.3
Successfully installed railties-3.0.0.beta
Successfully installed bundler-0.9.7
Successfully installed rails-3.0.0.beta
24 gems installed
And:
$ jruby -S gem install activerecord-jdbcsqlite3-adapter --no-rdoc --no-ri
Successfully installed activerecord-jdbc-adapter-0.9.3-java
Successfully installed jdbc-sqlite3-3.6.3.054
Successfully installed activerecord-jdbcsqlite3-adapter-0.9.3-java
3 gems installed
Finally:
$ jruby -S rails newapp -m http://jruby.org/rails3.rb
create
...(app creation)...
apply http://jruby.org/rails3.rb
apply http://jruby.org/templates/default.rb
gsub Gemfile
run jruby script/rails generate jdbc from "."
...(warnings omitted)...
exist
create config/initializers/jdbc.rb
create lib/tasks/jdbc.rake
$ cd newapp
$ jruby script/rails server
...(warnings omitted)...
=> Booting WEBrick
=> Rails 3.0.0.beta application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2010-02-23 19:44:26] INFO WEBrick 1.3.1
[2010-02-23 19:44:26] INFO ruby 1.8.7 (2010-02-23) [java]
[2010-02-23 19:44:26] INFO WEBrick::HTTPServer#start: pid=16449 port=3000
Recap
You’ll have best results with JRuby 1.5 snapshots, which include RubyGems 1.3.6. JRuby 1.5 final is coming soon. Also, the new activerecord-jdbc-adapter 0.9.3 release is required for Rails 3 compatibility.
The Rails experience on JRuby continues to get better.
Tags jruby, rails | no comments
Posted by Nick Sieger
Thu, 28 Jan 2010 15:16:49 GMT
I got a note from a community member about an annoying problem that a few people have run into when installing activerecord-jdbc-adapter (AR-JDBC) into a C Ruby implementation:
NameError: uninitialized constant
ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::PGconn
Turns out it’s pretty easy to momentarily forget to use jruby -S gem or jgem and just gem install activerecord-jdbc-adapter and suddenly your pg Postgres gems are not working properly. I thought it was worth documenting here in case others run into this problem.
I apologize for the clash. I had to provide a stub pg.rb in AR-JDBC inside of JRuby so that I could get active_record/connection_adapters/postgresql_adapter.rb to load with a database adapter type of postgresql. Because of load path order issues, I couldn’t get AR-JDBC’s code to load before ActiveRecord’s. At the time I was thinking this wouldn’t be a problem because the pg library won’t work on JRuby anyway, right? Wrong.
I can think of a couple options going forward:
- Submit a patch to ActiveRecord so that
active_record/connection_adapters/postgresql_adapter.rb can load without requiring pg up front and then AR-JDBC won’t have to stub it out.
- Display a big fat warning message when AR-JDBC is installed into anything other than JRuby.
Any other thoughts?
Tags jruby, ruby | 2 comments
Posted by Nick Sieger
Fri, 06 Nov 2009 16:06:37 GMT
It’s with a modicum of fanfare and a cocktail of orange peel, maraschino, bitters, bourbon and vermouth that I announce the 0.8.2 release of Hpricot.
The angly thingies are just two martini glasses turned on their side, see? Pouring out hpricoty goodness for you. (I don’t know if _why imbibed alcoholic beverages but I feel the desire to raise a glass to him.)
This release is mostly a refresh; the previous release was way back in April. From the Git logs I can see that there were a few bug fixes since then. Otherwise, the main addition is a modern JRuby release, thanks to Ola Bini. (the previous was the 0.6 series). This does fix a fairly old, popular JRuby bug.
As for the future of Hpricot, it’s up to you. I know it’s still a trusty tool for many; I have no grand plans to change it. So if you encounter bugs and want to send patches, I’m happy to serve as your curator.
Tags hpricot, jruby, rails, ruby | 2 comments
Posted by Nick Sieger
Mon, 12 Oct 2009 18:30:45 GMT
As announced last week on the jruby-user list, 0.9.2, the latest activerecord-jdbc-adapter release, has been pushed out. Please install the gem in the usual fashion and try it out on your applications.
One of the most contentious bugs broke db:create and db:drop, ruining the quick-start workflow that Rails is known for. To fix this, a creative solution was needed that ended up bringing some nice benefits.
The problem stemmed from the fact that some database setup tasks in Rails 2.3 no longer load the environment; instead they just load the configuration data and work with that. This means that there is no easy way to hook into Rails and override those tasks, which is what activerecord-jdbc needs to do.
The solution I ended up with was to create a jdbc Rails generator that inserts a couple files into your rails application that inject the JDBC logic into ActiveRecord and the database rake tasks. To wit:
$ jruby script/generate jdbc
exists config/initializers
create config/initializers/jdbc.rb
exists lib/tasks
create lib/tasks/jdbc.rake
The upside of this new technique is that now that we have a way to ensure the JDBC adapter is properly injected into Rails, and you no longer need to use adapter names like jdbcmysql, jdbcsqlite3 and the like. The net result is that database.yml no longer needs to be modified for the default Rails databases (mysql, sqlite3, postgresql). So while we introduced one additional step in the process to bootstrap a Rails application under JRuby, the removal the step where database.yml needs to be modified results in a more predictable workflow.
The new JRuby-specific Rails workflow looks like the following, assuming you’ve installed the activerecord-jdbc-adapter gem into JRuby, along with the appropriate database driver gem (e.g, jdbc-mysql). (Of course, the gems only need to be installed once per JRuby installation.)
- Create your Rails application as usual.
- Run the
jdbc generator as shown above.
- Profit!
Additionally, if you maintain a Rails application template that you use to start a new application, you can simply add generate(:jdbc) to that template’s script.
What’s more, the presence of the JDBC files in your application are guarded and only inject JDBC support when running under JRuby, so you can safely keep them around when running Rails under multiple Ruby implementations.
For more details of what’s in the release please consult the mini-changelog on Rubyforge and the list of fixed issues in JIRA.
Tags activerecord, jdbc, jruby | 9 comments
Posted by Nick Sieger
Sat, 12 Sep 2009 04:22:15 GMT
I’m so excited to see the news finally hit the wire today about the paint drying on the plans for JRubyConf 2009!
We always joked about having the first JRubyConf in the middle of a brisk Minnesota winter at Tom’s Cabin, but I think this will do nicely!
Please go quickly and register! Though there is no fee for the day, we only have a limited number of spots available!
P.S. This post is a little late to the party; I was in the air on the way back from JavaZone. If you want a peek at what’s been happening in JRuby land you can check out the slides from my talk there.
Tags jruby, jrubyconf | no comments
Posted by Nick Sieger
Thu, 27 Aug 2009 20:12:00 GMT
So, after a long, busy summer, I’m finally back onto support of the various bits for JRuby web application development (meaning Warbler and JRuby-Rack). I’m pleased to announce the 0.9.5 release of JRuby-Rack and the 0.9.14 release of Warbler! All of this brought to you courtesy of Engine Yard, my new employer!
Both of these are long-overdue releases. Here’s the low-down on each:
JRuby-Rack 0.9.5
For the full history, see the 0.9.5 entry in the History.txt file.
One bad bug in particular prevented you from running Rack-powered Rails 2.3 out of the box at all because JRuby-Rack bundled an older version of Rack than needed by Rails. This has been fixed for good by not forcing JRuby-Rack’s bundled copy of Rack on your application; any version of Rack you include (either via gems or vendor’ed in Rails or your application) will take precedence.
Another major upgrade is the introduction of rewindable requests. The Rack spec dictates that the request IO object be rewindable and that server/handler writers (such as myself) need to buffer the input. You’d think that Java application servers would do this for you, but, as is the case with Java so often, servers perform the bare minimum amount of work and leave the grunt work to the application developer. So JRuby-Rack takes care of the input buffering for you. The first 64k of input data are buffered entirely in memory; above that the request body is dumped into a temp file. (64k is a default and is configurable. If you have a better suggestion for a default, let me know.)
Finally, this release brings back Java Servlet-based sessions for use with the Rack-based session mechanism. For those of you experimenting with hybrid Rails/Java applications and want to share session data between them, you’ll want this. Servlet sessions are not the default; you need to turn them on by setting ActionController::Base.session_store = :java_servlet_store.
Warbler 0.9.14
Warbler’s main change this release is to unbundle JRuby. When you install Warbler as a gem, you’ll now get a dependent gem called jruby-jars installed for you. We’ll be releasing a new version of this gem with every release of JRuby, and you’ll be able to upgrade JRuby versions without having to update Warbler.
JRuby-Rack is still bundled with Warbler for now (0.9.14 comes with JRuby-Rack 0.9.5 of course), but the jar file is not that big and the two projects tend to be released around the same time. By Warbler 1.0 I hope to have a mechanism to unbundle all jar files so that Warbler is just a lightweight Rake library with enough smarts to fetch the binaries your application needs.
Future
The projects seem to be headed for a 1.0 release soon. For these releases, I hope to ensure that they are both ready to take advantage of Rails 3 out of the box. One of the ways is to use Bundler in Warbler to manage gems. Hopefully as Rails 3 and other applications start to standardize Bundler manifests, it means less custom configuration for Warbler.
Since the core of JRuby-Rack seems to be stabilizing, the next promising step is to explore more ways to integrate with existing Java code and Java applications. This should dovetail nicely with JRuby’s plan for better Java integration in the upcoming JRuby 1.4 release. For example, Christian Seiler explained how he’s using JRuby-Rack to integrate JMS while running an in-memory ActiveMQ server for his site blissmessage.com. These kinds of ease-of-use scenarios where you can start a single process with all of your application needs: web server, message queue, timer for periodic tasks etc. present a great way to jumpstart a project. I’d like to see some of these APIs standardize so that we can transition from all-in-one development servers up to scalable production clusters where app, message queue, and other servers are separated and standalone.
The fellows over at Google have been busy this summer with the appengine-jruby project, and there are opportunities for tuning that experience as well.
Of course, your suggestions are welcome too. I’d appreciate it if you’d drop me a line if you’re doing something novel with these tools, so I can help shape future directions around people like you who are Getting Things Done with them!
(Postlude: Both these projects need a logo. If you can mock something up, I’d love to see some ideas!)
Tags engineyard, jruby, rack, warbler | 1 comment
Posted by Nick Sieger
Tue, 09 Jun 2009 02:23:36 GMT
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.
Tags jruby, kenai, rails | 3 comments
Posted by Nick Sieger
Wed, 13 May 2009 21:21:37 GMT
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:
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!
Tags jruby, rails, ruby | 4 comments
Posted by Nick Sieger
Sat, 11 Apr 2009 04:10:51 GMT
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!
Tags appengine, google, jruby, rails | 2 comments
Posted by Nick Sieger
Tue, 31 Mar 2009 01:20:49 GMT
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.
Tags jruby, phillyete | 1 comment
