The Bayesian Conspiracy

A tooltip class for HTML5 canvas written with Processing.js

2011-09-08T22:43:00.000-07:00

The visualization code I'm writing using Processing.js needs a tooltip to display some information depending on where your mouse is in the canvas. Although there are many tooltip options for webpage elements, I didn't find any that I could easily use with Processing.js to generate tooltips dependent on the mouse position in the canvas. After a few frustrating attempts with various libraries I finally just took this rounded corners demo by F1LT3R. and hacked together a ToolTip class of my own that works with Processing.js. I think it's pretty nice for a quick hack.
The tooltip has variable transparency, detects in and out of canvas state, and adjusts itself when the tooltip approaches a canvas edge. It has a clipping mode for static canvas images and a non-clipping mode for use with canvas animations. Although I haven't tested it, this library should work just as well with the java-based Processing. A demo of the tooltip is below, along with a nice HTML5 background animation that was also written in Processing.

Mouse over the canvas to make the tooltip appear. Click on the canvas to give it focus. Press 'r' to randomize background animation. Press 'a' to cycle through alpha levels. Press 'c' to randomize tip color.

You can download ToolTip.pde and test code from github:gist. ToolTip.pde has instructions in it's header. The use of this tooltip isn't limited to Processing sketches. Since processingjs pde files are converted to pure javascript before execution, you can also use this tooltip, as well as any other Processing.js library, in javascript code that writes to the canvas. The Processing QuickStart for JavaScript Developers gives examples of how to use Processing.js libraries with pure javascript and libraries like jQuery (which, incidentally, was written by the same person who created Processing.js).

Processing.js first impression

2011-09-02T00:14:00.000-07:00

I've been playing around with Processing.js to produce visualizations of some genomics data. The Java based Processing language/environment was originally developed by the noted data visualization guru Ben Fry and graphic artist Casey Reas. Processing.js is a port of the Processing language and libraries to javascript and the HTML 5 canvas by none other than John Resig, the creator of the jQuery javascript library. I was skeptical at first that Processing.js would be anything but a pale shadow of it's Processing predecessor, but after using it for a bit I have to say that I am impressed.
Most of the Processing sketches one can find scattered around the web and on such sites as Open Processing just work. Here, for example, is a sketch from the examples on Processing.org called reflection2. Click on image to launch another ball. Once the canvas element has focus, type 'r' to draw a new ground.:

The only requirement for this sketch to work is a browser that supports the HTML5 canvas. While it's not close to the speed of Processing compiled to JVM bytecode, the performance isn't bad at all and seems more than adequate for a wide range of visualization tasks. This is a testimony to the performance work that has been going into browser javascript engines as well as to the efforts put into optimizing processing.js itself. Embedding processing.js scripts in blogger, as I have done here, also turns out to be quite easy. Just add a script tag to grab the processing.js library to an (old style) blogger template and another script tag embedded in the post containing the processing code (view source to see both tags).

Gibbs sampler in Groovy

2011-07-25T17:32:00.001-07:00

I recently read a couple of nice articles by Darren Wilkinson about implementing MCMC in various languages. The posts are here and here. Wilkinson apparently uses, or is considering using, Python for a lot of prototyping and C for a lot of his actual MCMC runs. However, since he feels that Java is in some ways nicer than C, and almost as fast, he has been using Java some also for the final MCMC runs. I thought I'd see how Groovy performed on this task.
A Groovy version of Wilkinson's Gibbs sampler is given here:

#!/usr/bin/env groovy 

import static java.lang.Math.*
import cern.jet.random.tdouble.engine.*
import cern.jet.random.tdouble.*

N=20000
thin=500
rngEngine= new DoubleMersenneTwister(new Date())
rngN= new Normal(0.0,1.0,rngEngine)
rngG= new Gamma(1.0,1.0,rngEngine)
x=y=0.0
println("Iter x y")
for(i in 1..N){
  for(j in 1..thin){
    x=rngG.nextDouble(3.0,y*y+4)
    y=rngN.nextDouble(1.0/(x+1),1.0/sqrt(x+1))
  }
  println("$i $x $y")
}

You'd run it like:

./Gibbs.gv > data.tab

On a Macbook Pro 2.2 GHz Intel Core 2 Duo, comparing Wilkinson's Java (1.6.1) and Python (2.7.2) versions with my Groovy (1.8.0) version, I get the following times:

java: 5.23 sec
python: 1m49s
groovy: 16.5s

Not bad for a dynamic scripting language! Now, there are lots of things one can do to speed up the Python code, from using pypy to calling native functions and so on, so this is nowhere close to optimal for Python but, if you're going to ultimately translate your prototype into Java or C anyway, why bother with Python at all when you can rapid-prototype in Groovy then do the simple translation to Java, using the same libraries, later? Moreover, at one third the speed of Java, many times you won't even need to bother with the final speed-up step.

Using Groovlets in jQuery tutorial.

2010-07-05T22:33:00.000-07:00

I've been learning a little about jQuery by going through the excellent jQuery tutorial over at the jQuery Docs page. The examples use php for server side code, but since I'm more familiar with Servlets/Groovlets, I decided do the server side code as a Groovlet.
First, the setup. After installing Tomcat, I created a sub-directory under webapps called sandbox. In sandbox, I created a sandbox/WEB-INF directory with a lib sub directory. I copied all of /usr/local/groovy/lib/ to sandbox/WEB-INF/lib/, though only some of it is needed. I then put the following web.xml file under sandbox/WEB-INF/

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
  version="2.5">
  <display-name>Groove</display-name>
    <servlet>
      <servlet-name>GroovyServlet</servlet-name>
      <servlet-class>groovy.servlet.GroovyServlet</servlet-class>
    </servlet>
    <servlet>
        <servlet-name>GroovyTemplate</servlet-name>
        <servlet-class>groovy.servlet.TemplateServlet</servlet-class>    
  </servlet>
    <servlet-mapping>
        <servlet-name>GroovyServlet</servlet-name>
        <url-pattern>*.groovy</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>GroovyTemplate</servlet-name>
        <url-pattern>*.gsp</url-pattern>
    </servlet-mapping>
</web-app>

This web.xml will tell Tomcat to use groovy.servlet.GroovyServlet to handle *.groovy files. From then on, any .groovy files you put under /sandbox (or any subdirectories thereof) will be compiled as a Groovlet by Tomcat.

I then downloaded the jquery-starterkit from the jquery site and unpacked it into sandbox/jqstarterkit. In jqstarterkit are a number of files, custom.js, rate.php, screen.css, and starterkit.html. You will need to download jquery itself into /sandbox/jqstarterkit/ and rename it to /sandbox/jqstarterkit/jquery.min.js. Then go through the tutorial, editing custom.js to include the custom bits of jQuery javascript in the tutorial, seeing the results in:

http://localhost:8080/sandbox/jqstarterkit/starterkit.html

When you get to the part about rate.php, simply replace rate.php with rate.groovy in the custom.js script, like so:

jQuery(document).ready(function(){
  // generate markup  $("#rating").append(" Please rate: ");

  for ( var i = 1; i <= 10; i++ )
    $("#rating").append("<a href='#'>" + i + "</a> ");

  // add markup to container and apply click handlers to anchors  $("#rating a").click(function(e){
    // stop normal link click    e.preventDefault();

    // send request    $.post("rate.groovy", {rating: $(this).html()}, function(xml) {
      // format and output result      $("#rating").html(
        "Thanks for rating, current average: " +
        $("average", xml).text() +
        ", number of votes: " +
        $("count", xml).text()
      );
    });
  });
});

Then, create a file rate.groovy with the following contents:


// Simple AJAX groovlet... takes a rating from a jQuery $.post()// saves it to a file, computes the running average, then // returns a status line in XML format...
rating = request.getParameter('rating')
f = new File('sandbox/jqstarterkit/ratings.dat')
f << "$rating\n"

// Now, read in the file and compute number of ratings// and average rating...sum = 0;
count = 0;
f.eachLine{
  sum+= (it as int)
  count++
}
avg = (double)sum/(double)count

// Report result back to jQuery
// In Groovlet, html is bound to new MarkupBuilder(out) by default// so the following bit of markup substitutes for this string://  out<<"""//  <ratings>//    <average>$avg</average>//    <count>$count</count>//  </ratings>"""// // out itself is bound to response.getOutputStream()html.ratings(){
  average("$avg")
  count("$count")
}

When a .groovy file is interpreted as a Groovlet, several variables are pre-bound. request, for example, is bound to ServeletRequest. See the full list of bindings in the Groovlet docs. It took me a bit of trial and error to get all of this right and working. Hopefully this boilerplate will help someone else get up and going even quicker.

gcsvsql

2010-03-27T16:49:00.000-07:00

I have encapsulated the ideas from the last post into a single script that will allow you to perform SQL queries on CSV files from the command line as though those CSV files were existing database tables in MYSQL or something.

With gcsvsql, you can do things like:


gcsvsql "select * from people.csv where age > 40"
gcsvsql "select name,score from people.csv where age >40"
gcsvsql "select name,score from people.csv where age <50 and score > 100"

Full path names should work fine:

 
gcsvsql "select * from /users/data/people.csv where age > 40"
gcsvsql "select people.name from /users/data/people.csv where age > 40"

You can even do queries with sum and average and so on like:


gcsvsql "select sum(score) from people.csv where age < 40"

If children.csv is a file with same key name as people, then you can join query like:

  
gcsvsql "select people.name,children.child from people.csv,children.csv where people.name=children.name"

You can also enter the query on multiple lines like:

 
gcsvsql "
> select people.name,children.child
> from people.csv,children.csv
> where people.name=children.name and people.age < 40"

If this sounds interesting or useful to you, get more details and download the script over at the Google code project for gcsvsql

Executing arbitrary SQL on CSV files.

2010-02-05T00:29:00.001-08:00

My life is full of comma separated value files. A common occurrence is to be given a csv file of data and want to explore it a little bit to see what is there, or to extract several columns of data out of the csv file and create a new csv file, or grab only certain columns of data and certain rows of data and create a new csv file. Quite often I find that I even need to join one csv file with another csv file. Each time I'm faced with this task I find that what I want is to do execute sql statements on the csv file itself. After ages of writing one-off scripts to process files like these, I finally looked into actually treating csv files as databases. It turns out that the h2 database engine has good support for both in-memory databases and csv file importing. With Groovy, it's very nice. Simply download the h2 database jar and drop it in your ~/.groovy/lib/ directory. Then you can write code like this:

#!/usr/bin/env groovy

import groovy.sql.Sql
import org.h2.Driver

// Create an h2 jdbc in-memory database,
// calling it what you like, here db1
def db = Sql.newInstance("jdbc:h2:mem:db1","org.h2.Driver")

// Create a table from your csv file... 
db.execute("create table people as select * from csvread('people.csv')")

// Execute a normal sql query on this table...
db.eachRow("select * from people where age < 40"){row->
 println row
}

If you want to create a new csv file from your query, you will have to do a tiny bit more work. First you will need to extract the column headings of your query from the metadata, and then you will need to collect the rows into comma separated list. It's easy boiler-plate once you know how. Here is an example:

#!/usr/bin/env groovy 

import groovy.sql.Sql
import org.h2.Driver

// Create an h2 jdbc in-memory database, 
// calling it what you like, here db1 
def db = Sql.newInstance("jdbc:h2:mem:db1","org.h2.Driver")

// Create a table from your csv file...  
db.execute("create table people as select * from csvread('people.csv')")

// Get the column headings...
db.eachRow("select * from people where age < 40 limit 1"){row->
  meta = row.getMetaData()
  numCols = meta.getColumnCount()
  headings = (1..numCols).collect{meta.getColumnLabel(it)}
  println headings.join(",")
}

// Execute a normal sql query on this table...
db.eachRow("select * from people where age < 40"){row->
  meta = row.getMetaData()
  numCols = meta.getColumnCount()
  vals = (0..<numCols).collect{row[it]}
  println vals.join(",")
}

The h2 database engine pretty quick too. I can query a 100k file (both read it in as a table and do select on it) in about 5 seconds using code like that above.

Finally, to do a join on two csv files, you only need to create the two files and execute the sql, like:

#!/usr/bin/env groovy 

import groovy.sql.Sql
import org.h2.Driver

// mem says in-memory db, and call it what you like, here db1 
def sql = Sql.newInstance("jdbc:h2:mem:db1","org.h2.Driver")

// Create the first table...  
sql.execute("create table people as select * from csvread('people.csv')")

// Create the second table...
sql.execute("create table children as select * from csvread('children.csv')")

sql.eachRow("""
select people.name,children.child,people.age
from people,children 
where people.name=children.name and people.age > 40
"""){result->
  
  meta = result.getMetaData()
  cols = meta.getColumnCount()
  vals = (0..<cols).collect{result[it]}
  println vals.join(",")  
}

Groovy++

2010-01-21T16:43:00.000-08:00

I just ran across this article on Groovy++ performance. Groovy++, it turns out, is a project to implement a static compilation of Groovy. This article reports a 6x performance boost for the low price of adding a few keywords. Very few, it turns out. We're not talking manually defining all of the static types, as in Java, but in telling the Groovy++ compiler to fix the types during compile/runtime. I'm hedging with compile/runtime since, honestly, I only discovered this project a few minutes ago and haven't had a chance to really dig into the details of how it works. The project is hosted on Google Code and, although it isn't open source yet, it's slated to become open source soon. A decent introduction to the developer and the rational can be found in this article.

I'll have more to say about this once I get a chance to really check it out, but in the mean time it's something worth watching.

Create/open OmniOutliner notebooks from command line.

2009-10-24T13:48:00.001-07:00

I like to use OmniOutliner as a lab notebook, and I like to be able to create/open notebooks from the command line. The OS X 'open' command will open an existing file, but I didn't see any obvious way to run OmniOutliner from the command line and tell it to create a new file. So I created an empty OmniOutliner file and dropped in ~/Documents/template, then wrote a little script to copy that template and open it if it doesn't exist, or open the pre-existing file if it does. Simple and effective.

#!/usr/bin/env groovy 
/********************************************
*  A simple little script to open up a file in OmniOutliner
*  creating a default file if the file does not already exist. 
* 
*  Run it like:
* 
*  omni newNotebook
*/

def omniFile
if (args[0].contains(".oo3")){
  omniFile = args[0]
}else{
  omniFile = "${args[0]}.oo3"
}

// Get our home directory..
env = System.getenv()
home = env['HOME']

// If there is no omni outline file there, copy a template over...
if (!(new File(omniFile).exists())){
  "cp -r $home/Documents/templates/OOTemplate.oo3/ ${omniFile}".execute()
}

// Open the desired file..
"open ${omniFile}".execute()

Weka: getting predictions from cross validation

2009-10-10T00:28:00.000-07:00

A common question in weka forums is how to keep track of instances with names. Weka does not have a name field for instances, so to keep track of instances one has to create a string ID attribute that has the name of each instance. The catch, though, is that most classifiers don't work with string attributes, and you wouldn't want to classify on the ID anyway. The official solution then is to delete the ID attribute before calling the classifier. Of course, if you delete the ID, you loose the names for your instances! Oof! The solution is to use the meta.FilteredClassifier classifier with the RemoveType filter as the filter. When you hand a FilteredClassifier off to Evaluation, it will apply the filter before sending it to the classifier, but will keep track of the relationship between the source Instances (with the ID) and the filtered set sent to the classifier. Great. Now what if you want to know how instances were classified during your cross-validation? The API for extracting those classifications is not obvious, but it's easy enough once you know where to look. In Evaluate.crossValidateModel() you pass in a StringBuffer to hold the predictions. This can then be parsed to obtain the predictions and the instance names they go with. Source code to do this below:

#!/usr/bin/env groovy 

import weka.core.*
import weka.core.converters.ConverterUtils.DataSource
import weka.filters.unsupervised.attribute.RemoveType
import weka.classifiers.*
import weka.classifiers.meta.FilteredClassifier
import weka.classifiers.evaluation.*;

import java.util.Random

arffName = args[0]

// Read arff file...
data = DataSource.read(arffName)

// Pick out the class attribute..
data.setClassIndex(data.numAttributes() -1)
  
// Create a classifier from the name...
// By using filtered classifer to remove ID, the cross-validation
// wrapper will keep the original dataset and keep track of the mapping 
// between the original and the folds (minus ID). 
classifier = 
"""weka.classifiers.meta.FilteredClassifier 
      -F weka.filters.unsupervised.attribute.RemoveType 
      -W weka.classifiers.misc.HyperPipes"""

options = Utils.splitOptions(classifier)
classname = options[0]
options[0] = ""
classifier = Classifier.forName(classname,options) 

// Perform cross-validation of the model..
eval = new Evaluation(data)
predictions = new StringBuffer()
eval.crossValidateModel(classifier,data,cvFolds = 5,
  new Random(1),predictions,
  new Range("first,last"),false)

lines = predictions.toString().split("\n")
  
// Output of predictions looks like:  
// inst#     actual  predicted error prediction (ID)
//     1      1:low      1:low       1 (P1)
//     2     2:high      1:low   +   0.5 (P6)
//     3     2:high     2:high       1 (P0)
lines[1..-1].each{line->
  // Parse out fields we're interested in..      
  m = line =~ /\d:(\w+).*\d:(\w+).*\((\w+)\)/
  actual = m[0][1]
  predicted = m[0][2]
  sample = m[0][3]
  println actual+"\t"+predicted+"\t"+sample+"\t"+!line.contains("+")
}

Groovy in Google App Engine

2009-04-08T01:13:00.000-07:00

I'm quite excited that Google has added Java as a supported language in Google App Engine. Google App Engine is a free (up to a certain quota) service from Google where Google hosts your web app and handles all the issues involved in making it scalable and so on. Check out the Google App Engine site for more info. Google App Engine has been out for awhile but until a couple of days ago it only supported Python as a development language. Python is fine, so far as it goes, but outside of Google itself Python has nowhere near the base of web application support that Java does. I expect Java support to really blow the lid off of Google App Engine. In supporting Java, Google also supports a number of java based frameworks and JVM based languages. Most notable for me is support for writing a Google app engine app in Groovy.

Invalid duplicate class definition

2009-03-14T14:19:00.000-07:00

"Invalid duplicate class definition...One of the classes is a explicit generated class using the class statement, the other is a class generated from the script body based on the file name. Solutions are to change the file name or to change the class name. "

When I was first learning Groovy I would get this error from time to time. It was puzzling to me because sometimes I'd get this error, and sometimes it would seem like the same situation and I wouldn't. It seemed quite random to me when the error would crop up. When it did, I'd usually just rename the class and go on, resolving to figure it out later. To save you the trouble, here's what is happening.

Groovy has two ways to treat a .groovy file: either as a script, or as a class definition file. If it is a script you can not have a class by the same name as the file. If it is a class definition file you can. It is very easy to tell whether a .groovy file is going to be treated as a script or as a class definition file. If there is any code outside a class statement in the file (other than imports), it is a script. What is happening is that if there is any code to be executed in the file then Groovy needs a containing class for that code. Groovy will implicitly create a containing class with the name of the file. So if you have a file called Grapher.groovy that has some code in it that isn't inside a class definition, Groovy will create an implicit containing class called Grapher. This means that the script file Grapher.groovy can not itself contain a class called Grapher because that would be a duplicate class definition, thus the error. If, on the other hand, all you do in the file Grapher.groovy is define the class Grapher (and any number of other classes), then Groovy will treat that file as simply a collection of class definitions, there will be no implicit containing class, and there is no problem having a class called Grapher inside the class definition file Grapher.groovy.

It's worth mentioning that the script version of Grapher.groovy will be compiled into a class called Grapher that extends groovy.lang.Script. In the other case, when Grapher.groovy merely defines classes, one of which is Grapher, that Grapher class will be compiled into a class that implements groovy.lang.GroovyObject.

I'm sure this is all explained somewhere in the Groovy documentation, but it didn't soak in to me until I read this Nabble post from which I extracted this explanation.

Groovy compared to Perl

2009-03-09T12:30:00.000-07:00

If you are a bioinformatics person considering taking up Groovy as an alternative to Perl, you will naturally wonder how the two compare on a range of simple tasks. Luckily, there is a great set of examples over at PLEAC (Programming Language Examples Alike Cookbook). Most bioinformatics Perl programmers have probably seen the Perl Cookbook by Tom Christiansen & Nathan Torkington. The aim of PLEAC is to implement all of the solutions found in the Perl Cookbook in other languages. The Groovy examples are 100% complete, so you can see how every Perl cookbook solution could be performed in Groovy. Go have a look!

Groovy for bioinformatics.

2009-03-09T12:11:00.001-07:00

I'll have a lot to say about Groovy for bioinformatics in this blog. Until I have time to write some posts on the topic here is Mark Fortner's brief comparison of how Groovy stacks up to Perl for bioinformatics. Mark has also set up a BioGroovy project wiki.

Groovy is groovy. Groovy is Java.

2007-06-05T13:12:00.000-07:00

Groovy is groovy. At least for me. Groovy is also Java, like quick and dirty Java all dripping with syntatic sugar. If you know Java you essentially know 80% of what there is to know about Groovy because underneath it's all Java objects and the syntax is roughly a superset of Java. Most Java programs will run, unaltered, as Groovy programs. Although Groovy's dynamic features, powerful language constructs, and other goodness will grow on you, a Java programmer can approach Groovy initially as if it were simply a kind of Java that can be executed without compiling and with the option to soft focus some of the details.

For example, here is a dumb little Groovy script that I wrote to convert a comma separated file into a tab separated file.

#!/usr/bin/env groovy

for(line in System.in.readLines()){
  bits = line.split(",");
  for(bit in bits){
    print bit+"\t";
  }
  println "";
}

This is something I wrote on the first day I was learning Groovy so it is not idiomatic Groovy. Groovy can be much more succinct than this. A Perl person might prefer a command line one-liner like:

cat test.tab | groovy -pe '(line =~/\t/).replaceAll(",")'

Nonetheless, this little script shows how one can come to Groovy gently from Java. First, that's a complete Groovy program. If it were Java, there'd have to be more, the declaration of a containing class, for example. Groovy provides an implicit containing class with the name of the file. You'd also have to be more fastidious about declaring the types of variables. Groovy works out types during runtime. The types Groovy eventually assigns to variables will be Java types. line and bits, for example, will resolve to java.lang.String, and all the functionality of java.lang.String is there for you just like you remember it. Also, unlike a Java program, Groovy scripts don't need compiling (if you need to, though, you can compile Groovy to a .class file to use in a Java program). You can just run the file like a Perl script, for example:

cat data.txt | comma2tab  > data.tab

So you can see that you get that sort of Perl-like hack-together-something-quick quality: no compiling, direct execution of the source file (via shebang or the command line interface), rapid edit/test cycle, and stripped down verbosity. Suppose I also wanted to add a date tag to each line. When I was doing my scripting with Perl I'd have to grind to a halt while I looked up various Perl date APIs. Obviously, if 99% of my code were scripting Perl I'd probably already know that, but my code is more like 10% C++, 65% Java, and 25% scripting. As a result, I'm much more likely to already know the Java API for something than the Perl API. With Groovy I can add date functionality without having to learn any new API's, I can just use the Java one I already know:

#!/usr/bin/env groovy  
  
date = new Date();  
for(line in System.in.readLines()){  
  println date.toString()+"\t";  
  bits = line.split(",");  
  for(bit in bits){  
    print bit+"\t";  
  }  
  println "";  
}

That print is, by the way, System.out.println, it' just lets you use the shorthand if you like. You don't have to though. With a simple import, you can use any of your own Java classes just as easily. Drop any external library into your CLASSPATH, or a jar into your ~/groovy/lib directory, and you have ready access to that functionality too. You can even hack together simple GUI's in just a few lines of code.

Given that I have worked on several pure-Java projects in the past few years, Groovy really fills a niche for me. Working in bioinformatics I have a lot of need for scripting, to create quick and dirty one-off programs to crunch some data or do some bulk operation, something someone wants today and will never use again. I also have a fair bit of need for production quality webpages, for computation intensive algorithms, and for GUI visualization tools. The combination of Groovy+Java nicely fills all of these needs for me. I can write my high quality webpages in Java (or Grails), my computation intensive algorithms in Java (which has become performance competitive in the past few years, within 2x of C [3]), my GUI visualization tools in Groovy/Java/Swing, and my one-off scripts and pipeline glue in Groovy. One set of libraries and API's to master to do all my work. The ability to share code across all the kinds of work I do. All my code is cross platform. It's like having my cake and eating it too!

If you know Java, you owe it to yourself to try Groovy. If you find yourself writing one kind of software in one language, another in a different language, you owe it to yourself to try Groovy. The rest of you, you should probably try it too.

[1] Six Things Groovy Can Do For You
[2] IBM Groovy articles
[3] 1.8x median, behind only C++, C, and ATS