techno.blog("Dion") » Groovy

SWeb 3.0: Paul Hammant goes from Thicky to Swiby

dion — Sun, 14 Oct 2007 03:53:32 +0000

Paul Hammant has been involved in a ton of fantastic open source projects, and some cool toys too. Thicky was a toy that I would often show off when I was doing the Groovy thing. Building prototypes of Swing apps with a nice builder API was great.

Now he is having a bash on the web, and has written up his thoughts on SWeb 3.0 which gratuitously joins the Web 3.0 debate although it isn’t some drivel about how “Web 3.0 will include even MORE participation ….”.

Paul has joined up to make Swiby happen:

With Swiby the pages, should be shipped from the server side web frameworks like those today (Ruby on Rails, or Waffle), and executed in the browser via that plugin. All of these will be possible:

AJAX-like behavior

lazy loading of hidden tabs, or sections of a page

threaded / timed events

client side object storage more sophistcated that the current browser cookie

amazingly rich interfaces (YouTube, GMail, Writely should be easy to do)

equivalent of CSS for properties of widgets

server side decoration a la Sitemesh or PhpMesh

tiny pages, quick loading, and quick transitions from one page to another

The philosophy is that Swing has a nice component model and the cool side of the Web is the REST stuff, and a page centric world.

Paul is trying to take the best of both worlds to make it easier to build very rich apps on the Web platform.

It is a bold play, and is obviously an up hill battle against the incumbants, but I am all for more projects pushing the edges here, and I can’t wait to see more.

LINQ 101 to Ruby 101 to Groovy 101

dion — Sun, 02 Oct 2005 09:47:07 +0000

Jon Udell posted some code that he was playing with to test out LINQ.

The code takes his blog format, and filters based on the XML, and some internal datastructures.

Then Sam Ruby ported it to Ruby.

For some reason I just ported it to Groovy:

def d = ["2005-09" : "September 2005", "2005-08" : "August 2005"]
def a = ["greasemonkey", "ajax"]

def rss = new XmlParser().parse("blog.xml")

def xml = new groovy.xml.MarkupBuilder(new PrintWriter(System.out))

rss.channel.item.findAll { item ->
d.keySet().any { day ->
t(item.date) =~ day;
} && a.any { tag ->
t(item.tags) =~ tag;
}
}.sort { x, y -> t(y.date) <=> t(x.date) }.each { i ->
xml.item() {
month(d[d.keySet().find { key -> t(i.date) =~ key }])
date(t(i.date))
title(t(i.title))
tags(t(i.tags))
}
}

def t(node) { return node[0]!=null ? node[0].text() : '' }

There are some uglies in there (especially the “node to text” pain), but I do prefer the native build syntax that we have in Ruby and Groovy, compared to nesting new XElement("item", ....). They could easily add more sugar to make that work on the .NET side of course.

The other interesting differences are that I didn’t use XPath in the Groovy version, and the lack of SQL like stuff. Here it is just method chaining. No need for a special orderby, you simply do a sort. Of course, the beauty of LINQ is its polymorphism across XML, SQL, etc etc.

Update: New Version

John Wilson took out his namespace aware XmlSlurper (to access dc:date vs. date), and a new builder syntax that handle multiple objects:

def d = ["2005-09" : "September 2005", "2005-08" : "August 2005"]
def a = ["greasemonkey", "ajax"]

System.out << new StreamingMarkupBuilder().bind {
mkp.declareNamespace(dc: "http://purl.org/dc/elements/1.1/")

new XmlSlurper().parseText(blog).channel.item.findAll {item ->
d.any{entry -> item.date.text() =~ entry.key} &&
a.any{entry -> item.tags.text() =~ entry}
}.list().sort{x, y -> y.date.text() <=> x.date.text()}.each {i ->
item([{month d.find{entry -> i.date.text() =~ entry.key}.value}, i.date, i.title, i.tags])
}
}

invokedynamic: New Java Bytecode for the Dynamics

dion — Thu, 29 Sep 2005 06:23:12 +0000

I am thrilled to see this post by Gilad Bracha, on the new invotedynamic bytecode that is “coming to a JSR near you very soon”.

I was beginning to think that this may not be coming, even though I know that people asked for it at the dynamically type language meetup at Sun, but look:

Last winter we had a meeting with various people who work on such languages – things like Groovy, Perl, Python/Jython. Our conclusion was that the most practicable thing was to support dynamically typed method invocation at the byte code level.

The new byte code, invokedynamic , is coming to a JSR near you very soon. I

Speaking to your applications via Jabber

dion — Thu, 08 Sep 2005 17:39:13 +0000

Guillaume Laforge has written about how you can get Groovy with Web services RPC calls over Google Talk.

I have actually seen a bunch of applications that take use of this kind of functionality.

One smart friend has integrated Jabber with Confluence.

Imagine being able to get on IM and start asking questions, and having a bot answer them, based on your wiki.

Add voice recognition to the mix, and you can start talking to your applications :)

Getting around BigDecimal pain with Groovy

dion — Tue, 02 Aug 2005 02:47:44 +0000

BigDecimal is a necessary evil, isn’t it. Without it, you end up over-running primitive bounds and suddenly your results are weird “what is with the negative numbers?”.

I was talking with someone whose “users” are uber-intense actuaries.

They need to be able to write quick reports, and change functionality on the fly.

Rather than using full on Java, they interfaced via a scripting language, to give them concise scripts versus the verbosity that we know and love from Java :)

JavaScript was one choice, but they quickly ran into problems with double/float/int/BigDecimal, and they had to manually do a lot of work with BigDeminal objects and methods.

Then along came Groovy, which automatically groks the fact that it should take care of autogrowing the world.

E.g.

def x = 10;

println x.class;

(1.0..100.0).step(20) { y ->
println x;

x = x * y;
}

println x.class;

Output

class java.lang.Integer
10
10.0
210.00
8610.000
525210.0000
class java.math.BigDecimal

Note the auto change, and how operators such as * / – + all JUST WORK.

Native XML support in Dolphin

dion — Sun, 17 Jul 2005 17:49:45 +0000

Kirill Grouchnikov’s discusses thoughts on native XML support in Dolphin. There are definitely some interesting items, but I really hope that Sun takes a LONG look at what comes from C# 3.0 (send someone to PDC guys!), and look at the current E4X. It was BEA after all that came up with E4X!

Even look at Groovy’s XML builders and parsing w/ GPath.

I just want to be able to work with XML in a trivial way, instead of with the ugly mess of DOM/SAX/X APIs.

I like having a smart for() loop for XML, that is good….. but some of the “extends” stuff just looks more complicated than it needs to be.

More Rails / Java Talk

dion — Fri, 15 Jul 2005 07:50:36 +0000

Wow it keeps on coming (and ironically I am adding to it). This last slew of postings on Rails vs. Java came after Patrick Peak Rails: Where are the Implications for “No Deploying”?.

As soon as that came out we saw:

Dave Thomas: Rails and FUD
DHH: Letting cooler minds prevail
Jamis Buck: Application Deployment with Rails
James Duncan Davidson: Rails: Sandbox, Develop, and Deploy
Patrick Lightbody: It’s the tools, stupid!

The funny thing is that it is hard to know what we are really arguing about :)

Scalability

Can Rails scale? Sure. As Brian McCallister just said, scalability isn’t about a particular language.

Do the different languages/platforms give you different implementation choices for scaling? Sure. Scaling with FCGI clusters is different to using Tangosol Coherence in a J2EE cluster.

In some ways it is much simpler to scale a web app with shared nothing. However, on really huge enterprise systems (not web apps), tools *like* Coherence really help you out. It is nice to have the many levels and buttons available in your architecture.

Again, Slashdot? Scales like a champ with Perl. There are a lot of huge enterprise Java systems that take in billions of transactions.

So, conclusion? You can make both scale. You can make both run like a dog :)

Tools

Patrick has some good points in his post. I am not sure if he has checked out Textmate for doing Ruby development. It is quite nice indeed, although I do miss IDEA for some things (can’t beat its refactoring etc).

With Ruby you really don’t need as MUCH tooling though. It is a nice concise language which doesn’t need as much scaffolding in the tools area. You can be very productive with Ruby – IDEA.

However, IDEA really does do a good job of getting you closer to the productivity. I notice this a lot in Groovy world, and I am excited about GroovyJ.

Tool support is only one leg on the chair though. There are many other components that matter as much, more-so, and maybe not as much.

Refresh, Reload

Tools can help get around the dev cycle that we have in Java, but we aren’t there yet. Patrick is correct in spotting the potential with dynamic languages on the JVM, where we could get the best of both. But we aren’t quite there yet.

It is painful to jump to the Java world once you are used to hitting SAVE and refresh for every type of change (we can get far w/ JSP, etc etc).

Both are beautiful, both can be ugly

I love both platforms in many ways. I don’t like both platforms in others.

Java Dion: I wish we had the Ruby language on the JVM.
Ruby Dion: I wish Ruby had a nice VM to run on (the JVM would be really nice).

Or maybe I will just do everything in JavaScript 2.0? ;)

Oh, and David Geary had too much caffeine at the Rails Cafe? :)

Grails: Groovy on Rails

dion — Mon, 04 Jul 2005 07:25:05 +0000

It was bound to happen. The Groovy folk have seen the boon from Ruby on Rails, and want to get in on some of that action :)

A discussion of Grails (Groovy on Rails) sparked up on the mailing list, and miracles happen… code has come out of it.

Steven Devijver put together the first 0.0001 release of this code:

A first version of Grails is available in CVS. It’s located under groovy/modules/grails. Currently simple controllers are implemented together with JSP support. The MVC part is based on Spring MVC.

Build the project via “ant jar”

To start your own project with Grails set the GRAILS_HOME environment variable. Next create a directory for your project and from within this directory run this command:

ant -f ${GRAILS_HOME}/src/grails/build.xml -Dbasedir=`pwd` init

to initialize the project directory structure.

Place your controllers under the grails-app directory and your JSP’s under the jsp directory. A simple controller in Grails looks like
this:

class NamesController {
@Property String namesView = “names”
@Property Closure names = {
request, response ->

return [ "names" : [ "John", "Jill", "Jack", "Jaqueline" ] ]
}
}

Then make sure to create a view.

To create a WAR for deployment run this command:

ant -f ${GRAILS_HOME}/src/grails/build.xml -Dbasedir=`pwd` war

This will create a war names grails-app.war.

When the WAR is deployed access it through this URI:

/grails-app/app/names

Obviously, this is insanely early days. It is so interesting to see how people are revisiting their way of dealing with web applications after Rails.

Gravy: Using Ant from Groovy for short non-build scripts

dion — Wed, 22 Jun 2005 19:52:50 +0000

I recently had to whip out a one/few-off script that took a directory, and recursively grabbed jar files from it, and put all of the classes in one place. I looked at JarJar and Uberjar, but in the end it was easier to whip together a few lines of Groovy to make it happen (although I could have used Ruby, JavaScript/Rhino, Perl, etc etc).

When it came to jar’ing and unjaring files, instead of using the Java APIs, it was easier to just use ant via the AntBuilder. This allowed me in one simple line to use the tasks available there:

ant.unjar(src: file.path, dest: structure[typeOfJar].outputDir)

Very convenient. This isn’t using Ant in a more formal “I am driving the build from Groovy” way, but rather being pragmatic and thinking “oh there is a simple ant task that already does this, so lets just call into it”.

Example

def buildJar(String typeOfJar) {
println "Building a jar file for the type: $typeOfJar"
new java.io.File(structure[typeOfJar].dir).eachFileRecurse { file ->
try {
//println file.path
if (file.path =~ "\\.jar") {
println "jar xf $file.path $structure[typeOfJar].outputDir";
ant.unjar(src: file.path, dest: structure[typeOfJar].outputDir)
}
} catch (Exception e) {
println e
}
}

ant.jar(destfile: structure[typeOfJar].jar, basedir: structure[typeOfJar].outputDir)
ant.delete(dir: structure[typeOfJar].outputDir)
}

Groovy Strachan Song

dion — Mon, 16 May 2005 04:18:58 +0000

Stephan Janssen of JavaPolis and BeJUG fame, sent over a mixed song, based on James Strachan quotes from the presentation on Groovy that we both gave to the euro crowd in Belgium (which was a really lovely time).

I have put the groovy song up here.

Quality :)