Posted by Nick Sieger
Thu, 14 Oct 2010 15:25:51 GMT
Just a quick note that
activerecord-jdbc-adapter has finally hit 1.0.0. Install it today:
gem install activerecord-jdbc-adapter
Included are adapters for MySQL, PostgreSQL, SQLite3, Derby, HSQLDB, H2, and Microsoft SQL Server.
gem install activerecord-jdbcmysql-adapter
gem install activerecord-jdbcpostgresql-adapter
gem install activerecord-jdbcsqlite3-adapter
gem install activerecord-jdbcderby-adapter
gem install activerecord-jdbchsqldb-adapter
gem install activerecord-jdbch2-adapter
gem install activerecord-jdbcmssql-adapter
You can also use
activerecord-jdbc-adapter with Oracle, DB2, Sybase, and Informix. Just ensure that the database JDBC driver jar files are mentioned in
require them directly in your script or application. Then, configure
adapter: set to one of
This release promises superb compatibility with Rails 3. We now have the ActiveRecord test suite running in CI and the 1.0.0 release is 100% green when run on MySQL. (SQLite3 is right behind with just 13 failures, and we hope to fix those soon.)
As mentioned before, to get started with Rails 3, JRuby and
activerecord-jdbc-adapter, simply run:
$ rails new app --database mysql --template http://jruby.org
$ cd app && bundle install
Using activerecord-jdbc-adapter (1.0.0)
Using jdbc-mysql (5.0.4)
Using rails (3.0.0)
Your bundle is complete! Use `bundle show [gemname]` ...
One new feature in 1.0.0 is the ability to define an extension adapter for your proprietary JDBC database without needing to hack the
activerecord-jdbc-adapter source code. To get you started we extracted the
activerecord-cachedb-adapter and put it on Github for you to use as a template.
The 1.0.0 release had over 200 commits poured into it and lots of great help from the community. Thanks to David Kellum, Dmitry Denisov, Dwayne Litzenberger, Gregor Schmidt, James Walker, John Duff, Joshua Suggs, Nicholas J Kreucher, Peter Donald, Geoff Longman, Uwe Kubosch, Youhei Kondou, Michael Pitman, Alex B, and Ryan Bell for their contributions to this release.
Posted by Nick Sieger
Mon, 30 Aug 2010 17:06:52 GMT
I am pleased that my Engine Yard webinar on JRuby and deployment is available for general viewing. While the JRuby deployment story is still evolving and maturing, and the 60 minute time frame is too short to cover the issues in depth, I hope you’ll find the content at least gives you some ideas or directions to look.
As always, feel free to contact me with any questions!
Deploying, Monitoring and Troubleshooting Rails on the JVM with JRuby from Engine Yard on Vimeo.
Posted by Nick Sieger
Wed, 24 Feb 2010 03:58:00 GMT
jruby -S rails new myapp -m http://jruby.org/rails3.rb
When creating your Rails 3 application, just add the JRuby-specific template (
$ 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
$ 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
$ jruby -S rails new myapp -m http://jruby.org/rails3.rb
run jruby script/rails generate jdbc from "."
$ cd myapp
$ jruby script/rails server
=> 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
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.
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.
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
- 10K lines of views (HTML + template code in
- 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.
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!
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
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!
Posted by Nick Sieger
Fri, 19 Dec 2008 13:46:33 GMT
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.
- 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
Posted by Nick Sieger
Sun, 19 Oct 2008 18:30:52 GMT
Project Kenai has been open for business for over a month, and I’m just writing about it now?
Blogging is hard. Let’s go shopping, m’kay?
http://www.flickr.com/photos/zen/1229934/ on flickr
There’s no excuse for not writing until now about the JRuby on Rails project that’s kept me busy at work since I joined Sun almost 18 months ago. (Ok, there are a few lame ones. Twitter. Conference travel. Presidential political news distractions. Also, Tim’s write-up filled in my side of the story immediately after the launch.)
So, better late than never. Actually, by looking back on the first month of operation I think that I can give you a better idea of where we’re going, supported by what we’ve done (as well as what we haven’t done), rather than what I might have said we’re going to do.
Word of Mouth
One thing we haven’t done is put the heavy Sun marketing blitzkrieg operation to work on our behalf. Word has made its way around the blogs, and even onto a few tech news sites, but we’re still in a growth phase for the project, and we’d rather earn respect quietly through a site that people find useful instead of shouting the word from the mountain tops.
We have established that we intend to embrace change, having deployed three additional releases since launch. During that time, we’ve added a new feature, fixed bugs and UI inconsistencies, and worked on performance and infrastructure issues.
We’ve also seen community participation grow. We’ve had over 2100 people join, 79 projects have been created, and we’re starting to see real activity in those projects. These are modest but respectable numbers.
JRuby on Rails
As you’ve heard, kenai.com runs on JRuby and Glassfish and uses bits of software I’ve worked on like activerecord-jdbc, Warbler and JRuby-Rack. Having worked on JRuby itself and Rails support for JRuby for a couple years now, this is a personal validation of all that work. One of the things I’ve relished the most working on Project Kenai for the past year is to be able to build infrastructure software for and based upon real-world use. The JRuby story continues to get stronger every day, with things like thread-safety in the upcoming Rails 2.2 release adding fuel to the fire.
(Not Yet) More Than Just a Forge
One of the things that might have caught your eye when you came to the site is the slogan More Than Just a Forge. That’s silly, you might say to yourself. What do they have here that I can’t get at another project hosting site? And if you said that, I’d heartily agree with you – the marketers are just getting a little antsy.
However, that doesn’t mean we don’t have plans. For now, we’re taking the Gmail Launch strategy, starting with a simple, solid foundation, and gradually inviting more and more to participate, stabilizing and growing the platform, and soliciting feedback from our user base. We do already have a healthy amount of requests on our UserVoice page, and while we hope to make good on a number of those, we also plan to do some new things that aren’t being done elsewhere. Stay tuned, and I hope to be able to reveal some more in the coming months as we start to roll out the implementation of those plans.
In the meantime, if you’d like an invite to create a project, drop me an email. If you have comments or requests, you can share them with me privately via email, on the site in the forums, or on our UserVoice page.
Posted by Nick Sieger
Thu, 10 Jul 2008 05:10:27 GMT
The other day several people chimed in wondering how I set up this blog with JRuby and Glassfish. One of the reasons I didn’t include the details in the post is that it’s not really much different than any JRuby/Glassfish/Warbler deployment, but in case you don’t know what that looks like, here are the basics.
I’m running on a Joyent Accelerator, which runs OpenSolaris, which has JDK 6 installed by default. If you’re running on some flavor of Linux, hopefully there’s a package available for you to install, otherwise you may have to download a self-extracting binary.
This step is actually straightforward; not at all as problematic as you might expect of a piece of Java technology! In the parent directory where you want Glassfish to be installed (substituting the name of the Glassfish jar you downloaded as appropriate):
java -Xmx256m -jar glassfish-installer-v2ur2-b04-sunos_x86.jar
chmod -R +x lib/ant/bin
./lib/ant/bin/ant -f setup.xml
You may want to add
GLASSFISH/bin to your path so that you can run the Glassfish
asadmin command from anywhere.
On Solaris, SMF is the subsystem that is used to ensure services are started at boot time (among other things). Glassfish works nicely with SMF. On other systems, there may be
/etc/rc.d init scripts out there, or you can roll your own (
asadmin start-domain and
Download JRuby and unpack it somewhere. I recommend adding
JRUBY_HOME/bin to the end of your path, so it doesn’t clash with Matz-Ruby.
Install Warbler and activerecord-jdbcmysql-adapter
In addition to Warbler, I’m using the activerecord-jdbcmysql-adapter to connect to the blog’s database. Both can be installed with Rubygems:
jruby -S gem install warbler activerecord-jdbcmysql-adapter
With Rails 2 and up, the application’s
config/database.yml file should be updated for
<% jdbc = defined?(JRUBY_VERSION) ? 'jdbc' : '' %>
adapter: <%= jdbc %>mysql
# same for test/production...
Otherwise, you need to jump through some extra environment.rb configuration hoops.
Warbler needs to be told about any gems that your application uses. To generate a Warbler configuration file:
jruby -S warble config
The file is generated at
config/warble.rb. In it, modify the following sections:
config.gems = ["activerecord-jdbcmysql-adapter"]
config.webxml.jruby.min.runtimes = 2
config.webxml.jruby.max.runtimes = 4
Build and deploy the .war
jruby -S warble
asadmin deploy --contextroot / blog.war
--contextroot / makes the application rooted at
/ in the server, rather than at
/blog which would be the default.)
At this point, the blog application is up and running on port 8080. I had previously been running the blog with an Apache/.htaccess-based setup reverse-proxying to mongrel, so all I had to do was change the port. I haven’t touched it since.
But is this right for you?
Chances are, this setup is overkill for a simple blog. If you’re going to try it, I’d recommend at minimum running on a VPS with at least 1G of memory. But once you get the core pieces in place, updating and re-deploying the application is really just as simple as the last two commands. It’s mundane and boring in its simplicity. But boring is good when you don’t want to worry about having to keep Mongrel running, or max out the memory in your server and make it unstable.