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
Posted by Nick Sieger
Sat, 10 Jan 2009 20:04:00 GMT
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-gems 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-gems/bin, chronic-gems/cache, chronic-gems/gems, and chronic-gems/specifications directories and installed chronic and its dependencies into it. Now, simply package those directories into a jar file. WARNING: make sure you don’t give the jar file name the same basename as the library or gem inside you wish to use (e.g., chronic.jar), because JRuby will load chronic.jar when you require 'chronic'!
$ jar cf chronic-gems.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-gems.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-gems.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-gems.jar
$ java -jar jruby-complete-1.1.6.jar -rchronic-gems.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)
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!
Tags jruby, rubygems
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.
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
Tags jruby, rails, warbler | no comments
Posted by Nick Sieger
Fri, 19 Dec 2008 05:04:00 GMT
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!
Tags gruff, jmx, jruby, ruby, rubyadvent | 1 comment
Posted by Nick Sieger
Mon, 24 Nov 2008 18:51:00 GMT
Fabio Akita played the role of the Energizer Bunny, making a blur around the hallways at QCon. He managed to catch me on Thursday morning, and we had a great chat.
Go check out our conversation on Akita On Rails to hear my take on JRuby and Rails 2.2 and more. Thanks for doing the interview Fabio!
Tags akitaonrails, jruby, qcon, ruby | no comments
Posted by Nick Sieger
Sun, 19 Oct 2008 18:30:52 GMT
Project Kenai
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.
Tags jruby, kenai, rails | no comments
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.
Preconditions (Java)
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
cd glassfish
chmod -R +x lib/ant/bin
./lib/ant/bin/ant -f setup.xml
Start Glassfish.
./bin/asadmin start-domain
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 asadmin stop-domain).
Install JRuby
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 adapter: jdbcmysql:
<% jdbc = defined?(JRUBY_VERSION) ? 'jdbc' : '' %>
development:
adapter: <%= jdbc %>mysql
encoding: utf8
database: testapp_development
username: root
password:
socket: /tmp/mysql.sock
# same for test/production...
Otherwise, you need to jump through some extra environment.rb configuration hoops.
Configure Warbler
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.
Tags jruby, rack, rails, warbler | 5 comments
