Introducing JRonA

In keeping with the theme of simplicity I have discovered that it's possible to run JRuby on an Android device with a very small amount of Java code. JRonA is all contained in two files JRonA.java with 51 lines of code and JRonA.rb with 24 lines of code. Even I can understand it!

I have called my creation JRonA (short for JRuby on Android) and if you are interested you can download the explanatory JRonA-01.PDF here or the code and examples here.

In a sense this discovery was forced on me because I found it difficult to figure out how to use Ruboto or how it works and JRonA emerged in my struggle to understand.

Have fun!

Sharing Ruby Programs

I hope that one theme that runs through these various blog pieces is a preference for simple solutions.

I wondered in another piece why it was necessary to go to the trouble of writing the Jquery-Rails gem just to distribute a few Javascript files?

I have often felt that it would be nice to be able to give someone else a copy of one of my Ruby programs. But it was always very obvious that the people I would be likely to give a program to would have neither the interest nor the expertise to get the MRI Ruby system working so that they could use my program.

JRuby changes all that.

Of course JRuby only works on a computer with the Java runtime system. But most PCs have it already and, if not, installing it is straightforward - unlike installing MRI Ruby and the Gems necessary for your project.

If you want to distribute your JRuby project (big or small) all you need to do is include the JRuby system within it and a shell script or batch file that sets the PATH variable and starts the application. And if you give a copy of the whole project to someone else all they have to do is load it onto their PC and double-click the script/batch file.

For a simple project the directory structure might look like this

.
├── jruby-1.7.0.preview1/
├── helloworld.rb
└── LocalJRubyTerminal.sh*

Or for a Ruby-on-Rails project it might look like this

.
├── app/
├── config/
├── db/
~
├── jruby-1.7.0.preview1/
~
├── public/
├── script/
~
├── config.ru
~
├── LocalJRubyTerminal.sh*
├── Rakefile
└── README

Unfortunately if you go looking for internet advice about making your JRuby app shareable you will find any number of complex solutions (Warbler, Rawr etc) and (as far as I can see) no simple solutions that take advantage of the Java runtime system.

JRuby and Java

While I have been using Ruby and Rails for various personal projects for a few years I have to confess I had paid little attention to JRuby. I guess I saw it as another flavour of Ruby designed to scratch somebody's itch to build a better mousetrap and by causing confusion would just dilute support for Ruby generally.

And Java - ugh! It looks even less user-friendly than C, if that's possible.

However recently I spent a bit longer delving into JRuby and the Java system after coming across a new programming language called Mirah - which is a way of writing Java code using Ruby-like syntax.

I feel a bit sheepish admitting that I didn't realize the Java system revolves around a Java bytecode interpreter and that Java programs are compiled to bytecode rather than to native machine code. Hence compiled Java programs (including the JRuby system) can run on any computer (Linux, Mac or Windows) that has the Java runtime installed. I have understood the concept of bytecode for years - it's just that I didn't associate it with Java.

Well this opens up a whole new perspective on JRuby and how to use it.

While Rails is a wonderful product for helping write web applications it used to be a real pain to get it working. You had to make sure you had the right version of MRI Ruby (not necessarily the version Ubuntu wanted to supply) and you had to be able to download and access the right Ruby gems. Just when I thought I had learned how to do this reliably along came a wonderful program called RVM (Ruby Version Manager) that magically does all the complex stuff, and does it even better than you would do it yourself.

But there is another way of looking at RVM - as a product that solves a problem that should never have been allowed to exist.

You can, of course, use RVM to manage JRuby. But installing JRuby is so trivially simple that there is no need for RVM. You just download the Zip file, extract it to whatever directory you like, add the jruby/bin directory to your PATH and it just works - whether you're on Linux, Mac or Windows.

What this also means is that you can have a separate copy of JRuby (the same or a different version) in each of your JRuby (or Rails) projects with all of the Gems specific to that project.

And if you copy the project (including its copy of JRuby) to any other computer it will work there just the same as on your PC. And this is also true of a Rails project - even though Rails with MRI Ruby has a reputation for being hard to deploy.

And if that's not enough JRuby can easily access the hundreds of existing Java libraries including, for example, all the bits needed to make a GUI program that works the same on Linux, Mac and Windows.

All credit to Matz for inventing the Ruby programming language. But JRuby is the only practical manifestation of it - and thanks to Charles Nutter for that.

Capital Goods

Humans are the only species capable of developing capital goods - things that help you do other things. A spade was better at digging than a bare hand, and a JCB digger is better than a spade. And even though it's expensive it's cheaper than employing the several men who would be needed to do the same work.

This all sounds fine. But there is a "but" ... and it's the people who design and develop the capital goods.

If you are the designer what do you do when the JCBs start rolling off the production line? Do you say your job is done and apply to be a JCB driver? Not likely! You take another sheet of paper and set about designing another digger.

And the same happens in the software world. Back in the day (not long ago - 2003) there was no Rails and few people knew about the Ruby programming language which is also young (1995) and very clever. 

Then along came an incredibly clever young man called David Heinemeier Hansson (Google DHH) who realized that you could automate so many of the chores involved in developing a web application. It was a bit like the step from the spade to the JCB. And Rails attracted a following and evolved to version 2.something at which stage it was a pretty complete product - a working JCB if you like. 

However the developers didn't leave it there, they went on to make Rails 3 (and they are still evolving the product). My guess is that as many man hours (are there women on the development team?) went into the step from Rails 2.3 to 3.0 as went into the development up to version 2.3. But from the users' point of view Rails 3 is not much more than a new bucket attached to the JCB. 

The law of diminishing returns has kicked in with a vengeance - as it always does.

And it seems to me not only that a lot of effort is going to produce relatively small improvements but also that much effort is being absorbed with complex solutions (which show how clever you are) where simple ones would be as good or better for the end user.

A good example is the JQuery-Rails gem. All it really does is supply a few Javascript files and copy them into your Rails application. Wouldn't it have used less of mankind's resources to package them in a Zip file with a short Readme to explain where to put them? And the simple approach would allow the web developer using Rails to see what was being done and fix it if necessary.

Joel Spolsky wrote a blog piece about this sort of complication 10 years ago - The law of leaky abstractions. 

By the way I am just using Rails as an example. The same process occurs in all professions.

Introduction

I've long been interested in computer programming as a hobby and as an occasional part of my job. I even wrote Fortran programs on punched cards!

For the past few years I've been a great fan of Ruby on Rails and, very recently I have discovered the joys of JRuby.

Whether you like it or not I'm going to share my views on various bits and pieces - hopefully viewed from a somewhat different perspective than that of young software professionals.

My reader will have to use Google to figure out any "jargon" that s/he hasn't already come across. That way I can be lazy and write less.