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.

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

JRuby getting lots of attention lately

Of course while I'm away, toiling on projects using Spring/Hibernate, JBoss/EJB3/GWT things with the JRuby world get really exciting.  New versions of JRuby are rolling out everytime you turn around and the gems and projects that run on jruby are getting refreshed daily it seems.  Here are just some of the highlights I've seen fly by...

• JRuby 1.1.6RC1 released (final due next week)


• Glassfish gem 0.9.1 released (with latest Glassfish v3 server inside)


• Rails 2.2 released and JRuby mentioned right there in the title... wasn't long ago when the jruby team was fighting to get Rails even run on it's implementation.


• Mike Herrick and his team are seeing incremental performance improvements for jruby releases...

Hopefully I'll get some time of the holidays to dust off some of my (now old) projects and give them a whirl with all the new hotness... I'd love to do some more benchmarks and see if the thread-safety of Rails does anything to improve things on jruby outright.  Of course, I'll post results if I can get around to it.

For a sort of realtime look at what folks are doing with jruby:

• http://search.twitter.com/search?q=jruby

Interesting... that is all

Just read this post...

Just saying... it's interesting.  Seems to be a lot of the benchmarking bug going around these days.

JRuby slowdown from Rails 2.0.2 to 2.1.0

Before you decide to bring your current JRuby on Rails app to the latest 2.1.0 version... you may want to take a look at the performance. I was running the console benchmark from this blog post with jruby trunk and saw some numbers I wasn't expecting:
[sourcecode language="ruby"]
in console: 6.times {puts Benchmark.measure {10000.times {Person.find :first}}.total}
4.47 : jruby 1.1.2 & rails 2.0.2 (jdbc) (best out of 6 runs)
5.43 : jruby 1.1.2 & rails 2.1.0 (jdbc)
4.12 : jruby 1.1.3 (trunk) & rails 2.0.2 (jdbc)
5.06 : jruby 1.1.3 (trunk) & rails 2.1.0 (jdbc)
[/sourcecode]

JRuby trunk IS faster than 1.1.2 as expected, but JRuby overall is experiencing a (pretty significant) slowdown when running Rails 2.1.0.

Hopefully finding the culprit for this slowdown will open the floodgates for improving JRuby on Rails performance.

JavaOne '08 - Script Bowl apps for JRuby released

This year's JavaOne had an interesting competition... the Script Bowl.  Pitting 4 different languages (Groovy, Scala, Jython & JRuby) on the JVM against each other in three different categories.  (Rich Client Application, Web Application and an Open event)  Check the results here on Rags' blog.

Headius just posted the JRuby Script Bowl artifacts for your viewing pleasure.  Anyone know if the other languages have posted their apps/code?

Re: RSS Feeds for Subversion

I was reading a friend's blog post about RSS feeds for Subversion repositories earlier... he couldn't find anything that was not written in a scripting language which he has no access to in his environment... he needed a Java based solution.  He solved his problem with a war.  I came back to this after dinner (and a few glasses of wine) and decided to show him another way to solve this problem on the JVM... (you knew it was coming Matt.)

Assuming you already have JRuby setup (of course you do), we'll do the following to get the one gem we'll need:
[sourcecode language="css"]
> jruby -S gem install rscm
[/sourcecode]

The RSCM (Ruby Source Code Management) gem provides a nice interface to SVN, CVS, ClearCase, StarTeam, etc. and since it's written in pure Ruby, it runs just fine on the JVM.

Then download this file. Not much to it, 106 lines and 45 of that is the template for creating the rss xml doc.

Command line has a few options, here's an example:
[sourcecode language="css"]
> jruby -J-server server.rb -p 8080 -m svnlog
or just get help
> jruby server --help

-p, --port=3003 Which port do you want the server to listen on.
-m, --mount-point=svnrss http:///
-h, --help Show help (this).
[/sourcecode]

Point your RSS reader @ the following: http://localhost:8080/svnlog?url=http://svn.codehaus.org/jruby/trunk/&num_revs=15 and here's what you get:

(Firefox 3 beta)

Nice, think I'll actually use this.

Some Rails perf numbers on JRuby 1.1.1 part 2 (Linux, JDK 6)

After this post, I got a lot of suggestions to re-run the benchmarks using JDK 6. I'll let you read the previous post to see what exactly I did... here's what the runtime looks like for this run:

• Ubuntu 7.10 / Dell Latitude D830


• Ruby 1.8.6


• JRuby 1.1.1


• JDK 1.6.0_03

*NOTE: could not run benchmarks without jdbc drivers (jdbcmysql adapter) due to JRUBY-2303

First the Rails console benchmark numbers:

[sourcecode language="css"]
5.15 seconds - Ruby console
2.41 seconds - JRuby console (jdbc)
[/sourcecode]

(side-note: re-running the console test with JDK 5 on same machine, best out of 6 runs: 3.31 seconds)

Next the Web Server numbers: (numbers in parens are the number of benchmark runs)

[sourcecode language="css"]
272.84 Mongrel (6)
257.02 GlassFish (40)
235.17 Mongrel (jruby/jdbc) (20)
188.12 Glassfish (-n 2, 20)
179.76 Mongrel (jruby/jdbc) (10)
168.52 Glassfish (6)
161.12 Mongrel (jruby/jdbc) (6)
151.04 Glassfish (-n 2, 6)
131.89 Tomcat 6 (30)
105.72 Tomcat 6 (6)
[/sourcecode]

The console numbers show JDK 6 really kicking in... contrast that with the numbers for actually serving the Rails app and you can see there is still some work to be done to make Ruby on Rails serve faster on the JVM.

Again, not very scientific, just something to show where things stand for now. If you have better benchmarks, please link to them from the comments section below.

Some Rails perf numbers on JRuby 1.1.1

UPDATE: Next up will be the same benchmarks using Java 6 on ubuntu.

Just before JRuby 1.1.1 was released, I was surfing around and found this post which shows JRuby running basic Rails bench tests slower than MRI. I wondered what those numbers would look like now, so I got to testing.

I started by downloading the latest binary release of JRuby here.

I setup a Rails app following the theme mentioned by the blog post above, then ran the console benchmark 6 times with each runtime and list the lowest time below:
[sourcecode language='css']
jruby -J-server script/console production
>> Benchmark.measure {10000.times {Person.find :first}}.total
=> 10.352999925613403

ruby script/console production
>> Benchmark.measure {10000.times {Person.find :first}}.total
=> 4.98
[/sourcecode]

Now I wanted to see if the ActiveRecord-JDBC drivers would help the situation:
[sourcecode language='css']
jruby -S gem install activerecord-jdbcmysql-adapter
vi config/database.yml ("mysql" -> "jdbcmysql")

jruby -J-server script/console production
>> Benchmark.measure {10000.times {Person.find :first}}.total
=> 4.134999990463257
[/sourcecode]

Sped things up quite a bit... Now for Mongrel:
[sourcecode language='css']
> mongrel_rails start -e production
Requests per second: 202.27 [#/sec] (mean)

jruby -S gem install mongrel
jruby -J-server -S mongrel_rails start -e production
Requests per second: 96.47 [#/sec] (mean)

# now with adapter: jdbcmysql about the same... got a bit faster after warm-up
Requests per second: 120.05 [#/sec] (mean)
[/sourcecode]

MRI's Mongrel beats JRuby version even after a little warm-up period. I also wanted to see what GlassFish would do :
[sourcecode language='css']
jruby -S gem install glassfish

jruby -S glassfish_rails start ../person_test/
Requests per second: 132.93 [#/sec] (mean)

# now with jdbcmysql adapter
jruby -S glassfish_rails start ../person_test/
Requests per second: 139.96 [#/sec] (mean)
[/sourcecode]

Just goofing around, I used an experimental setting to see what would happen. I repeated the benchmark for some time and you can then really start seeing the JVM 'harden' the execution path... I'm sure the tests above may have benefited in the same way had I let them run but here are the numbers of a glassfish_rails server with 2 Rails instances (probably ran the benchmark about 10-15 times?)
[sourcecode language='css']
jruby -J-server -J-Djruby.compile.fastest=true -S glassfish_rails start -n 2 ../person_test/
Requests per second: 211.64 [#/sec] (mean)
[/sourcecode]

I also wanted to see some numbers for Tomcat 6, a war'd Rails app using Warbler. The numbers were not at all what I was expecting... even though I know things out of the box are not tuned for this type of deployment. The best numbers I could get were:
[sourcecode language='css']
Requests per second: 67.68 [#/sec] (mean)
[/sourcecode]

So what does this tell me? JRuby is getting faster each release. There is more work to be done to make JRuby on Rails apps faster. GlassFish is a very easy way to deploy JRoR apps. And last, I am definitely doing something wrong with my war'd depoyment!

I could not find much else in the way of JRuby on Rails benchmarks... if you know of any, please link in comments!

P.S.
All these benchmarks were run on a MacBook 2GHz Core Duo with 1GB mem., Java 5, JRuby 1.1.1, Ruby 1.8.6, Ruby on Rails 2.0.2, MySQL 5.0.27.

JRuby 1.1.1 to be released today!

2 short weeks after the JRuby team released version 1.1 we'll see the next release some time today.  Version 1.1.1 resolves 41 issues and focuses on stability, performance and compatibility according to Charles Nutter.

Issues still exist with JRuby on GCJ and possibly on IBM's JVM 5.  Anyone using these platforms is encouraged to submit bugs or possibly fixes.

The pace on this project is truly amazing...  I plan to write-up a few posts about a recent project I worked on which used JRuby and Rails to speed development, exciting times my friends!

JRuby / Ruby Continuous Integration with Hudson

Hudson is a great tool for your continuous integration needs. It's very easy to setup and can run/monitor multiple types of tasks. Some have used it for Python and this blog entry will show you how to get Hudson setup quickly for running your Ruby or JRuby tests. (including reporting)

(This step-by-step is assuming you have Java installed on the machine you are using.)

First we'll need to download Hudson here and start our Hudson instance: (just grab the latest stable release)
[sourcecode language='css']
java -jar hudson.war
[/sourcecode]
(see Hudson site for other deployment options.)

Next, grab the CI::Reporter gem we'll need for test results xml formatting :
[sourcecode language='css']
gem install -y ci_reporter
OR for JRuby
jruby -S gem install -y ci_reporter
[/sourcecode]

UPDATE: Make sure you insert the following lines in your Rakefile:
[sourcecode language='ruby']
require rubygems
gem ci_reporter
require ci/reporter/rake/test_unit
[/sourcecode]

Hit your running Hudson instance: http://localhost:8080/ and configure a new build by clicking the "New Job" link. Enter the name of your build and select the "Build a free-style software project" (click OK.)

Configure your SCM data, then scroll down to the "Build" section and select either "Execute Windows batch command" (windows) or "Execute shell" (*nix). This is where we'll call our 'rake test' task using the CI::Reporter gem and specifying a spot for the report XMLs to live:
[sourcecode language='css']
//rake ci:setup:testunit test CI_REPORTS=results
OR for JRuby
//jruby -S rake ci:setup:testunit test CI_REPORTS=results
[/sourcecode]

UPDATE: When using Subversion, it will check things out into a sub directory of your "workspace" (found ~<user running hudson>/.hudson/jobs/<your job name>/workspace) If you are checking out 'trunk' and don't specify a different name for the directory, your shell execution settings should look like this:
(be sure to know how your SCM works before applying the following)
[sourcecode language='ruby']
cd trunk
//rake ci:setup:testunit test CI_REPORTS=results
[/sourcecode]

This will setup the CI::Reporter and place the XMLs in the "results" directory for us.

We are almost done, now under the "Post-build Actions" section, check the "Publish JUnit test result report" box and enter the following in the "Test report XMLs" field:
[sourcecode language='css']
results/*.xml
[/sourcecode]

Now click Save and go test it out... Select your newly created job from the Dashboard.

Click the "Build Now" link... done. After a few builds you should see a graph on the job's main page that looks like this:


If you have a failure, you can drill down by clicking the "Test Result" link on an individual build's page.



Clicking on an individual failed test's name will show you the output from that failure



That's all it takes, pretty simple and works like a charm. Now you can go back and play with the other settings Hudson has, triggers, scheduling, job artifacts, notifications... you could even have a job that prepares a build by generating all your static content so your server doesn't have to take the initial hit after startup. (web projects)

If interested, there is a way to create plugins for Hudson.

Latest JRuby release is faster

The latest JRuby release (Jruby 1.1RC1) improves on the past numbers showing the recent push for speed. I have been out of the loop for a while but am not surprised to see these improvements.


But speed was not the only thing happening in the JRuby camp lately :

- 143 issues resolved since JRuby 1.1b1
- Landing of Java port of Oniguruma (Joni)
- Most Posix methods supported (e.g. stat, kill, getuid)
- Latest Rubygems 1.0.1, RSpec 1.1.1, and Rake 0.8.1 gems
- Updated standard library to be Ruby 1.8.6 compatible

more details here

Makes one wonder... with JRuby's speed increases, Java integration (remember Java is everywhere) and a great tooling story... when does JRuby replace Rhino as an alternate pre-packaged language in the JDK? (or the JRE for that matter?)

New Ruby Shootout

Antonio Cangiano recently completed a new Ruby performance shootout:
The Great Ruby Shootout

JRuby has a very nice showing this time compared to the shootout done in February.



Congrats JRuby team!

On a separate note, Charles Nutter (JRuby core developer) recently asked that all benchmarks currently being outperformed by Ruby 1.8.x should be reported as bugs!!! Bold and inspiring!

Interesting Debate...

Martin Fowler brings up a good topic on his blog : "GroovyOrJRuby"

I like the way Martin ends this post... Ruby (and Rails) have brought the dynamic (we used to call them scripting) languages back to the forefront.

There is a need for different languages, to help the programming/software engineering world grow. Finding different ways to do things. The same way we have Ruby, Python, Perl, PHP... we should have JRuby, Jython, PHP/Quercus, Groovy.

Which language is the best for the JVM? I would not jump right into saying Java... it really depends on what you are doing.

Swing'in with Ruby and Javascript

I did a presentation last fall about Mozilla's Rhino (a Javascript engine found here.) One of the things demonstrated was the use of Java's Swing from Javascript. It's a tiny bit of simple code so I thought it might be interesting to look at the similarities and diffs between Rhino and JRuby's Java integration from this perspective.

Javascript (Rhino)

[sourcecode language="js"]
importPackage(Packages.javax.swing)

frame = new JFrame("My New Window")
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE)
frame.setSize(200,200)

panel = new JPanel()

button = new JButton("Click Me")

function clicked() {
print("button was clicked")
}

button.addActionListener(clicked)

panel.add(button)

frame.add(panel)
frame.pack()
frame.show()[/sourcecode]

Ruby (JRuby)

[sourcecode language="ruby"]
require "java"

include_class %w{
javax.swing.JFrame
javax.swing.JPanel
javax.swing.JButton
java.awt.event.ActionListener
}

frame = JFrame.new("My New Window")
frame.set_default_close_operation(JFrame::EXIT_ON_CLOSE)
frame.set_size(200,200)

panel = JPanel.new

button = JButton.new("Click Me")

listener = ActionListener.impl do
puts "button was clicked"
end

button.add_action_listener(listener)

panel.add(button)

frame.add(panel)
frame.pack()
frame.show()[/sourcecode]

Similarities

1. short and sweet, much nicer than writing this tiny thing in Java


2. only one JVM specific call in both : importPackage and include_class respectively

Diffs

1. Java support automatically 'on' in Rhino : no need to call something to initiate the Java support (JRuby: require 'java')


2. Rhino has fewer lines : yes, part of this is how I include the classes, but not all...


3. specifying the ActionListener : Rhino simply allows a function to be passed in... JRuby needs to have an impl of the ActionListener interface... which requires me to include that class


4. speed : Rhino is faster for this silly test... this is most definitely due to the sheer size of the JRuby impl. Rhino comes in just about 3 times faster than JRuby.

Conclusion

Either way, it's much easier to work with than writing the same thing in Java. JRuby now has a few libraries to help you build your JRuby Swing apps:

• Profligacy


• Monkeybars

I have not seen anything for Rhino, but that doesn't mean they don't exist!

ActiveRecord Migrations - JRuby

I was goofing around a while back, wanted to use AR in a Java project... came up with this Rakefile. Comments welcome, didn't spend much time on it so I'm sure there may be some issues:

[sourcecode language="ruby"]
require 'active_record'
require 'active_support'
require 'yaml'
require 'ftools'

$mig_dir = 'db/migrate'
File.mkpath($mig_dir) if !File.exists?($mig_dir)

task :default do
Rake.application.options.show_task_pattern = //
Rake.application.display_tasks_and_comments
end

namespace :db do
task :environment do
ActiveRecord::Base.establish_connection(YAML::load(File.open('database.yml')))
ActiveRecord::Base.logger = Logger.new(File.open('.migrations.log', 'a'))
end

desc "Migrate the database through scripts in db/migrate. Target specific version with VERSION=x"
task :migrate => :environment do
ActiveRecord::Migrator.migrate($mig_dir, ENV["VERSION"] ? ENV["VERSION"].to_i : nil)
end

desc "Get the schema version number from DB"
task :version => :environment do
class SchemaInfo :environment do
abcs = YAML::load(File.open('database.yml'))

case abcs["adapter"]
when "mysql", "oci", "oracle"
ActiveRecord::Base.establish_connection(abcs)
File.open("db/schema_structure.sql", "w+") { |f| f db/schema_structure.sql"
else
raise "Task not supported by '#{abcs["test"]["adapter"]}'"
end

if ActiveRecord::Base.connection.supports_migrations?
File.open("db/schema_structure.sql", "a") { |f| f < max then n else max end
end
end

def next_migration_number
current_migration_number + 1
end

def next_migration_string(padding = 3)
"%.#{padding}d" % next_migration_number
end

def write_template(file_name, name)
contents = < :user_id do |t|
# t.primary_key :user_id
# t.column :user_id, :integer, :null => false
# t.column :first_name, :string, :null => false
# t.column :last_name, :string, :null => false
# end

# sample for self.down:
# drop_table :users

end
EOS

File.open("#{$mig_dir}/#{file_name}", 'w') do |file|
file.write(contents)
end

puts "Created migration file: #{$mig_dir}/#{file_name}"
end[/sourcecode]

“DynLangs” and you…

Unless you have been living behind your monitor and keyboard only to look up to find the coffee mug you knocked over, you've most likely heard about all the attention dynamic languages, or dynlangs, have been getting these days. Dynamic Languages (or scripting languages) have been taking their spot in the limelight in recent years... I feel this is in large part due to the readily available video streaming sites showcasing the benefits of such languages/frameworks.

For those willing to step outside the compiler, large gains in productivity abound. And with so many dynamic language options being implemented on the JVM, JSR 223, and attention from large companies... dynlangs are quickly becoming viable options in companies and organizations that would never have considered using them in the past.

If you primarily work with a compiled language (Java maybe?) and don't want to miss the productivity boat, you may want to review the following list comprised of just a few languages/frameworks making waves (on and off the JVM) :

Languages

Ruby

Object Oriented, interpreted, dynamically typed language. Created by Yukihiro “matz” Matsumoto, everything is an object and every class is "open" for change.

JRuby

JVM implementation of the Ruby language... provides the ability to use the Ruby language and leverage the existing capabilities of the Java Virtual Machine (and all it's libraries.)

Groovy

Dynamic OO language built for the JVM... "builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk"

Python

Dynamic OO language, embeddable, integration friendly, dynamically typed. Strong user base.

Jython

JVM implementation of the Python language... project has fallen behind the Python pace, but new life buds. As with most JVM dynlangs, Jython provides Java integration.

Scala

Type-safe, both object oriented and functional. Written for the JVM so the Java integration is there.

Rhino

JVM implementation of the JavaScript language... all you would by now expect from a JVM dynlang, Java integration, embeddable, shell access.
... and of course...

PHP

"PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML." Heavily pervasive, low barrier to entry, object oriented with PHP 5, large library code base.
(PHP can now run on the JVM too: Quercus)

Web Frameworks

Ruby on Rails

"Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control pattern. From the Ajax in the view, to the request and response in the controller, to the domain model wrapping the database, Rails gives you a pure-Ruby development environment. To go live, all you need to add is a database and a web server." ORM, MVC, JavaScript and templating for views...

Grails

"It's an open-source web application framework that leverages the Groovy language and complements Java Web development." Inspired by the Ruby on Rails framework (at least at one time it was.)

django

"Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design." ORM, MVC we're seeing a pattern here...

Symfony

"Based on the best practices of web development, thoroughly tried on several active websites, symfony aims to speed up the creation and maintenance of web applications, and to replace the repetitive coding tasks by power, control and pleasure." (PHP web framework)

Did I miss a dynlang/framework you enjoy working with? (most certainly...) Then drop me a line in the comments below and let me know what dynamic language or framework you use to get your job done!

P.S.
One of the best implementations of a dynamic/scripting language IDE around (non-trivial task): NetBeans Ruby Support (thanks Tor)