Groovy in Action

I started my career with "dynamic languages" (we called them scripting languages then). I enjoy getting things done quickly with scripting languages, the power it gives you and the freedom to concentrate on the problem domain and not fight with the platform. With all the new languages that are available on the JVM alone, I'm having a lot of fun getting back to my roots. To this point I've mostly stuck to Ruby (JRuby) as I really like the syntax of the Ruby language. I've been aware of Groovy for quite some time... hearing Scott Davis and Andy Glover singing it's praises. But have just not given it enough attention... until recently.

I've been reading the Groovy in Action book from Manning. What a great title to get started with. When I get a tech book, I want to make sure it will pass the test of time... meaning: I don't want to read through it and then have to sell it or throw it away immediately due to it's uselessness. This book has a key component to it that makes it worth the money... the logical flow and organization of the book makes it perfect to work as a reference manual later on. If you are like me, you don't exactly remember EVERYTHING you read... reference abilities are VERY important to me.

With features like "FOR THE GEEKS", the layout stays interesting (as interesting as a technical book can be anyway... :) ) I also appreciate the effort taken not to go too far into Grails. Grails is very important to the Groovy language, but not everything. It's touched on in the back of the book, but just enough to give you an idea of it's potential benefit to your arsenal.

Google App Engine - JVM support

So of course most have heard Google App Engine now supports the JVM... and in doing that they have not only gone from just supporting Python, they now support Java and most of the other languages written to run on the JVM.

I find it interesting the first app I built for GAE with the new JVM support was simple Sinatra app using JRuby.  Like many other alternative JVM language implementers, the JRuby team leaped into action to make sure their stuff worked on GAE.  I have to admit I was amazed how things just seemed to work.  With some help from Ola Bini's post (for Bumble), I was able to build a simple application in no time at all.

Recently I was asked to look into implementation options for a project who's resources seem to have a skill set based in PHP.  Most of our work is based in the JVM so I went back to Caucho's Quercus PHP support for the JVM.  Based on a recommendation from the Twitterverse I started looking into the CodeIgniter PHP web framework as well.  This project seems to have a some momentum, the documentation at first glance appears up-to-snuff and video demonstrations are always a plus!

After playing around with CodeIgniter for a while running under oucho's Resin server, I figured someone had already run this framework on GAE... and of course someone has.  Caucho released a blog post about Quercus running PHP on GAE and this application seems to be proof of CodeIgniter on GAE.

Google had a ton of folks crying out to get their favorite language supported on GAE, Java was high on that list I'm sure.  But in supporting the JVM, Google has opened their App Engine cloud based platform to a miriad of developers to play around on.  Nice move Google.

Pick your battles

Random: Had a conversation today about when the right time to push for the things you want at work... in this case tools.  There is definitely a right and wrong time.  In this case, some of the push-back is due to the many deadlines hanging over everyone's head... and then again some may be posturing.  Requesting new tools to be installed/purchased/etc. during a period of stress at any level is futile.  The best advice I could give was to get things done first and document the different times during the push that this new tool could have come in handy.  After a "big win" or deployment, I'm not sure he'll have the same resistence to the tools he wants.

New Ruby Shootout 12/08

Antonio Cangiano has released another Ruby Shootout which are always fun to check out.  Looks like Ruby 1.9 is leading the pack with JRuby 1.1.6RC1 close behind.  Some of the JRuby tests failed which I'm sure pissed Charlie off!

JRuby vs. Java speed (re: Stochastic Simulation with SSJ)

Just read Ali Rizvi's blog post about "JRuby: Stochastic Simulation with SSJ" and decided to take a look at the implementation real quick... of course the Java version will be much faster, but the numbers given seemed a little strange.  After setting up the environment and running the tests, I saw the major slowdown as expected, then I decided to take a look at the Ruby code to see if I could speed things up a little.  This was done rather quickly, if you have better result... please share!

First, the Java version:

real    0m7.960s
user    0m7.839s
sys     0m0.056s

The JRuby version took too long to run (I'm pressed for time) so I added a few options to the runtime:

jruby -J-Djruby.compile.fastest=true --server collision.rb

real    3m55.834s

user    3m53.684s

sys     0m2.355s

Not as bad as reported by the blog ref'd above... but still pretty bad. I had a hunch the loops were what was killing the time and made the following changes to the collision.rb file:

@k.times { |i| @used[i] = false}

changed to:

@used.fill(false)

That brought the time down a bit:

real    1m1.430s

user    1m1.344s

sys     0m0.538s

It would seem loops are a sore spot. (kinda expected? the loop for setting happens in the Java impl) Decided to make one last change to see what happened. I condensed the "generate_c" method back into "simulate_runs" method to get the loops in one place. Some (not much) benefit was shown in my tests:

real    0m59.081s

user    0m59.027s

sys     0m0.502s

CONCLUSION: Yes, straight java is faster. Yes, there are ways to tune your Ruby to make things a bit more efficient. Yes, I'm sure there are other ways to make this run faster. I think prototyping this sort of thing in JRuby is just fine... then when you need more perf (if this stuff will be called from say a JRuby on Rails app) you can code it up in Java (Collision.java) and just call that from JRuby layer.

Here is the final collision.rb I ended up with :

require 'java'

require 'ssj.jar'



import 'umontreal.iro.lecuyer.rng.RandomStream'
import 'umontreal.iro.lecuyer.stat.Tally'
import 'umontreal.iro.lecuyer.rng.MRG32k3a'

class Collision
  def initialize(k, m)
    @k = k
    @m = m
    @lambda = m * m / (2.0 * k)
    @used = Array.new(k, false)
  end


def simulate_runs(n, stream, stat_c)

stat_c.init

n.times do

c = 0

@used.fill(false)

@m.times do

loc = stream.nextInt(0, @k-1)

if @used[loc]

c += 1

else

@used[loc] = true

end

end

stat_c.add(c)

end

stat_c.setConfidenceIntervalStudent()

puts stat_c.report(0.95, 3)

puts " Theoretical mean: #{@lambda} "

end



def self.run

stat_c = Tally.new("Statistics on collision")

col = Collision.new(10000,500)

col.simulate_runs(100000, MRG32k3a.new, stat_c)

end



end



Collision.run