JRuby Core Team Members Enebo and Nutter Moving to Red Hat

Breaking news! At JRubyConf 2012 (a 3 day JRuby-focused conference in Minneapolis) it has just been announced that JRuby core team members Thomas Enebo and Charles Nutter are moving from Engine Yard to open source giants Red Hat.

The news was confirmed by Nutter in a tweet:

Engine Yard shares their side of the story and says they’ll continue to “work closely with Charles and Tom as well as Red Hat to continue development of JRuby and collaborate on JRuby features to support customers running on JRuby on Engine Yard Cloud.”

From the Red Hat perspective comes this post by JBoss director Mark Little. He notes:

They’ll [Enebo and Nutter] be working with various teams in JBoss and Red Hat, including the obvious candidates such as TorqueBox, Immutant and OpenJDK, but also helping us deliver on our polyglot visition. I can say that bringing them to Red Hat has been almost 2 years in the making, but it’s time that has been well worth spent and I have great expectations for their future here.

Mark Little

JRuby has had an interesting history, starting out as purely as a Java port of MRI by Jan Arne Petersen. It has matured significantly over the years, especially after the current core team leaders took over the reins in 2004. JRuby’s performance now trumps that of MRI 1.9 in many cases and JRuby is broadly considered as Ruby’s second-most established Ruby implementation (although Rubinius is approaching quickly from the rear in this regard.)

Red Hat has recently begun to make moves into the dynamic app hosting world with OpenShift, a Heroku-style auto-scaling ‘Platform as a Service’ (PaaS) for webapps. It includes Ruby support and along with the JRuby news shows a growing interest in the language at the popular open source company.

The JRuby team also announced the release of JRuby 1.7 preview 1 this week.

Free Course: An Introduction to JRuby

Introducing an online course for beginners that helps you get started with JRuby programming.

What’s JRuby?

Credit: JRuby

According to http://en.wikipedia.org/wiki/JRuby – “JRuby is a Java implementation of the Ruby programming language, being developed by the JRuby team. JRuby is tightly integrated with Java to allow the embedding of the interpreter into any Java application with full two-way access between the Java and the Ruby code.”

Charles Nutter says –

Despite all the new alternatives, JRuby on Rails remains one of the fastest, cleanest ways to build JVM-based web applications. JRuby provides the full Ruby ecosystem as well as integration with JVM languages and libraries. Ruby is both a wonderful language and increasingly the best choice for rapid application development. Add to that platforms like Torquebox and the excellent Ruby community, and it’s easy to see why JRuby should be in every Java developer’s toolbox.

What Will I Learn?

  • What is JRuby?
  • Why JRuby?
  • Killer app
  • What the experts say
  • Downloading and Setting-up JRuby
  • Getting your hands wet
    • JRuby allows Ruby programs to use Java classes
      • jruby01a.rb – JVM properties
      • jruby01.rb – DateFormat and Date
      • jruby02.rb – Internationalization / Localization
      • jruby03.rb – Swing library
      • Extending Java
      • Assignment 1
      • jruby04.rb – ActiveRecord and JDBC
    • JRuby allows Java programs to use Ruby classes
      • JRubyJSR223.java
      • JRubyJSR223Ex2.java
      • Assignment 2
  • Brief look at Ruby on Rails
  • Installation
  • Install Bundler and Rails
  • Creating your app – JRuby on Rails

Who’s It For?

A beginner but with a working knowledge of Ruby and Java.

This course will not teach you Java or Ruby programming. A basic knowledge of both programming languages is assumed, but most examples will be in Ruby and focus on Ruby development with help from Java. Also, you should have played around with some database. Whether you are a Java hacker who’s new to Ruby or a Rubyist taking your first steps into Java, this course is a great guide to help you navigate the gray area between the new languages.

By the time you have finished the course and worked on the examples and assignments, you will be fairly comfortable with JRuby.

Mentors

Satish Talim and others from the RubyLearning team.

Dates

The course starts on Saturday, 12th May 2012 and runs for a week.

How do I register?

Register here. Use the Enrollment key: rubylearning. That’s it!

Hurry, registrations have started.

At the end of this course you should have enough working knowledge to explore the wonderful world of JRuby, on your own.

Update

9th April 2012 at 7.45 hrs IST – List of Participant’s Countries

Online Graphing

Here are some details on how the course works:

Important:

Once the course starts, you can login and start with the lessons any day and time and post your queries in the forum under the relevant lessons. Someone shall always be there to answer them. Just to set the expectations correctly, there is no real-time ‘webcasting’.

Methodology:

  • The Mentors shall give you URL’s of pages and sometimes some extra notes; you need to read through. Read the pre-class reading material at a convenient time of your choice – the dates mentioned are just for your guideline. While reading, please make a note of all your doubts, queries, questions, clarifications, comments about the lesson and after you have completed all the pages, post these on the forum under the relevant lesson. There could be some questions that relate to something that has not been mentioned or discussed by the mentors thus far; you could post the same too. Please remember that with every post, do mention the operating system of your computer.
  • The mentor shall highlight the important points that you need to remember for that day’s session.
  • There could be exercises every day. Please do them.
  • Participate in the forum for asking and answering questions or starting discussions. Share knowledge, and exchange ideas among yourselves during the course period. Participants are strongly encouraged to post technical questions, interesting articles, tools, sample programs or anything that is relevant to the class / lesson. Please do not post a simple "Thank you" note or "Hello" message to the forum. Please be aware that these messages are considered noises by people subscribed to the forum.

Outline of Work Expectations:

  1. Most of the days, you will have exercises to solve. These are there to help you assimilate whatever you have learned till then.
  2. Some days may have some extra assignments / food for thought articles / programs
  3. Above all, do take part in the relevant forums. Past participants will confirm that they learned the best by active participation.

Some Commonly Asked Questions

  • Qs. Is there any specific time when I need to be online?
    Ans. No. You need not be online at a specific time of the day.
  • Qs. Is it important for me to take part in the course forums?
    Ans. YES. You must Participate in the forum(s) for asking and answering questions or starting discussions. Share knowledge, and exchange ideas among yourselves (participants) during the course period. Participants are strongly encouraged to post technical questions, interesting articles, tools, sample programs or anything that is relevant to the class / lesson. Past participants will confirm that they learned the best by active participation.
  • Qs. How much time do I need to spend online for a course, in a day?
    Ans. This will vary from person to person. All depends upon your comfort level and the amount of time you want to spend on a particular lesson or task.
  • Qs. Is there any specific set time for feedback (e.g., any mentor responds to me within 24 hours?)
    Ans. Normally somebody should answer your query / question within 24 hours.
  • Qs. What happens if nobody answers my questions / queries?
    Ans. Normally, that will not happen. In case you feel that your question / query is not answered, then please post the same in the thread – “Any UnAnswered Questions / Queries”.
  • Qs. What happens to the class (or forums) after a course is over? Can you keep it open for a few more days so that students can complete and discuss too?
    Ans. The course and its forum is open for a month after the last day of the course.

Remember, the idea is to have fun learning JRuby.

Technorati Tags: , , , , , ,


(Powered by LaunchBit)

Let’s Build a Simple Video Game with JRuby: A Tutorial

Ruby isn’t known for its game development chops despite having a handful of interesting libraries suited to it. Java, on the other hand, has a thriving and popular game development scene flooded with powerful libraries, tutorials and forums. Can we drag some of Java’s thunder kicking and screaming over to the world of Ruby? Yep! – thanks to JRuby. Let’s run through the steps to build a simple ‘bat and ball’ game now.

The Technologies We’ll Be Using

JRuby

If you’re part of the “meh, JRuby” brigade, suspend your disbelief for a minute. JRuby is easy to install, easy to use, and isn’t going to trample all over your system or suck up all your memory. It will be OK!

One of JRuby’s killer features is its ability to use Java libraries and generally dwell as a first class citizen on the JVM. JRuby lets us use performant Java powered game development libraries in a Rubyesque way, lean on Java-based tutorials, and basically have our cake and eat it too.

To install JRuby, I recommend RVM (Ruby Version Manager). I think the JRuby core team prefer you to use their own installer but rvm install jruby has always proven quick and effective for me. Once you get it installed, rvm use jruby and you’re done.

Slick and LWJGL

The Slick library is a thin layer of structural classes over the top of LWJGL (Lightweight Java Game Library), a mature and popular library that abstracts away most of the boring system level work.

Out of the box LWJGL gives us OpenGL for graphics, OpenAL for audio, controller inputs, and even OpenCL if we wanted to do heavy parallelism or throw work out to the GPU. Slick gives us constructs like game states, geometry, particle effects, and SVG integration, while allowing us to drop down to using LWJGL for anything we like.

Getting Started: Installing Slick and LWJGL

Rather than waste precious time on theory, let’s get down to the nitty gritty of getting a basic window and some graphics on screen:

  • First, create a folder in which to store your game and its associated files. From here I’ll assume it’s /mygame
  • Go to the Slick homepage and choose “Download Full Distribution” (direct link to .zip here).
  • Unzip the download and copy the lib folder into your /mygame as /mygame/lib – this folder includes both LWGWL and Slick.
  • In /mygame/lib, we need to unpack the natives-[your os].jar file and move its contents directly into /mygame.

    Mac OS X: Right click on the natives-mac.jar file and select to unarchive it (if you have a problem, grab the awesome free The Unarchiver from the App Store) then drag the files in /mygame/lib/native-mac/* directly into /mygame.

    Linux and Windows: Running jar -xf natives-linux.jar or jar -xf natives-win32.jar and copying the extracted files back to /mygame should do the trick.

  • Now your project folder should look a little like this:

    If so, we’re ready to code.

A Bare Bones Example

Leaping in with a bare bones example, create /mygame/verybasic.rb and include this code:

$:.push File.expand_path('../lib', __FILE__)

require 'java'
require 'lwjgl.jar'
require 'slick.jar'

java_import org.newdawn.slick.BasicGame
java_import org.newdawn.slick.GameContainer
java_import org.newdawn.slick.Graphics
java_import org.newdawn.slick.Input
java_import org.newdawn.slick.SlickException
java_import org.newdawn.slick.AppGameContainer

class Demo < BasicGame
  def render(container, graphics)
    graphics.draw_string('JRuby Demo (ESC to exit)', 8, container.height - 30)
  end

  # Due to how Java decides which method to call based on its
  # method prototype, it's good practice to fill out all necessary
  # methods even with empty definitions.
  def init(container)
  end

  def update(container, delta)
    # Grab input and exit if escape is pressed
    input = container.get_input
    container.exit if input.is_key_down(Input::KEY_ESCAPE)
  end
end

app = AppGameContainer.new(Demo.new('SlickDemo'))
app.set_display_mode(640, 480, false)
app.start

Ensure that ruby actually runs JRuby (using ruby -v) and then run it from the command line with ruby verybasic.rb. Assuming all goes well, you’ll see this:

If you don’t see something like the above, feel free to comment here, but your problems most likely orient around not having the right ‘native’ libraries in the current directory or from not running the game in its own directory in the first place (if you get probable missing dependency: no lwjgl in java.library.path – bingo).

Explanation of the demo code

  • $:.push File.expand_path('../lib', __FILE__) pushes the ‘lib’ folder onto the load path. (I’ve used push because my preferred << approach breaks WordPress ;-))
  • require 'java' enables a lot of JRuby’s Java integration functionality.
  • Note that we can use require to load the .jar files from the lib directory.
  • The java_import lines bring the named classes into play. It’s a little like include, but not quite.
  • We lean on Slick’s BasicGame class by subclassing it and adding our own functionality.
  • render is called frequently by the underlying game engine. All activities relevant to rendering the game window go here.
  • init is called when a game is started.
  • update is called frequently by the underlying game engine. Activities related to updating game data or processing input can go here.
  • The code at the end of the file creates a new AppGameContainer which in turn is given an instance of our game. We set the resolution to 640×480, ensure it’s not in full screen mode, and start the game.

Fleshing Out a Bat and Ball Game

The demo above is something but there are no graphics or a game mechanic, so it’s far from being a ‘video game.’ Let’s flesh it out to include some images and a simple pong-style bat and ball mechanic.

Note: I’m going to ignore most structural and object oriented concerns to flesh out this basic prototype. The aim is to get a game running and to understand how to use some of Slick and LWJGL’s features. We can do it again properly later 🙂

All of the assets and code files demonstrated here are also available in an archive if you get stuck. Doing it all by hand to start with will definitely help though.

A New Code File

Start a new game file called pong.rb and start off with this new bootstrap code (very much like the demo above but with some key tweaks):

$:.push File.expand_path('../lib', __FILE__)

require 'java'
require 'lwjgl.jar'
require 'slick.jar'

java_import org.newdawn.slick.BasicGame
java_import org.newdawn.slick.GameContainer
java_import org.newdawn.slick.Graphics
java_import org.newdawn.slick.Image
java_import org.newdawn.slick.Input
java_import org.newdawn.slick.SlickException
java_import org.newdawn.slick.AppGameContainer

class PongGame < BasicGame
  def render(container, graphics)
    graphics.draw_string('RubyPong (ESC to exit)', 8, container.height - 30)
  end

  def init(container)
  end

  def update(container, delta)
    input = container.get_input
    container.exit if input.is_key_down(Input::KEY_ESCAPE)
  end
end

app = AppGameContainer.new(PongGame.new('RubyPong'))
app.set_display_mode(640, 480, false)
app.start

Make sure it runs, then move on to fleshing it out.

A Background Image

It’d be nice for our game to have an elegant background. I’ve created one called bg.png which you can drag or copy and paste from here (so it becomes /mygame/bg.png):

Now we want to load the background image when the game starts and render it constantly.

To load the game at game start, update the init and render methods like so:

def render(container, graphics)
  @bg.draw(0, 0)
  graphics.draw_string('RubyPong (ESC to exit)', 8, container.height - 30)
end

def init(container)
  @bg = Image.new('bg.png')
end

The @bg instance variable picks up an image and then we issue its draw method to draw it on to the window every time the game engine demands that the game render itself. Run pong.rb and check it out.

Adding A Ball and Paddle

Adding a ball and paddle is similar to doing the background. So let’s give it a go:

def render(container, graphics)
  @bg.draw(0, 0)
  @ball.draw(@ball_x, @ball_y)
  @paddle.draw(@paddle_x, 400)
  graphics.draw_string('RubyPong (ESC to exit)', 8, container.height - 30)
end

def init(container)
  @bg = Image.new('bg.png')
  @ball = Image.new('ball.png')
  @paddle = Image.new('paddle.png')
  @paddle_x = 200
  @ball_x = 200
  @ball_y = 200
  @ball_angle = 45
end

The graphics for ball.png and paddle.png are here. Place them directly in /mygame.

We now have this:

Note: As I said previously, we’re ignoring good OO practices and structural concerns here but in the long run having separate classes for paddles and balls would be useful since we could encapsulate the position information and sprites all together. For now, we’ll ‘rough it’ for speed.

Making the Paddle Move

Making the paddle move is pretty easy. We already have an input handler in update dealing with the Escape key. Let’s extend it to allowing use of the arrow keys to update @paddle_x too:

def update(container, delta)
  input = container.get_input
  container.exit if input.is_key_down(Input::KEY_ESCAPE)

  if input.is_key_down(Input::KEY_LEFT) and @paddle_x > 0
    @paddle_x -= 0.3 * delta
  end

  if input.is_key_down(Input::KEY_RIGHT) and @paddle_x < container.width - @paddle.width
    @paddle_x += 0.3 * delta
  end
end

It’s crude but it works! (P.S. I’d normally use && instead of and but WordPress is being a bastard – I swear I’m switching one day.)

If the left arrow key is detected and the paddle isn’t off the left hand side of the screen, @paddle_x is reduced by 0.3 * delta and vice versa for the right arrow.

The reason for using delta is because we don’t know how often update is being called. delta contains the number of milliseconds since update was last called so we can use it to ‘weight’ the changes we make. In this case I want to limit the paddle to moving at 300 pixels per second and 0.3 * 1000 (1000ms = 1s) == 300.

Making the Ball Move

Making the ball move is similar to the paddle but we’ll be basing the @ball_x and @ball_y changes on @ball_angle using a little basic trigonometry.

If you stretch your mind back to high school, you might recall that we can use sines and cosines to work out the offset of a point at a certain angle within a unit circle. For example, our ball is currently moving at an angle of 45, so:

Math.sin(45 * Math::PI / 180)   # => 0.707106781186547
Math.cos(45 * Math::PI / 180)   # => 0.707106781186548

Note: The * Math::PI / 180 is to convert degrees into radians.

We can use these figures as deltas by which to move our ball based upon a chosen ball speed and the delta time variable that Slick gives us.

Add this code to the end of update:

@ball_x += 0.3 * delta * Math.cos(@ball_angle * Math::PI / 180)
@ball_y -= 0.3 * delta * Math.sin(@ball_angle * Math::PI / 180)

If you run the game now, the ball will move up and right at an angle of 45 degrees, though it will continue past the game edge and never return. We have more logic to do!

Note: We use -= with @ball_y because sines and cosines use regular cartesian coordinates where the y axis goes from bottom to top, not top to bottom as screen coordinates do.

Add some more code to update to deal with ball reflections:

if (@ball_x > container.width - @ball.width) || (@ball_y < 0) || (@ball_x < 0)
  @ball_angle = (@ball_angle + 90) % 360
end

This code is butt ugly and pretty naive (get ready for a nice OO design assignment later) but it’ll do the trick for now. Run the game again and you’ll notice the ball hop through a couple of bounces off of the walls and then off of the bottom of the screen.

Resetting the Game on Failure

When the ball flies off of the bottom of the screen, we want the game to restart. Let’s add this to update:

if @ball_y > container.height
  @paddle_x = 200
  @ball_x = 200
  @ball_y = 200
  @ball_angle = 45
end

It’s pretty naive again, but does the trick. Ideally, we would have a method specifically designed to reset the game environment, but our game is so simple that we’ll stick to the basics.

Paddle and Ball Action

We want our paddle to hit the ball! All we need to do is cram another check into update (poor method – promise to refactor it later!) to get things going:

if @ball_x >= @paddle_x and @ball_x < = (@paddle_x + @paddle.width) and @ball_y.round >= (400 - @ball.height)
  @ball_angle = (@ball_angle + 90) % 360
end

Note: WordPress has borked the less than operator in the code above. Eugh. Fix that by hand 😉

And bingo, we have it. Run the game and give it a go. We have a simple, but performant, video game running on JRuby.

If you’d prefer everything packaged up and ready to go, grab this archive file of my /mygame directory.

What Next?

Object orientation

As I’ve taken pains to note throughout this article, the techniques outlined above for maintaining the ball and paddle are naive – an almost C-esque approach.

Building separate classes to maintain the sprite, position, and the logic associated with them (such as bouncing) will clean up the update method significantly. I leave this as a task for you, dear reader!

Stateful Games

Games typically have multiple states, including menus, game play, levels, high score screens, and so forth. Slick includes a StateBasedGame class to help with this, although you could rig up your own on top of BasicGame if you really wanted to.

The Slick wiki has some great tutorials that go through various elements of the library, including a Tetris clone that uses game states. The tutorials are written in Java, naturally, but the API calls and method names are all directly transferrable (I’ll be writing an article about ‘reading’ Java code for porting to Ruby soon).

Packaging for Distribtion

One of the main reasons I chose JRuby over the Ruby alternatives was the ability to package up games easily in a .jar file for distribution. The Ludum Dare contest involves having other participants judge your game and since most participants are probably not running Ruby, I wanted it to be relatively easy for them to run my game.

Warbler is a handy tool that can produce .jar files from a Ruby app. I’ve only done basic experiments so far but will be writing up an article once I have it all nailed.

Ludum Dare

I was inspired to start looking into JRuby and Java game libraries by the Ludum Dare game development contest. They take place every few months and you get 48 hours to build your own game from scratch. I’m hoping to enter for the first time in just a couple of days and would love to see more Rubyists taking part.

How do I run a Sinatra app using JRuby?

How do I run a Sinatra app using JRuby?

RubyLearning is conducting a free, online JRuby 101 course – the first of its kind, on Google+ Some participants wanted an answer to their question “How do I run a Sinatra app using JRuby?” This blog post explains the same. Read on.

Pre-requisite

I have a Windows XP box but the following should work on Mac and Linux-based computers too.

Ensure that you have already installed JDK 6, JRuby and set the relevant system environment variables path, classpath, JAVA_HOME and JRUBY_HOME.

Install Bundler

Bundler helps prevent conflicting or missing gems and shines when it’s time to configure those dependencies at install time and runtime.

JRuby comes with a fairly loaded standard library from scratch but that does not mean there aren’t other things you’ll need. Almost all of them are installable as Gems. RubyGems is the premier package management tool for Ruby. It works fine with JRuby and JRuby ships with it. You use it through the gem command. We will need to run the JRuby version of the gem command and to ensure that, we use the -S flag to the interpreter.

Create a project folder (say c:\jrubysinatra) on your hard-disk. Ensure that your internet connection is active. Now, open a command window in this project folder and type:

jruby -S gem install bundler

Note: This approach (jruby -S) works for any Ruby command-line tool, including gem, rake, spec, and others.

Create a Gemfile

Next, in your project folder, create a Gemfile. It looks something like this:

source "http://rubygems.org"
gem 'sinatra'

This Gemfile says a few things. First, it says that bundler should look for gems declared in the Gemfile at http://rubygems.org. You can declare multiple Rubygems sources, and bundler will look for gems in the order you declared the sources. Next, you will have to list all your applications dependencies in there. Sinatra’s direct dependencies (Rack and Tilt) will, however, be automatically fetched and added by Bundler.

To make bundler install the dependencies, in the already open command window, type:

jruby -S bundle install

Because all the gems in your Gemfile have dependencies of their own (and some of those have their own dependencies), running jruby -S bundle install on the Gemfile above, will install quite a few gems. If any of the needed gems are already installed, Bundler will use them. After installing any needed gems to your system, bundler writes a snapshot of all the gems and versions that it installed to Gemfile.lock.

Write your Sinatra app

Create the file hellojruby.rb in the folder c:\jrubysinatra.

require "rubygems"
require "bundler/setup"

require "sinatra"

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

Set up your Sinatra application to use Bundler

For your Sinatra application, you will need to set up bundler before trying to require any gems. At the top of the first file that your application loads (for Sinatra, the file that calls require "sinatra"), put the following code:

require "rubygems"
require "bundler/setup"

This will automatically discover your Gemfile, and make all the gems in your Gemfile available to Ruby (in technical terms, it puts the gems “on the load path”). You can think of it as an adding some extra powers to require “rubygems”.

Now that your code is available to Ruby, you can require the gems that you need. For instance, you can require "sinatra".

Run your Sinatra application

In the already open command window, type:

jruby -S bundle exec jruby hellojruby.rb

In the command window, you will see:

== Sinatra/1.2.6 has taken the stage on 4567 for development with backup from WEBrick
[2011-09-03 07:21:17] INFO  WEBrick 1.3.1
[2011-09-03 07:21:17] INFO  ruby 1.8.7 (2011-08-23) [java]
[2011-09-03 07:21:17] INFO  WEBrick::HTTPServer#start: pid=5128 port=4567

Access the Sinatra application

In your browser, visit the URL: http://localhost:4567/hi – the browser shall display “Hello JRuby World!

That’s it for now.

Feel free to ask questions and give feedback in the comments section of this post. Fellow Rubyists, if you would like to write a guest blog post for RubyLearning email me at satish [at] rubylearning.org

Technorati Tags: , , , ,

JRuby 1.6 Released: Ruby 1.9.2 Support and More

It’s a newsflash! JRuby 1.6.0 has been released today. Congratulations to the JRuby team. 1.6 is a significant and much awaited release and comes after a 9 month push of over 2500 commits.

Hit up the official release post for the full run-through but here are some of the highlights of the release:

  • Windows has been added to the JRuby team’s continuous integration system meaning that Windows support is only going to get better
  • Ruby 1.9.2 language and API support (with the exception of Encoding::Converter and ripper)
  • Built in profiler
  • General performance improvements
  • Experimental support for C extensions (with provisos)
  • RSpec is no longer included (worth mentioning in case it catches you out..)

You can download binary and source releases direct from JRuby.org if you want to get up to date or update RVM with rvm get head and rvm reload before running rvm install jruby-1.6.0 🙂

Fingers crossed for some great JRuby tutorials and guides coming along in the next couple of months.

[me!] My Ruby Weekly e-mail newsletter is 7 months old and going great! For the best Ruby news of the week, check it out. However, you might also like JavaScript Weekly, a newer newsletter of mine dedicated to.. yep, JavaScript, node.js, CoffeeScript, etc. 😉

JRuby 1.6.0 RC1 Released: JRuby Gets All 1.9.2 On Us

jruby-new-logo.pngThe JRuby team has announced the release of JRuby 1.6.0 Release Candidate 1. The final release is still a little way off but the bulk of the work is in place. It’s billed as the “largest release of JRuby to date” which, given how awesome 1.5 was, is a big deal, especially as it adds initial Ruby 1.9.2 language and standard library compatibility (though 1.8.7 is still the “default”).

So, what’s new?

  • Ruby 1.9.2 language and API compatibility (use the –1.9 command line option to get it)
  • Ruby 1.9.2 stdlib included (even in jruby-complete.jar)
  • General performance and stability improvements
  • RubyGems 1.4.2 included
  • Experimental C extension support (!)

The JRuby team are especially keen for people to try out the new Ruby 1.9.2 support so that they can round out and perfect their 1.9.2 compatibility before the final release.

You can grab the 1.6.0.RC1 builds of JRuby from the JRuby download page. I haven’t had any luck with RVM yet but I suspect it’ll be supporting this release really soon..

[ad] The Red Dirt RubyConf is taking place in Oklahoma City on April 21-22, 2011! Speakers include Aaron “tenderlove” Patterson and Dr. Nic Williams. Mark your calendars!

JRuby Programming 2nd Batch: An Online Course For Beginners

Introducing an online course for beginners that helps you get started with JRuby programming.

What’s JRuby?

Credit: JRuby

According to http://en.wikipedia.org/wiki/JRuby – “JRuby is a Java implementation of the Ruby programming language, being developed by the JRuby team. JRuby is tightly integrated with Java to allow the embedding of the interpreter into any Java application with full two-way access between the Java and the Ruby code.”

Martin Fowler says –

For Ruby Developers, JRuby offers a deployment platform that is well understood, particular in corporations. For a Java community, JRuby is important because it offers a chance to experience a powerful language and framework while still taking advantage of Java’s excellent libraries and the ability to work in both Ruby and Java.

Tom Mornini, Founder and CTO, Engine Yard says –

JRuby is a great Ruby, developed by an amazing team, and that it’s extremely enterprise friendly.

What Will I Learn?

  • Learn to call various Java classes from Ruby.
  • Learn to call various Ruby classes from Java.
  • Bonus: Learn to create a simple app using JRuby and Ruby on Rails.

By the time you have finished the course and worked on the examples and assignments, you will be fairly comfortable with JRuby.

Who’s It For?

A beginner but with a working knowledge of Ruby and Java.

Mentors

Satish Talim and others from the RubyLearning team.

Dates

The course starts on Saturday, 12th Feb. 2011 and runs for a week.

Course Fees

The course fee is US$ 9.95 per participant. Only 20 15 participants.

How do I register?

  • You first need to register on the site.
  • The course is based on the Quick Guide to JRuby eBook and you need to buy the Quick Guide to JRuby eBook at an introductory price of US$ 9.95 (either by Paypal or send cash via Western Union Money Transfer or by bank transfer, if you are in India). The fees collected helps RubyLearning maintain the site, the JRuby course, the JRuby eBook, and provide quality content to you.
  • Send us the purchase details, your registered email id while creating an account at RubyLearning.org to satish [at] rubylearning [dot] com
  • We will enroll you into the course and intimate you so.

Hurry, registrations have started.

At the end of this course you should have enough working knowledge to explore the wonderful world of JRuby, on your own.

Update

Many of you wrote in asking for details on how the course works. Here are some of the details:

Important:

Once the course starts, you can login and start with the lessons any day and time and post your queries in the forum under the relevant lessons. Someone shall always be there to answer them. Just to set the expectations correctly, there is no real-time ‘webcasting’.

Methodology:

  • The Mentors shall give you URL’s of pages and sometimes some extra notes; you need to read through. Read the pre-class reading material at a convenient time of your choice – the dates mentioned are just for your guideline. While reading, please make a note of all your doubts, queries, questions, clarifications, comments about the lesson and after you have completed all the pages, post these on the forum under the relevant lesson. There could be some questions that relate to something that has not been mentioned or discussed by the mentors thus far; you could post the same too. Please remember that with every post, do mention the operating system of your computer.
  • The mentor shall highlight the important points that you need to remember for that day’s session.
  • There could be exercises every day. Please do them.
  • Participate in the forum for asking and answering questions or starting discussions. Share knowledge, and exchange ideas among yourselves during the course period. Participants are strongly encouraged to post technical questions, interesting articles, tools, sample programs or anything that is relevant to the class / lesson. Please do not post a simple "Thank you" note or "Hello" message to the forum. Please be aware that these messages are considered noises by people subscribed to the forum.

Outline of Work Expectations:

  1. Most of the days, you will have exercises to solve. These are there to help you assimilate whatever you have learned till then.
  2. Some days may have some extra assignments / food for thought articles / programs
  3. Above all, do take part in the relevant forums. Past participants will confirm that they learned the best by active participation.

Some Commonly Asked Questions

  • Qs. Is there any specific time when I need to be online?
    Ans. No. You need not be online at a specific time of the day.
  • Qs. Is it important for me to take part in the course forums?
    Ans. YES. You must Participate in the forum(s) for asking and answering questions or starting discussions. Share knowledge, and exchange ideas among yourselves (participants) during the course period. Participants are strongly encouraged to post technical questions, interesting articles, tools, sample programs or anything that is relevant to the class / lesson. Past participants will confirm that they learned the best by active participation.
  • Qs. How much time do I need to spend online for a course, in a day?
    Ans. This will vary from person to person. All depends upon your comfort level and the amount of time you want to spend on a particular lesson or task.
  • Qs. Is there any specific set time for feedback (e.g., any mentor responds to me within 24 hours?)
    Ans. Normally somebody should answer your query / question within 24 hours.
  • Qs. What happens if nobody answers my questions / queries?
    Ans. Normally, that will not happen. In case you feel that your question / query is not answered, then please post the same in the thread – “Any UnAnswered Questions / Queries”.
  • Qs. What happens to the class (or forums) after a course is over? Can you keep it open for a few more days so that students can complete and discuss too?
    Ans. The course and its forum is open for a month after the last day of the course.

Remember, the idea is to have fun learning JRuby.

Technorati Tags: , , , , ,

An Introduction to Desktop Apps with Ruby

An Introduction to Desktop Apps with Ruby

This guest post is contributed by Martin Sadler, who has over 10 years experience in the web development industry working with a range of successful high profile businesses, public sector organisations, and individuals. He is best known in the Ruby community as the creator of Working With Rails and is a keen advocate of the Ruby on Rails Framework.

Introduction

Martin Sadler In this article I’m going to show you how easy it is to create a nifty little cross-platform system tray/menu bar application using JRuby.

The application enables a user to take a screenshot of their desktop and then do something interesting with it!

"Screenshot Tray Application"

What’s covered in this article

Some of the key areas covered include:

  • Using Java Classes within Ruby
  • Refactoring
  • Blocks

Note: This tutorial assumes no prior Java knowledge and covers basic Ruby concepts only.

What is JRuby?

JRuby is a version of Ruby that runs on top of the JVM. It runs just the same as regular MRI Ruby except it’s about twice as fast and you get access to existing Java libraries.

Getting started with JRuby

It’s never been easier to try JRuby out. RVM is your friend here. Assuming you have RVM already installed it’s simply a case of doing the following inside your terminal session:

rvm install jruby

and then (where x.y.z is the version of JRuby)

rvm use jruby-x.y.z

From this point all your normal ruby commands will be using JRuby in the current terminal. Sweet.

Part 1: Taking a screenshot

Robot

Robot does for the Desktop what Selenium and other automation tools do for the browser. The main difference is that you have far more access to a users machine. You can move the mouse around, control keystrokes, manipulate other programs, and most usefully take a screenshot.

What is Robot? It’s a Java class and we going to make good use of it in our first script.

Our first JRuby script

example1.rb

#----------------------------------------------------------------
# Summary: Takes a screenshot of the desktop and saves to disk
#----------------------------------------------------------------

# this gives us direct access to Java classes in Ruby
include Java

# here we are importing Java classes, just like you might require 'yaml' or 'date'
import java.awt.Robot
import java.awt.Toolkit
import java.awt.Rectangle
import javax.imageio.ImageIO

# Taking the screenshot
# 1) Create a new instance of the Robot class
# 2) Use the Toolkit class to get the size of the screen
# 3) and pass those dimensions to the Robot instance for capture
robot     = Robot.new
toolkit   = Toolkit.get_default_toolkit
dim       = toolkit.get_screen_size
rectangle = Rectangle.new(0, 0, dim.get_width, dim.get_height)
image     = robot.create_screen_capture(rectangle)

# Save the file to disk
file = java::io::File.new('test.png')
ImageIO::write(image, "png", file)

Running the above script is a simple case of:

ruby example1.rb

The resulting screenshot gets saved to the same directory you are in as ‘test.png’. Result.

Tip: One question you might be asking by this point is how do you know what classes are available when you include Java? Java API docs have the answer.
Now, although helpful, it’s still pure Java so you’ll need to do a bit of translating to the equivalent JRuby calls. The tree view makes it easier to see how all the classes fit together.

So we’ve got a script to take a screenshot, it does the job, but we can make it better.

Refactoring into a re-usable Ruby Class

screenshot.rb

class Screenshot
  include Java

  import java.awt.Robot
  import java.awt.Toolkit
  import java.awt.Rectangle
  import javax.imageio.ImageIO

  def self.capture(filename = 'screenshot.png')
    robot     = Robot.new
    toolkit   = Toolkit.get_default_toolkit
    dim       = toolkit.get_screen_size
    rectangle = Rectangle.new(0, 0, dim.get_width, dim.get_height)
    image     = robot.create_screen_capture(rectangle)
    file  = java::io::File.new(filename)
    ImageIO::write(image, "png", file)
  end

end

now fire up a copy of irb and enter the following:

require 'screenshot'
Screenshot.capture('screenshot1.png')

By moving the code into a class method it’s much tidier and easier to use for the next part of the application.

Gotcha: File naming is really important here. The Ruby class defined in the file must be the CamelCase version of the filename for the require to work otherwise you’ll get errors like :
LoadError: use ‘java_import’ to load normal Java classes
Note, this is only the case in JRuby not regular MRI Ruby

Part 2: Creating the system tray application

Now we have a class for taking a screenshot lets create the system tray application:

example2.rb

#-----------------------------------------------------------------------------
# Summary: Runs a system tray application with ability to take a screenshot
#-----------------------------------------------------------------------------

require 'screenshot'

# Import the Java class libraries we wish to use
include Java
import java.awt.TrayIcon
import java.awt.Toolkit

# Setup our menu items
exititem        = java.awt.MenuItem.new("Exit")
screenshotitem  = java.awt.MenuItem.new("Take Screenshot...")
aboutitem       = java.awt.MenuItem.new("About")

# Event handling
exititem.add_action_listener {java.lang.System::exit(0)}
screenshotitem.add_action_listener {Screenshot.capture}

# Add the items to the popup menu itself
popup = java.awt.PopupMenu.new
popup.add(aboutitem)
popup.add(screenshotitem)
popup.add(exititem)

# Give the tray an icon and attach the popup menu to it
image    = java.awt.Toolkit::default_toolkit.get_image("screenshot.gif")
tray_icon = TrayIcon.new(image, "Screenshot!", popup)
tray_icon.image_auto_size = true

# Finally add the tray icon to the tray
tray = java.awt.SystemTray::system_tray
tray.add(tray_icon)

Before you run this script make sure you have an icon named screenshot.gif in the same directory. Short of creating one you can use Google to find an icon.

On running the application you’ll see the menu appear in your system tray. Click the screenshot menu item and the screenshot gets saved to disk!

"Screenshot Tray Application"

Refactor

The application is neat but it feels quite bulky, lets condense it down in to a much tighter API:

example3.rb

require 'tray_application'; require 'screenshot';
app = TrayApplication.new("Deskshot")
app.icon_filename = 'screenshot.png'
app.item('Take Screenshot')  {Screenshot.capture}
app.item('Exit')              {java.lang.System::exit(0)}
app.run

Not bad for an application of 6 lines! Where did all that code go?

tray_application.rb

class TrayApplication

  include Java
  import java.awt.TrayIcon
  import java.awt.Toolkit

  attr_accessor :icon_filename
  attr_accessor :menu_items

  def initialize(name = 'Tray Application')
    @menu_items = []
    @name       = name
  end

  def item(label, &block)
    item = java.awt.MenuItem.new(label)
    item.add_action_listener(block)
    @menu_items << item
  end

  def run
    popup = java.awt.PopupMenu.new
    @menu_items.each{|i| popup.add(i)}

    # Give the tray an icon and attach the popup menu to it
    image    = java.awt.Toolkit::default_toolkit.get_image(@icon_filename)
    tray_icon = TrayIcon.new(image, @name, popup)
    tray_icon.image_auto_size = true

    # Finally add the tray icon to the tray
    tray = java.awt.SystemTray::system_tray
    tray.add(tray_icon)
  end

end

A similar pattern of refactoring was carried out here as per the Screenshot class.

Probably the most interesting point is the way you can use Ruby to capture a block of code. In the case of the Screenshot application there are certain actions we only want to be executed when the user clicks a menu item. You can see these as code surrounded by curly braces. Alternatively they could have been written as follows:

app.item('Take Screenshot') do
  Screenshot.capture
end

Which does more or less the same job. Usually the do/end format is preferred for multi-line code blocks.

What is handy for us is that we can capture these code blocks using the &block parameter in the method definition. This makes the block available as a local variable inside the method and it can be simply pushed onto an array (@menu_items) for later recall.

Curious as to how a block is executed once stored? Here is a simple example:

def hello(&block)
  block.call # execute the contents of the hello block using call
end

hello do
  p "hello there"
end

Tip: Always try to keep your code tidy as you go along. Look for patterns and bake them into classes if need be. Think about how the end product will look like and work out how to get there. See also: Readme Driven Development.

Part 4: One further improvement

So now we have a tray application that takes a screenshot and saves to disk. How about we get it to open in an image browser too. No problem.

Lets make a small addition by making use of the Desktop Java Class.

screenshot.rb (revisited)

class Screenshot
  include Java

  import java.awt.Desktop # added Desktop to import
  import java.awt.Robot
  import java.awt.Toolkit
  import java.awt.Rectangle
  import javax.imageio.ImageIO

  def self.capture(filename = 'screenshot.png')
    robot     = Robot.new
    toolkit   = Toolkit.get_default_toolkit
    dim       = toolkit.get_screen_size
    rectangle = Rectangle.new(0, 0, dim.get_width, dim.get_height)
    image     = robot.create_screen_capture(rectangle)

    file  = java::io::File.new(filename)
    ImageIO::write(image, "png", file)

    # Open the file in the users default application for the given file type
    desktop = Desktop.get_desktop
    desktop.open(file)
   end
  end

end

So now when you click ‘Take Screenshot..’ up pops Preview (on Mac) with your Desktop image.

Beyond the screenshot

So we have put together the foundations of a screenshot tray application and in the process built a skeleton GUI JRuby framework. So where could we go from here?

  • Send the screenshot to a web service

    This would make for a handy utility for a support web app. Take the file and post it via http to your app for processing.

  • Add an About Box

    Sadly the amount of code to show this here would have detracted from the main article. However it is still pretty straight forward. JFrame is your friend.

  • HotKey for taking the screenshot

  • Package! Rawr. Distribute

    So currently you’ll need JRuby in order to run this application. One of the main benefits of JRuby is it compiles down to Java bytecode and will run on any Java enabled platform. Mac, Windows, and Unix support in one go!

  • Variations on the theme

    Why stop at screenshots? Here are few more ideas:

    • Drag and drop copy and upload of files to a web service
    • A notification service e.g. new support messages, tweets
    • System analytics tool
    • Copy and Paste share bin

Reference

Attribution

In Summary

I hope you found this article valuable and that it gives you an insight into the world of possibilities with JRuby and desktop applications. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Technorati Tags: , , , , ,

JRubyConf 2010

ELC is proudly sponsoring JRubyConf this year. This year, we’ve seen more and more cases of JRuby making its way into existing Java-centric enterprises and bootstrapped startups alike.  As the Ruby ecosystem keeps growing, new VM/Implementation support (JRuby, Rubinius, Reia, Etc), and tools like RVM, allow the flexibility of picking the right tool for the […]

How to Build a “Spy Camera” App for an Android Phone with Ruby and Sinatra

It’s been a great year for Ruby on Android, but no one knows it. You can start writing Ruby apps for Android devices TODAY. You don’t need to install any SDK, you don’t need to install some giant Eclipse IDE, and you certainly don’t need to write any Java.

Mike Leone

In Turn your Android Phone Into a Remote Spy Camera with Ruby in 15 Minutes, Mike Leone demonstrates how to use Ruby, Sinatra and Scripting Layer for Android (SL4A) to build and deploy a phone-hosted “spy camera” Web service.

SL4A is a system that allows you to run “scripting language” scripts and interactive interpreters on the Android platform. It currently supports JRuby, Python, Perl, Lua, JavaScript, BeanShell, and Tcl. Mike demonstrates how to set up a Sinatra project to use SL4A to run on an Android phone using JRuby. Upon receiving a request, Mike’s app takes a picture using the phone’s camera and serves it back over HTTP. He has also released the source code to a larger Ruby app called Broadcast that implements general Android device management functionality over HTTP.

Even if you don’t want to build a “spy camera”, Mike’s walkthrough is a must-read if building Web services in Ruby that can run directly on the Android platform is of interest to you.

June 4 2010: Okay, here’s a link post

Quick links post:

Gregory Brown is looking for comments and donations for a proposal for a Ruby Mendicant University, basically a rolling online Ruby course.

Charles Nutter is interviewed by InfoQ on the state of JRuby.

Yehuda Katz has a long post on various kinds of extensions in Rails 3 — gems, plugins, generators. This one I need to look at in some detail.

The new RubyMine 2.5 beta integrates with Pivotal Tracker. Looks like you can tell RubyMine what story you are working on and it will tag your source control comments. Cool.

Book Status

Working on the style/quality chapters, integrating material from the ChicagoRuby talk. Probably not a beta next week, but maybe the week after.

Filed under: JRuby, Rails 3, Ruby, RubyMine, Yehuda

June 1, 2010: June, she’ll change her tune

iPad Note

I keep wanting to write about the iPad, but so, so many other people are writing about it that I’m not sure I have anything to add. More or less at random, I really liked the brief rant Joe Posnanski added in the middle of an otherwise-unrelated blog post, and Charles Stross’ typically complete take. Right now, I just would add that I still use it more than I thought, that the form factor makes more of a difference than I expected (being able to easily walk to show the screen). Also, I’m somewhat idiosyncratically waiting for turn-based strategy games to pop up for it, along the line of Avalon Hill’s old games — the thing is perfect for them.

Today

One last reminder of today’s Chicago Ruby meeting featuring Matt Polito talking about Git, and me talking about testing.

And then

Looks like Kent Beck has gone and evolved the Agile Manifesto at the Startup Lessons Learned conference. This moves in the direction of what Beck has been calling Responsive Design.

Sarah Mei has a really nice example of outside-in BDD going back and forth between Cucumber and RSpec. Very nice overview of the process.

Ruby 1.9.2 preview 3 is out and available via RVM. Also over the weekend RSpec 2.0.0 beta 9.1 was released.

Charles Nutter has a long technical examination of performance in JRuby.

Filed under: Chicago Ruby, Cucumber, iPad, JRuby, Kent Beck, RSpec

May 13, 2010: The Rules of Agile Estimation

Top Story

JRuby 1.5 is out. Highlights include improved Rails 3 support, better support for Windows, better FFI support, better startup time (yay!) and a lot of other tweaks and fixes.

Book Update

Still Cucumbering, hope to finish today.

The book is still on sale, of course. And I’d still love to see more comments in the forum.

I’ll be talking at Chicago Ruby on June 1, exact topic TBD (let me know if you have a preference), but I’m leaning toward talking about how to avoid test problems and write good, robust tests.

And Then…

As an unrepentant old Newton fan, I loved this compare and contrast of a recent iPad ad with an old Newton ad. The Newton, flaws and all, was way ahead of the market back them.

If you are going to RailsConf, first of all have fun and wish I could be there. Second, if you are wondering about the difference between the two Rails 3 tutorials, wonder no more.

Kent Beck is publishing some old pieces again, including one about how the original XP book made the mistake of equating “the team” with “the developers”.

Fred and George Weasley are marketing experts.

And Finally

The Rules of Agile Estimation:

1. Estimates are always wrong

2. If you think spending more time on estimates is a good idea, see rule 1.

3. On average, an experienced developer is not going to improve on his or her gut reaction by thinking it over.

4. Team estimates are important, one person may see something that everybody else missed. Just keep it quick.

5. People are much better at estimating size relative to each other than absolute time a task takes.

6. Separate the problem into smaller chunks, the more estimates you make the better the chance that the law of averages will help you.

7. Decomposition into roughly equal sized tasks is pretty much the whole ballgame.

Filed under: Agile, Apple, Estimates, iPad, JRuby, Kent Beck, Newton, Potterverse, RailsConf

JRuby 1.5.0 Released: The Best Alternative Ruby Implementation Gets Even Better

Following on five months after the release of the popular JRuby 1.4, the JRuby team have delivered JRuby 1.5!

Forgetting the de facto “official” Ruby implementations of 1.8.x and 1.9.1/2, JRuby is the fastest and most stable Ruby implementation available and already has 9 years of progress under its belt. JRuby takes a lot of its performance and versatility from running on the Java Virtual Machine (JVM), which has provided JRuby’s developers with a solid base from which to optimize how Ruby is implemented.

JRuby 1.5.0’s release notes provide the full detail, but essentially the biggest new features are:

  • Native launcher for UNIX-based platforms
  • Ant support (effectively a Java based built tool, a la make)
  • Rails 3 related fixes
  • Updates to the standard library, RubyGems, and RSpec
  • ruby-debug is now included
  • Significantly improved Windows support (a breath of fresh air for Windows-based Ruby developers used to getting second best in the Ruby world)
  • Overall performance improvements

I don’t use JRuby in production myself, but everyone I know who does attests to its stability and performance. I’ve tried a handful of benchmarks on it informally, and it typically gives Ruby 1.9.1 a run for its money (though not always – and it’s worth noting that JRuby’s 1.9.x support is still new and optionally applied). It’s well worth a try as you might need to pull it out of your arsenal one day to meet the requirements on a “Java-only” enterprise project 😉

Installing JRuby

Picking up JRuby from its downloads page and getting it running isn’t difficult at all, as long as you have a JVM/JRE installed. It comes in both binary and source forms separately for UNIX-esque and Windows environments. Windows users get the bonus of a special “executable + JRE” download for simplified installation.

A far cooler way of installing JRuby, however, is to use RVM (Ruby Version Manager)! With RVM you can install multiple Ruby implementations on your machine without damaging the ones you already have. Creator Wayne E Seguin has already released a new version that supports and installs JRuby 1.5.0. With RVM 0.1.30, installing JRuby 1.5.0 is as easy as:

# rvm install jruby
.. wait a minute or two ..
# rvm use jruby
# ruby -v
=> jruby 1.5.0 (ruby 1.8.7 patchlevel 249) (2010-05-12 6769999) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_17) [x86_64-java]

May 10, 2010: The need for eyeballs

Top Story

Let’s start with this: there’s a small but embarrassing typo in the Pragazine article code. Especially since it was a) called out by the author of Mocha and b) was a direct copy from the book, and from the Lulu version before that, so it’s been public for about a year, and I’ve proofread that chapter at least five times. Which just goes to show… you never catch everything.

On the plus side, this guy likes the book!.

Book Status

Beta 2 will either be today or Friday. Hoping for today, we’ll see.

And then…

Very technical list of Charles Nutter’s favorite Hotspot JCVM command line flags. I guarantee that unless you are actually Charles Nutter, you will find stuff here that you don’t know. Especially recommended if you need to deep debug JRuby behavior.

RubyMine 2.5 has started its beta cycle. The headline feature is Rails 3 support. Normally JetBrains betas are pretty stable, but it’s still an early beta.

It has been days since Yehuda Katz has clarified some corner of the Bundler universe. Here’s an article about Bundler groups.

Matt Aimonetti has some thoughts on writing the MacRuby book with an open license.

Finally

Some quotes:

Pat Maddox in tweets:

Fundamental prob w/ relying on cucumber as primary test coverage is that it’s meant to capture & define the business’s expectations. But the first, implicit, expectation that the business has is that the software _works_. This means it’s *not* AT’s role to verify application works

Joe Posnanski, quoting baseball HOF pitcher Robin Roberts:

You want to be proud of your successes,” he told me, “but you want to be proud of your failures too.”

Dave Thomas, quoting Ryan King from Twitter:

The one -in-a-million case happens once every 80 seconds for us

Filed under: Bundler, errata, JRuby, MacRuby, Publishing, RubyMine, Twitter, Yehuda

May 6, 2010: The day of promoting stuff

Top Story

I’ll mention somebody else’s book, but don’t worry, I plan on doing it in a totally self-absorbed kind of way. Pragmatic released Using JRuby into beta yesterday, by the core JRuby team. Looks good, interested to see where they go with it.

Because I’m me, I can’t help but compare the structure of the book with the Jython book I did. Biggest structural difference so far is that we were unable to assume a Python-savvy audience, so we felt we had to awkwardly teach Python for 100 pages at the start of the book, where as the JRuby book is able to teach Ruby in an Appendix. Good luck to the JRuby team, and I’m looking forward to seeing this one all the way through.

Book Updates

In the spirit of an old Chevy Chase routine, Rails Test Prescriptions is still on sale. There’s a forum, which is still largely empty — I’d love some feedback.

Worked on the integration and webrat/capybara chapters, cleaning them up for beta 2.

The May, 2010 issue of the PragPub is out with my article about mocking, among other, cooler stuff.

And Then…

Today was a big day for updating software I use every day. If this blog post looks extra-shiny, it’s because I’m using MarsEdit 3, which I’ve used for every blog post I’ve written for several years. New stuff includes a rich text editor and better HTML syntax highlighting.

I also upgrated TextExpander and iStat Menus.

Matt Polito discovered that the Rails 3 API can be found at http://edgeapi.rubyonrails.org/. He did not know this. Neither did I. Neither did you, probably. Now we all know.

You probably do know about Rubular, which is an outstanding online tester for Ruby regular expressions. I just wanted to point out that it’s really cool.

If you aren’t using Dropbox, you should start right now — it’s an outstanding backup tool. (Man, I’m plugging a lot of commercial stuff today for some reason). Anyway, there’s now a Ruby library for the brand-new Dropbox API.

Also from Ruby Inside, a nice overview of three newish date-time libraries. Tickle, in particular, looks handy.

And in Yehuda news, a nice overview of Ruby 1.9 and character encodings, and in a completely different mode, a jQuery plugin for using HTML 5 offline data support.

Finally…

Randall Munroe at XKCD did a big survey asking people to name colors, and the results are really cool.

Will Leitch has a new book about baseball and dads, and this excerpt from Deadspin is all about the famous 2003 Chicago Cubs playoff loss. Since I’m a Cubs fan who loves reliving painful moments, I read it. Leitch gets the flavor of the game down correctly. As a Cubs fan, what I remember most strongly about when that ball dropped, was thinking “Oh, that’s how we’re going to blow this game” — the play was important mostly in getting across the idea that Weird Stuff was afoot.

Filed under: Cubbies, Dropbox, JRuby, Mac, MarsEdit, Pragmatic, Rails 3, Ruby, xkcd, Yehuda

April 13, 2010: iAd, youAd, weAll Ad

Top Story

iPads. Lots of them popping up in and around work. Probably some more coherent impressions coming later.

Wait, once again, Twitter has a big announcement after I start writing this. This time, they are going to start placing ads in the Twitter stream in various ways to be announced today. My quick reactions: a) I long suspected this day was coming, b) if the ads in clients are any guide, they aren’t particularly burdensome, c) implementation details will decide how irritating this is.

Book Status

Still working on Webrat and Capybara. Still waiting for a cover. Somewhat doubtful that the beta will happen this week, but I haven’t been told that for sure.

Tab Dump

Charles Nutter puts out an open call for help with the pure Java port of the Nokogiri XML parser for use with JRuby.

Confused by ==, equal?, and === in Ruby? You won’t be after this article.

Hey, it’s another big-time Agile founder: Ward Cunningham being interviewed. Pull quote: “When you’re doing it well it feels a little plodding, you’re not racing ahead like you might do on your own. But what happens is that it never slows down.” Can I get that on a T-Shirt?

Yehuda Katz is turning his attention to more Bundler documentation, with two articles that went up as I started typing this. The first one lays out the problems bundler tries to solve, and the second talks a bit more about problems specifying the order of require statements.

Filed under: Agile, Apple, Bundler, iPad, JRuby, Ruby, standup, Yehuda

In-depth JRuby Q&A: What Makes JRuby Tick in 2010?

jruby1JRuby is undoubtedly the most mature of the alternative Ruby implementations. Supporting Ruby 1.8.7 and 1.9.1 (mostly!) and JIT compilation, JRuby is already in use in mission critical Ruby apps and runs scarily fast on the JVM. In this interview with JRuby core member, Charles Nutter, we dig deep into what makes JRuby tick.

A great deal of conversation on IRC, as well as quite a number of lengthly emails, were eventually corralled into the following Q/A session between Charles Nutter and myself.

JRuby and Rails are the ideal solution for building new enterprise web applications. With JRuby’s ability to seamlessly integrate with anything Java, and Rails’ strong REST principles, these new applications will be 100% WOA compliant themselves, and also may trivially extend WOA compliance to the underlying Java systems. Rails makes it easy and inexpensive, and JRuby leverages the capacity, manageability and security of existing Java deployment farms.

— Tom Mornini (@tmornini)

The JRuby guys are doing the hard, bone-crunching work of exposing a high-quality Ruby implementation to millions of new developers. It’s not glamorous work, but the work they’ve been doing has already changed the landscape of Ruby, and there’s much more work still to come.

— Yehuda Katz (@wycats)

The JRuby / Charles Nutter Q&A

It’s frequently mentioned that the HotSpot JVM has 500+ man-years invested, and you’ve mentioned not only how infrequently you experience faults within the JVM, but at once how quickly they are addressed by the Hotspot team. How much of an advantage is it that you aren’t also responsible for maintaining the VM?

It is a tremendous advantage for anyone using an existing VM. Many folks don’t realize how much effort is required to build a new VM from scratch. You need a reliable optimizing compiler that not only makes code run fast, but does not change the execution results of users’ programs. You need memory management and garbage collection systems that limit pauses, keep memory usage within reasonable levels, and don’t become performance problems for systems under load. You need safe and reliable native interfaces that protect the integrity of VM internals. If you can achieve those items, you may want real concurrent threading that doesn’t cause the runtime to crash in unrecoverable ways. You may want tunable settings, like those added to REE to adjust garbage collection parameters. You will almost certainly want debugging and profiling interfaces that don’t drastically impact performance. You may want management interfaces that allow you to monitor and configure the system at runtime. You may want security guarantees, so users can safely sandbox code and be certain it will remain within operating parameters. And ideally, you want experts working on all these subsystems. That’s exactly what you get with the JVM.

And it goes even farther than that. There’s not just one JVM, there’s at least three in widespread use: Sun’s Hotspot, the VM behind OpenJDK; Oracle’s JRockit; and IBM’s J9. Each one has whole *teams* of developers working on those subsystems. And each company has competed for years to make their JVM better than the others. There are JVMs for every platform in use; we’ve gotten bug reports from users on exotic systems like Z/OS and OpenVMS. There are VMs that run on the smallest embedded devices and on the largest many-core systems you can imagine (see Azul’s JVM and hardware, running on hundreds of cores with hundreds of GB of memory). There have been JVMs on mobile phones for almost a decade. Every Blu-Ray player runs a JVM. There are JVMs literally everywhere.

It’s impossible to measure how much effort we’ve saved by building atop the JVM … but it’s a tremendous amount.

Garbage collection in MRI Ruby has been singled out as a significant performance issue. HotSpot has been said to have a sophisticated and excellent garbage collection strategy. How important is garbage collection for all Ruby implementations? How important is it for JRuby specifically?

Ruby is an extremely GC-intensive language. Much of the performance improvement in the upcoming Rails 3 comes from reducing object churn and therefore reducing the amount of GC necessary. Another example of this is the success of REE, in large part due to performance-improving patches to the MRI garbage collector. There are many such examples, and as a result, you simply can’t have a high-performance Ruby without a high-performance GC.

In JRuby’s case, we can leverage the years of effort that have gone into the JVM GCs. On Hotspot, the JVM we generally test against, you have not one but as many as 5 different garbage collectors to choose from. There are collectors that optimize straight-line allocation and GC performance (like Hotspot’s “throughput collector”). There are collectors that spread collection across cores to reduce pauses (the “parallel collector”). There are collectors that run nearly pauseless, running some collection phases concurrently with your application’s code (the “concurrent collector”). There are collectors that focus on aggressively localizing objects of similar ages so they can be collected in groups (the G1 “garbage first” collector). These collectors can often be mixed and matched depending on how your application behaves (or how you need it to behave). And they all can be almost infinitely tuned and monitored.

JRuby’s performance on numeric benchmarks serves as another example of how well JVMs manage memory…

One feature the JVM does not yet have is “fixnums”. Fixnums, in the VM world, are the ability to treat certain numeric values as though they were objects, without them actually being objects. Usually, this is achieved by dedicating a range of memory addresses as “tagged integers”, so that by masking off a few bits, you get the actual numeric value. This could, for example, reduce the cost of “boxing” integer values in java.lang.Integer objects to almost zero, allowing them to behave like objects but take up no memory on the heap and require no special attention from the garbage collector.

All the MRI-based implementations use “true fixnums”, as do several of the alternative implementations. JRuby does not, since the JVM does not support fixnums yet. As a result, we have to actually allocate a fixnum object for almost every math operation or for each iteration of a numeric loop. Those objects take up heap memory and eventually have to be collected.

We’ve always accepted that we’d eventually be surpassed on numeric performance, since fixnums have a much higher cost for us. But even though some of the newer fixnum-supporting implementations have better numeric performance than JRuby, we’re still able to come very close–even with all that fixnum object churn. Our numeric performance rarely impacts typical applications, and that’s a testament to the performance of the JVM’s memory subsystem.

(FWIW, there are several other JVM languages crying for “true fixnums”, and I’d be very surprised if we didn’t see an implementation within the next year.)

It’s a very different sensation to develop with JRuby with regards to start-up time. How are people minimizing this impact in production today, and what might be done to improves this micro-benchmark in the future?

Start-up time is one of those areas JVM engineers have unfortunately neglected until recently. JVM engineering has, for most of its lifetime, focused on the performance of long-running applications. Indeed, the best performance of JRuby (and other JVM languages) comes after not just slow startup but after a substantial warm-up period. This works great for server-side applications, but client-side use–whether for test-driven development, command-line tooling, or quick scripting–can sometimes be painful to deal with.

There’s also a culture clash here. Basically all JVM-based developers do their development inside an IDE, which often can run tests in the same JVM process from run to run. And JVM engineers have only recently started focusing efforts on startup performance (like the work Apple did with Java 1.5, which was built upon Hotspot).

But things are improving. JVMs that used to take ten or more seconds to start up may now take well under a second. That was unheard of 5 years ago. Additional work going into OpenJDK 7 and OpenJDK 6 updates promise to improve this further, and future research may even help reduce the warmup time required for maximum performance. Projects like JRuby have helped drive this work forward.

And we also understand the pain that slow startup can cause users. With each release we spend some time looking for ways to improve JRuby’s startup. Indeed, we even use slower JVM settings by default because we want the user experience to be better (specifically, we try to force Hotspot-based JVMs to use the faster-starting but less-optimized “client” VM, with switches to turn on the optimizing “server” VM). With JRuby 1.3, we started shipping support for “Nailgun”, a persistent background JVM you toss commands at (in order to reduce the spin-up and warm-up time for quick commands). There’s more work to do, but we feel users’ pain, and try to address it better with each release.

Macs ship with a JVM, it’s readily available for Linux distributions via packages, and a number of Windows machine vendors have it pre-installed nowadays. Despite that, a number of Rubyists somewhat disregard JRuby for having any relationship whatsoever to Java. Are they throwing the baby out with the bathwater?

They certainly are, but we also accept that JRuby isn’t for everyone. Maybe the startup time is a show-stopper. Maybe it’s JRuby’s less-than-perfect support for exact POSIX IO and subprocess behavior. Maybe it’s the lack of support for C extensions. There are certainly reasons why JRuby wouldn’t be the best choice for certain problem domains. But there’s also tremendous potential for JRuby to bring Ruby to problem domains, organizations, and platforms that it might never have been able to reach. JRuby opens up a huge world of opportunity for Rubyists and brings Ruby to the huge world of JVM-based developers. It’s such a beautiful match that I spent 20-30 hours per week on JRuby for almost a year before being hired by Sun … all in my spare time, because I was so excited about the possibilities.

What really depresses me is that many of the folks dismissing JRuby are exactly the folks who could help us make Ruby a better option for developers on the JVM. We need Rubyists skilled in building DSLs, skilled in designing libraries, skilled in integrating systems. We need day-to-day Rubyists to show Java developers how much better things could be for them. We need the amazing Ruby community to help us bring Ruby to a much larger world. There’s no time for platform bigotry … we all want the same thing: Ruby everywhere!

What can you tell the common Rubyist about application platform layers like the ones provided by Torquebox and Glassfish?

Both Torquebox (JBoss’s set of excellent Ruby wrappers around key server-side Java APIs and tools for deploying JRuby on Rails applications) and GlassFish (Sun Microsystem’s modular Java-based server, with lightweight “embedded” JRuby deployment support and a few similar API wrappers) are examples of how the best parts of the Java/JVM ecosystem can be repurposed (and improved) using a little Ruby knowhow. In both cases, you get simple, one-shot deployment (of multiple applications, I might add), along with well-designed service APIs and management tooling.

We would love to see the “Torquebox approach” or the “GlassFish way” applied to other popular Java APIs for persistence, networking, web services, and more. We’ll try to tackle some of the key libraries ourselves, but again we need help from the Ruby community. And in return we’ll promise to faithfully support Rubyists and to continue improving JRuby.

Github used JRuby to allow for code obfuscation and I’m assuming to best integrate with the kinds of customers who would pay for it. Do you see this type of decision making driving JRuby adoption as Ruby becomes more commonplace in the enterprise?

As long as there’s demand for Ruby, there will be demand for features unique to JRuby like easy deployment on Java services and compiled “obfuscation” like the Github folks needed. And these are only the beginning. JRuby can make it possible to write Ruby-based Android applications. JRuby can produce fully-compiled desktop applications in a single executable file that runs wherever there’s a standard JVM. JRuby can integrate easily with other JVM languages and access the vast world of JVM libraries. And it can do all this while still being true to Ruby.

All we have ever wanted is for JRuby to be a powerful, useful tool for JVM users and Ruby fans alike. And anyone who has talked to us knows we put the needs of our users first. Why not become a JRuby user today?

Gartner Inc. predicts that Android will make up 14% of the smartphone market in the year 2012, second only to the Symbian OS that powers some popular Nokia phones. What can you tell us about working with Android via JRuby?

It’s still early days for “Ruboto” (JRuby on Android), but there’s a lot of potential. I’ve been hearing from a few people every week interested in using Ruby as their Android language of choice, so the demand is certainly there. And with the Android 1.6 and 2.0 updates, JRuby appears to work fully on Android without any modifications.

For an early example of what’s possible, check out my ruboto-irb project on Github (link), which is basically an interactive Ruby session that runs directly on the device. You can do everything you would normally do with Ruby in IRB, plus construct and call Android core classes. It’s great fun, and with a bit more work I could see JRuby being ready for production use on Android.

Recently I’ve noticed some dialogue with regard to JRuby and Maven. I’ve seen references to Maven v3, and also to “Polyglot Maven.” Can you shed some light on the implications of this new interoperability for the everyday JRubyist?

There are two projects for JRuby and Maven integration.

The first is a prototype Maven server that looks and feels like a RubyGems source. By setting this server as a source (or passing it to the gem command), any Java library in the world is installable as a gem. Let me repeat that: ANY Java library in the world, installable as a gem. This means you can also use Maven artifacts as dependencies in regular Ruby gems, and it additionally means we won’t have to re-release jar files into their own duplicate gems on the standard repositories. It’s very exciting, and we hope to have it ready for JRuby 1.5.

The second project is part of the official “Polyglot Maven” work started by Jason van Zyl and the Sonatype folks. That project intends to provide standard DSLs for popular JVM languages, allowing you to use those languages in place of the XML-based POM files so many people hate. In addition, those DSLs would have access to Maven’s workflow and data model classes, providing fully-scriptable Maven builds without a lot of the noise of a typical Maven project. This work is still in early days for JRuby; I’ve only committed a couple prototype scripts to the repository. We would love to have help here, since we’re not really Maven experts.

Generic Q/A

There are ~150 native extension gems for Ruby, some of which are prolific and often depended upon by other gems. Does your Ruby implementation support FFI (foreign function interface) at present, and/or how much of a priority is running native extension gems going forward?

I believe that native extensions are the #1 thing holding the standard Ruby implementation (MRI) back. If you look at archives of the Ruby mailing lists going back for years, maintaining extension compatibility has always come at the expense of improving MRI. You want a better GC that’s generational and compacting? Sorry, that wouldn’t be compatible with current extensions without a big performance hit. How about real concurrent threads? Nope, without adding fine-grained locks or safepoints around all extension calls, you’re sure to segfault somewhere.

JRuby does support FFI, and has for well over a year now. In fact, Wayne Meissner of the JRuby team is largely responsible for FFI being a viable alternative to C extensions, since he implemented the FFI gem for MRI and has been working closely with the FFI community ever since. We believe FFI, or mechanisms like it, are the best way to call C libraries from Ruby, regardless of the implementation, and we encourage people to use FFI if there’s a native library they simply must use.

As far as real native extension support… anything’s possible, but we have no plans to support MRI’s C API in JRuby. The API is unfortunately very invasive, giving direct memory access to object internals in many places. In order to support this on JRuby, we would need to copy lots of data back and forth on every call, not to mention locking down extension calls per-thread completely to ensure they weren’t stepping on each others’ data. It might be possible to get a limited subset of the MRI extension API implemented for JRuby, but existing extensions would require some rework and performance would probably end up worse than FFI due to the amount of copying and locking required.

In general, the only 100% answer for JRuby is to port extensions to a JVM language or wrap existing JVM libraries (and there are literally tens of thousands of libraries available). FFI provides a good stopgap or bandaid for the problem, but it still requires us to load a native library which many deployment environments will disallow. Only pure-“Java” libraries (where by “Java” I mean “some JVM language”) will have the best possible chance of running on all target systems.

Passing RubySpec tests is fundamentally important. Has this compliance lowered the theoretical performance ceiling of your implementation considerably?

Ruby is a difficult language to implement. JRuby is arguably the only production-quality alternative Ruby, and that quality has come after literally dozens of man-years of work. We’ve also managed to achieve production-level compatibility while turning JRuby into one of the best-performing implementations, so we have a solid understanding of the challenges involved.

There’s no doubt about it: Ruby has lots of features that make optimization really hard. Being able to use a block as the binding to an “eval” call forces us to keep all of the block’s surrounding state, even if the block itself doesn’t need it. Backref and lastline references ($~ and $_ variables) require a called method to be able to modify the caller’s context, even if the method itself never accesses those values. The ability to replace methods on core classes – even super-important ones like Fixnum#+ – means we have to always check for those modifications. Even simple things like “eval” and “send” force us to deoptimize more code than we’d like.

We have managed to work around many of these challenges, just like some of the other Ruby implementations, but many of them remain. In almost every case, we’ve tried first to get solid compatibility, optimizing later as much as we can. We plan to revisit those performance challenges in the future, learning from other dynamic language runtimes and other Ruby implementations about new ways to optimized. But right now we’re pretty happy with JRuby’s performance, which puts us at least on par with Ruby 1.9 for almost everything (and faster for many things).

Closures, continuations, and tail-call optimizations are often discussed in terms of programming language VM’s. Which of these attributes are implementable at present, which are expected to be implemented, and which are not possible by design?

Closures are probably the easiest one. If you can save some local context and pass it around with a function reference, you’ve got closures. There’s plenty of details, like making non-local flow control work (break or return inside a block), but in general they’re not difficult to support.

Continuations and tail-calls unfortunately both require VM-level support to do well.

JRuby does not support Ruby’s continuations because the JVM does not (yet) support continuations. In order for us to implement continuations atop the JVM, we would have to forgo standard Java method dispatch for all of JRuby, since any calls that would deepen the stack would make saving a continuation impossible. The performance impact of this would be tremendous: the JVM gets its performance because it’s able to optimize normal chains of calls; by trampolining in and out of methods at the same stack depth, practically none of the standard optimizations would fire. We actually did try a “stackless” implementation in 2005, and I demoed it at RubyConf that year. It could calculate a recursive fib(1_000_000), but it ran so incredibly slow (orders of magnitude slower than what we have right now) that it simply wasn’t feasible.

For tail calls, VM support is necessary to do a 100% job, but you *can* fake some recursive tail-call optimization by branching back to the top of a method body. We have not implemented any “tricky” tail-call optimization yet, but it’s a possibility for future versions of JRuby.

And in both cases, there’s some interesting work on the horizon. Both tail calls (“true” tail calls) and continuations are being developed against the Multi-Language VM subproject of OpenJDK, and both actually have working patches right now. There’s a good chance that a future version of the JVM will have support for true tail calls, and a slim chance that delimited continuations (coroutines) might arrive as well. That’s part of the beauty of JRuby: there’s dozens or hundreds of JVM engineers out there working to make it faster, working to add features, and competing with each other. JRuby users directly benefit from all that work.

How integral is dynamic feedback-based optimization to reaching a high level of performance? Do you feel it will be possible to maintain acceptable speed into the future without embracing these strategies or are there less well-known alternatives which are potentially more effective?

Because we run on the JVM, we already benefit from a tremendous amount of runtime optimization. JRuby’s core classes (Hash, Array, etc) are perhaps the fastest implementations of any Ruby, largely because they’re all written in Java and benefit from the very best JVM optimizations available. At the end of the day, the vast amount of Ruby execution is in the core class implementations, so they really need to be as fast as possible, and Java is our “C” for doing that.

We also benefit from feedback-based optimization when running Ruby code, though we still have a lot of opportunity here. Currently, JRuby’s Ruby compiler is fairly “dumb”: it doesn’t use runtime profiling *at all* and only does a few limited static optimizations. Now of course the JVM is able to pick up a lot of slack, using its own runtime profiling to make our “dumb” generated code run really well. But because we recognize that we need to help the JVM out a bit more, we do have plans to introduce more runtime feedback into our Just-In-Time compiler subsystem. Expect to see more work on JRuby performance in 2010.

There’s also a Java 7 feature we’ve started to play with: fast dynamic invocation. JSR-292, the “invokedynamic” JSR, is adding a new bytecode called “invokedynamic” to the JVM. The invokedynamic bytecode allows us to wire up (for example) Ruby method invocation directly into the JVM’s call protocols. As a result, the JVM can do all its usual inlining and optimization even across Ruby calls. Early results have been promising… even without a lot of optimization, the current invokedynamic implementation is 20-30% faster than our old call protocols. We’ve been working closely with Hotspot engineers throughout their development, and we’re really looking forward to seeing how well JRuby runs on invokedynamic in the coming months.

Which of 1.8.7 and 1.9.x is your implementation compatible with?

JRuby 1.4 made the move to Ruby 1.8.7 compatibility, because we felt that 1.8.7 has become established enough (and because we were tired of getting bug reports about 1.8.7 features being missing). We also have done a lot of work on supporting Ruby 1.9, though that’s still a bit of a moving target. We’re hoping that in the first half of 2010 we’ll be able to reach feature-parity with the upcoming Ruby 1.9.2. We’ll definitely need help from the community.

Do you think further acceptance of Ruby is driven equally by spending man-hours working on performance and by meeting an international body’s specification?

I think performance is somewhat of a red herring, and as I mentioned before it can be a tremendous resource sink. We will, just like the other implementations, continue incrementally improving performance. But given JRuby’s unique features, our current level of performance is good enough for us to focus on other areas for a while. We won’t ignore performance, and we don’t want to fall behind in the endless performance wars, but we have to balance features, compatibility, and stability at the same time.

As far as specification goes… I think it’s only useful for entities that require specifications. If it’s true that many organizations worldwide will refuse to adopt Ruby due to a lack of a specification, then time spent preparing such a specification is probably worthwhile. Since there’s already such an effort, I sincerely hope it will help increase Ruby adoption.

What are your team’s goals for the next quarter, the next year?

The number one goal for me is Java integration. Java integration means many things:

  • ability to generate *real* Java classes for Ruby classes, both at runtime and ahead-of-time
  • fast-as-possible Ruby-to-Java invocation
  • ecosystem integration, like our recent work to make all Maven artifacts in the world transparently installable as gems
  • platform integration, like making Rails work naturally as a Java-land web framework, and making Java-land frameworks like Hibernate fit naturally into Rails

I also want to return to performance work, most likely by continuing the work that Subbu Sastry has already begun on JRuby’s new optimizing compiler. The potential here is to do a large amount of optimization before feeding bytecode to the JVM, allowing us to approach the performance of statically-typed languages over the same code. We want to make Ruby run as well as possible on the JVM, and I think the new compiler work will be a big part of that.

Besides any obvious platform niche, why might someone benefit from electing to use your Ruby Implementation?

Well, we’ve got several years of production users under our belt! The value of having real users for several years can’t be understated, and we learned very quickly that getting a 1.0 release out is just the beginning.

JRuby Installation

If you’ve still not given JRuby a proper try, you can learn more at the official JRuby site or if you’re using the RVM (Ruby Version Manager) you can be up and running on the latest main build (1.4.0) with:

rvm install jruby

Recent Confreaks Presentations

You can watch the full keynote “JRuby State of the Union” by Charles Nutter and Tom Enebo here at Confreaks’ site or you can go directly to the video (MPEG 4) file here.

Conclusion

During their respective funding periods, Sun and Engine Yard have both had a strong commitment to JRuby. For Ruby to thrive, it ultimately needs to be deployed in numbers that achieve a lasting critical mass. There is a reportedly massive amount of existing infrastructure based on the JVM, which makes JRuby a noteworthy stepping stone to many interesting destinations, and based on what we’ve discussed here, why would anyone obstinately ignore JRuby any longer?

Do YOU want to learn JRuby using Google Wave?

RL offers online courses in Ruby programming, Ruby Metaprogramming, Git & GitHub, FXRuby, Shoes, JRuby, Sinatra and Merb. Since 2005, over 15,000 participants spread across 140+ countries have learned Ruby and other Ruby related timely topics. This has been possible due to the extensive support provided by the mentors of these courses. RL strives hard to improve the methodology and course content based on the extensive and critical feedback we receive. Thanks to YOU, the Ruby community, people like Fabio Akita and companies like Locaweb who make this possible. Our Alumni are our best ambassadors.

But What is Google Wave?

Google Wave1 is a new web-based collaboration tool that enables groups of people to edit and discuss documents simultaneously on the web. At first, Wave can feel overwhelming, especially if you’re trying to understand it as a type of tool you already know—such as email, a document collaboration tool, or instant messenger. Wave combines features from all three of those types of tools.

To really understand Google Wave, I would recommend Gina Trapani’s excellent online tutorial “The Complete Guide to Google Wave“.

Advantages of using Google Wave

A tool such as Google Wave enables the students to collaborate together in an online environment. Wave replaces the need for multiple services such as a Wiki to post work, Google Docs to collaborate on documents, email to communicate asynchronously, and instant messaging services to communicate synchronously. From personal experience with using technology with students I have learned that the simplest solution is the best. Using one tool instead of four is a great advancement.

Thus, you could have one master notebook, where you could verify all the information, highlight what will probably be the most important things to learn, and just improve the process of studying completely.

Another feature of Wave that would be useful for education purposes, is the play-back ability – “so instructors can see exactly who did what, and see the progression of ideas.”

What’s JRuby?

JRuby is a 100% pure-Java implementation of the Ruby programming language.

Recently, JRuby has been gaining more and more attention in the Java and Ruby communities. Java is a powerful platform and there are millions of lines of Java code being written each month, that the world will have to live with for a long time from now. By leveraging Java the platform with the power of the Ruby programming language, programmers will get the best from both worlds. You better not ignore JRuby any more!

This is what some experts have to say about JRuby.

Martin Fowler:

For Ruby Developers, JRuby offers a deployment platform that is well understood, particular in corporations. For a Java community, JRuby is important because it offers a chance to experience a powerful language and framework while still taking advantage of Java’s excellent libraries and the ability to work in both Ruby and Java.

Pat Eyler:

Pretty soon, JRuby will be our common gateway between the infrastructure world of quick Ruby scripting and the application world of large-scale Java apps.

Why Use Google Wave To Teach JRuby?

At RubyLearning.org, we have been teaching the Ruby programming language and related libraries, api’s and frameworks for the past three years, using traditional tools. With the advent of Google Wave, we wanted to try and understand ourselves the effectiveness of using Google Wave as a teaching tool.

Who’s It For?

  • You need to know the basics of Java and Ruby programming languages.
  • You need to have a Google Wave account to access the invite-only “RubyLearning JRuby Wave“.
  • You should be able to use Google Wave effectively. If you are not comfortable with Google Wave, read the excellent free, online tutorial “The Complete Guide to Google Wave“.

What Will I Learn?

This is an introductory course on JRuby, wherein you will:

  • learn to call Java classes from Ruby, and
  • learn to call Ruby classes from Java.

On completion of this course you will be comfortable programming in JRuby.

When And Where Do I Start?

Impatient? Well before we start off with this course, I would appreciate your feedback (as comments to this blog post). Feedback could be on:

  • Appropriateness of using Google Wave as a learning tool.
  • Suggestions for the format of the course.
  • How you could contribute to this learning experience.
  • Any other suggestions.

When you make a comment, please leave your Google Wave address, so that I can invite you once the “RubyLearning JRuby Wave” is ready. If the response is encouraging, I shall make this a public wave.

Update (11th Nov.): The JRuby course has started and so far 90 participants have registered. You can join the course anytime you want. Just post your Google Wave address as a comment to this blog post.

Technorati Tags: , , , ,

  1. Google Wave is a trademark of Google, Inc.

Announcing grizzly-sendfile!

It’s my pleasure to finally announce grizzly-sendfile v0.2 – the first stable version of a project that I started after I got one of those “Sudden Burst of Ideas” last summer.

For people who follow the grizzly development or mediacast.sun.com, this is not exactly hot news. grizzly-sendfile has been used by mediacast since last September and mentioned on the grizzly mailing list several times since then, but I haven’t had time to promote it and explain what it does and how it works, so here I go.

If you don’t care about my diary notes, skip down to “What is grizzly-sendfile”.

A bit of background: the whole story goes back to the end of 2007 when a bunch of us where finishing up the rewrite of mediacast.sun.com in JRuby on Rails. At that time we realized that one of the most painful parts of

Continue reading “Announcing grizzly-sendfile!”