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
Tue, 10 Feb 2009 21:38:35 GMT
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!
Tags rubyfringe | 2 comments
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 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!
Tags jruby, rubygems | 4 comments
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
Wed, 10 Dec 2008 14:50:44 GMT
Here’s a nice surprise. My mini-keynote at RailsConf Europe was posted over at blip.tv. It’s only 10 minutes, so give it a watch and let me know what you think. I even watched it myself, without cringing! I laughed (at how I actually sounded credible), I cried (at how I laughed at my own poorly-delivered joke).
Tags railsconf, railsconfeurope | 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, 23 Nov 2008 08:51:03 GMT
This year’s QCon San Francisco conference was my first time attending, and it was an eye-opener for me for several reasons.
First, the tutorial Ola and I gave on Monday went well, though I was mildly surprised to find that only about 10% of the attendees at our talk had any familiarity with Ruby. This turned out to work just fine as we were able to adjust and fill in a little bit of the back story on both Ruby and Rails. Still, to try to convey a sense of Ruby, Rails, and JRuby all in the span of a 2.5 hour session is a tall order!
Next, I was impressed with the diversity the conference organizers were able to achieve. There were tracks on agile development, cloud computing, REST, DSLs, design and clean code, Ruby, functional programming, real-world architectures, storage rethinking, and more. Tracks were relevant and topical even if the quality of talks was mixed.
The last item relates to my perception that Ruby is not yet seen as a worthwhile tool for enterprise software
development. It leaves me with some cause for concern, though it reflects more on the state of the industry
rather than on the way Ruby was presented at the conference itself.
What does it mean for Ruby to be “ready for the enterprise”? Does that imply JRuby? Running on the JVM or a Java application server, or even .NET? Reams of XML? Presence of buzzwords, such as JMS, Spring/Hibernate? Or ability to adapt to or leverage legacy code? All of these?
I would argue that Ruby already has everything it needs to be a successful enterprise software development platform, even without using JRuby. Ruby has a mature standard library, a large and ever-growing list of gems and extensions, and a vibrant community. Testing tooling, certainly seen more and more as a critical piece of software development, is also an area where Ruby excels (and brings a strong culture bias toward testing as well). Add JRuby to the mix and the ability to leverage existing infrastructure as well as code, and the picture gets even stronger. Best of all, Ruby the language is a malleable medium perfectly suited for gluing enterprise components together, creating DSLs on top of stable layers and remaining clean enough to be eminently readable and maintainable. Yet behind-the-firewall deployments appear to be elusive; if they do exist, they’re small, isolated apps that work so well, the community doesn’t hear about them. Judging from the low level of participation in Ruby-related talks at QCon, I’m inclined to believe the former.
I was speaking with Jay Fields about this topic on Friday. Jay also noticed that the the Ruby and DSL tracks were sparsely attended. (For that matter, so was the functional programming track.) His observation was that the track content was not marketed and tailored enough toward toward solving enterprise-class problems, or being approachable enough in that regard. We can certainly do better.
Do we have an issue here? Are we, the Ruby community, being too insular and not concerning ourselves enough with bringing Ruby-based solutions to the enterprise? Or perhaps businesses are waiting for more organizations that can provide services, support and indemnification? Does there need to be a Ruby, Inc. (or even a JRuby, Inc.) that looks at common enterprise problems and devises best-of-breed solutions (a sort of SpringSource for Ruby) for things like enterprise integration, security and identity, reporting, business workflow, decision support, etc. ad infinitum? Ruby should be able to do all of those while bringing the increased agility and productivity that we’ve all experienced.
I seem to have raised more questions than I am able to answer at this time. Of course, the obvious answer is that adoption of Ruby will just need more time, but I’m not willing to accept that as the only reason. I’d love to hear your opinions on contributing factors and what can be done to mitigate them. It seems like there’s a huge opportunity waiting to be tapped to help make Ruby more enterprise-worthy.
And yet, despite the less-than-stellar turnout for Ruby at QCon among conference attendees, I still had a great week, and would go back again. QCon is a fun and well-organized event overall, and I got the impression that the folks present were on the leading edge of “the enterprise”, which is exactly the people we need to engage to bring about growth in adoption of Ruby. For that reason, I hope we can kick it up a notch and take another shot at pimping Ruby at the next one. Maybe I’ll see you there!
Tags qcon, ruby | 12 comments
Posted by Nick Sieger
Sun, 23 Nov 2008 07:10:41 GMT
I finally did it. I ditched the old, crufty Typo theme in favor of one hand-crafted by yours truly. I’m by no means a professional web designer, but I’m happy with what I ended up creating. It’s relatively clean, the colors are a little edgy, and it took less that forever thanks to blueprint and kuler. Let me know if you have any feedback!
2 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
