JRuby and Sinatra in 2 Minutes

July 17th, 2010

While at RubyMidwest I decided to explore Sinatra in more detail. I’ve spent a lot of time with Rails, and while I love it, there is something alluring about the simplicity of Sinatra (and, well… ooh shiny). Being a recovering Java developer (Hi, I’m R.J., and I haven’t developed in Java for 18 hours) I have a server that runs Java, and would like to be able to use Sinatra to build my fancy-awesome web-apps. On those lines, I want all of the shiny benefits of JRuby’s multi-threading awesome-ness, as opposed to just trying to use WEBrick, which does not a powerful server make. So here is a 2 minute tutorial (well, depending on the performance of your computer, and how fast you type) startup with Sinatra, JRuby, Bundler, and Glassfish.

I’m cheating already by assuming you already have JRuby installed as your default Ruby installation. No? Go get it!

Next step is to get bundler:

1
gem install bundler

Now we need to make a home for our application, and prep it for Bundler:

1
2
3
mkdir testapp
cd testapp
edit Gemfile

Here I’m creating a new file in testapp called ‘Gemfile’ in your favorite editor. This is where we will sketch out our dependencies for Bundler to do all the hard work for us – here are the contents for this example:

1
2
3
source :rubygems
gem "sinatra"
gem "glassfish"

Frankly, that’s it. We tell Bundler to look for gems in RubyGems core repo, and then we ask it to make sure we have Sinatra and Glassfish. Now we can create the program – create the file ‘hello.rb’, and use these contents:

1
2
3
4
5
6
7
8
9
require "rubygems"
require "bundler"
Bundler.setup

require "sinatra"

get '/hi' do
    "Hello World!"
end

So what’s special for JRuby? Absolutely nothing. We do have special sauce for Bundler, (by calling Bundler.setup prior to the require for ‘sinatra’) but trust me – you’ll be happy you used it. You’ll also make @wycats happy.

And – that’s it! Now, if you were to start this file the standard (well, bundler-standard) way, we’ll see this:

1
2
3
4
5
realjenius$ bundle exec hello.rb
== Sinatra/1.0 has taken the stage on 4567 for development with backup from WEBrick
[2010-07-17 11:24:46] INFO  WEBrick 1.3.1
[2010-07-17 11:24:46] INFO  ruby 1.8.7 (2010-06-06) [java]
[2010-07-17 11:24:46] INFO  WEBrick::HTTPServer#start: pid=44490 port=4567

…and we can visit this URL: http://localhost:4567/hi. But, recall that our goal was to work with Glassfish, not WEBrick. All that has to change (and for folks who has done Glassfish/Rails before, this won’t be a surprise) is to run this startup instead

1
2
3
4
5
6
7
realjenius$ bundle exec glassfish
Log file /Users/realjenius/Projects/testapp/log/development.log does not exist. Creating a new one...
Starting GlassFish server at: 0.0.0.0:3000 in development environment...
Writing log messages to: /Users/realjenius/Projects/testapp/log/development.log.
Press Ctrl+C to stop.

Running sinatra

This time, we’ll visit this URL: http://localhost:3000/hi, and if all worked as desired, Sinatra will be crooning away. Boom goes the dynamite.

Upgraded to WordPress 3.0

June 24th, 2010

I just completed the upgrade to WordPress 3.0. So far, the upgrade appeared to go seamlessly. Everything is running, no plugins are complaining, yadayadayada. If you have a problem on the site please be sure to let me know.

If you are a WordPress user, and want to see what has changed since 2.9, here is a lovely screencast that covers the particulars:

Distilling JRuby: Frames and Backtraces

March 15th, 2010

Ruby Logo
Welcome back JRuby fans. I took a poll on twitter about what distilling article to do next, and frames and backtraces was the clear winner – so here we are! (three months later)

In previous “distilling” articles, I discussed how methods are dispatched, and then how the scope of variables in each method and block is managed. The scope and dispatch rules are only part of the big picture, however. Ruby, as a programming language, must gather rich information about the execution of the program, and must be able to share this with the developer when errors occur. Furthermore, Ruby itself provides a number of kernel-level methods for accessing and manipulating the current invocation stack (such as Kernel.caller).

This article is all about how JRuby implements those concepts.

Read the rest of this entry »

The Ides of March

March 13th, 2010

So Monday is my birthday: March 15th. For years I remember two things about the way adults reacted to me as a child: (1) Oh, your name is R.J.! That’s just like Dallas! (and for the record, no, no it is not). Or (2) Oh my! You were born on the Ides of March!

It’s funny, because when I was a kid, I had no idea what the ides of march was; I just knew it carried with it a certain degree of playful dread, given the reaction of adults. As I’ve gotten older, I’ve learned a lot more about what the day actually is, and not what people seem to attribute to it.

If you have no idea what I’m talking about, I’m not surprised. It seems like the superstition around the date has faded in recent years. Historically speaking, the term ‘ides’ meant the middle of the month for either Martius (March), Maius (May), Quintillis (July), or October on the Roman calendar. On the Ides of March, the Romans actively celebrated for Mars, the god of war (who, by the way, is awesome). Read the rest of this entry »

Check Out the Play Framework

March 1st, 2010

play
I’ve spent a lot of time recently investigating a variety of languages other than Java, such as JRuby and Scala, and truly believe from these experiences that traditional Java MVC web frameworks are inherently flawed in design and implementation. The effort involved in implementing on a framework like Struts or Spring MVC is astronomical, especially if you are going to implement things “the right way”.

It’s amazing to me how much these platforms push “hello, world” examples that are simply not realistic web applications. After trying these short examples, developers turn around and start trying to implement a complete application, and this simple example balloons into a mess of code, and that’s without any real functionality yet in the application. A co-worker of mine is a fan of saying “[These frameworks] make the simple things trivial, and the hard things impossible”.

Historically, I’ve been known to say “If you are doing web-development in Java, use Wicket“; this was based on the fact that to my experience Wicket took the most advantages from the strongly-typed, and strongly IDE-supported, Java language, as opposed to trying to hide them behind anemic and broken templating languages that have horrid editors and basically trade one problem for another.

Recently, however, I spent some time doing some significant development with the Play Framework. I have to say that I think the Play Framework has eclipsed my Wicket fever. That’s not to say that I don’t still think Wicket is very powerful, but I have been particularly impressed with the feedback loop provided by Play. It has, without a doubt, the most direct code-test-cycle I have seen in any platform for Java (it approaches the instant feedback of Rails), and also has the distinct advantage of being stateless out-of-the-box (something Wicket is definitely not).

Play manages this feedback loop problem in a rather novel way – embedded in the framework is the Eclipse compiler for Java (ECJ). This means that when you’re coding for the play framework, you’re not sending it your class files, but rather your source files. This allows Play to recompile code in a running instance on the fly – I literally only restarted my application a handful of times while I was coding over the course of several days. It also integrates seamlessly with IDEs, and ships with an embedded HTTP runtime (no deployment is necessary during development).

There are a number of other benefits Play can provide by working with source files instead of class files. Much like Rails ability to add functionality to your application at runtime, Play can (and does) pre-process certain Java classes to add functionality.

I was further heartened to see that the next release of Play is meant to fully support Scala, which would allow for other modern language features to be used with this highly interactive framework.

It’s hard to describe all of the neat features Play provides in a few hundred words, but I would highly recommend you check it out – they have a 10 minute screencast they sells it better than I can. While I’m still convinced Java (as a language) will be surpassed for an overwhelming majority of the web-development as the language continues to stagnate, this is a compelling framework for the Java platform as a whole, even if Java isn’t your language of choice.

JRuby “IO.foreach” Performance

November 3rd, 2009

Ruby LogoI’ve been spending some time dipping my toes in patch contribution for JRuby recently. I started with a few easy, isolated, spec issues, and have since been working my way into more entrenched problems. The past few weeks I spent a good bit of time toying with solutions to JRUBY-2810: “IO foreach performance is slower than MRI”. The exercise was interesting enough, that I thought it might be worth posting here. This isn’t meant to be a study of the JRuby code in particular, but more-so in the thought process of diagnosing a performance problem in foreign code. Read the rest of this entry »

Fistful of Awesome: IntelliJ Open-Sourced

October 15th, 2009

In a surprising move, the JetBrains team has decided to open-source the JavaSE portions of IntelliJ IDEA 9.0 and beyond under an Apache 2.0 license. They will begin offering two products, a community edition, and an ultimate edition:

Starting with the upcoming version 9.0, IntelliJ IDEA will be offered in two editions: Community Edition and Ultimate Edition. The Community Edition focuses on Java SE technologies, Groovy and Scala development. It’s free of charge and open-sourced under the Apache 2.0 license. The Ultimate edition with full Java EE technology stack remains our standard commercial offering. See the feature comparison matrix for the differences.

Very cool news! The impact in competition for other IDEs (namely Eclipse and NetBeans) remains to be seen, but this certainly brings another aggressive (and already well-liked competitor) to a broader market.

WordPress 2.9 Beta Testing Call to Arms

October 13th, 2009

wordpress-logo-stacked-bg

“For a limited time only – you can beta-test WordPress 2.9 from the comfort of your own installation!”

In the “another reason I like WordPress better for blogging” category, the folks over at WordPress.com have published a detailed article on how WordPress users can get involved in the beta-testing of WordPress 2.9 – the next major release. Included in the options for aspiring beta-testers is a plug-in that will automatically upgrade your site to the new version, and will keep you on the up-and-up. Read the rest of this entry »

What Am I Downloading Today, Eclipse?

October 8th, 2009

With the release of Eclipse 3.5, the plugin installation and update manager was completely revisited once again; the update process was reorganized, and the strengths of the p2 provisioning framework were surfaced. It’s nice to be able to hop in, download updates, and go.

However, I think Eclipse, as a product, still has a way to go. Read the rest of this entry »

Distilling JRuby: The JIT Compiler

October 6th, 2009

Ruby Logo
The JIT compiler in JRuby is a relatively new creation for JRuby. Of course, the initial approach taken for the JRuby platform was the most straightforward: parse and interpret the code incrementally as the program executes, traversing the AST. As time went on, the JRuby team have taken a bunch of steps to improve the performance of JRuby, most of which have involved shortcutting the consistent, but also slow and indirect interpreter model. The JIT compiler is probably one of the most aggressive and technically complex steps taken to date.

JIT compilers are a novel idea: take some code in an “intermediate form”, and, given some heuristics, compile it into a “more native” representation, with the expectation that the more native version will perform faster, and allow for more optimizations by the underlying platform. If some optimizations can be thrown into the more native form in the process, all the better.

Java, as an example, has had a JIT compiler for several years now. In fact, Java was, for many developers, the first time they heard the term JIT; so much so that many developers I know think the “J” in JIT stands for “Java”. In fact, JIT stands for Just-In-Time. Smalltalker’s may recognize the term “Dynamic Translation” instead.

Anyway, when the Java runtime determines code is eligible for native compilation (frequency of execution is one of the primary parameters), it diverts the execution of the code, so it can perform some fancy hoop-jumping to turn the Java bytecode into platform-specific native instructions, thereby removing any cost of bytecode interpretation, and also throwing some nifty optimizations into the compiled code. From that point forward, the native code will be used for execution, unless and until it has been invalidated by changing assumptions.

JRuby’s JIT compiler is similar in nature, the primary difference being the source and destination formats. In Java the source format is Java bytecode, and the destination format is native machine instructions. Conversely, in JRuby, the source format is the JRuby AST, and the destination format is Java bytecode. Perhaps the most fascinating aspect of the JRuby JIT compiler is that it benefits from both the initial compilation into Java bytecode, and then later, when Java may attempt to translate the JRuby-generated bytecode into native machine instructions. So effectively, it is possible to get a double-JIT on your executing code.

Generating Java bytecode from interpreted Ruby code is no small feat, however; so, without further ado, let’s start the tour of JRuby’s JIT!

Read the rest of this entry »