Friday, April 11, 2008

Getting out the Google App Engine Vote for Groovy

I might as well join in the fray of "getting out the vote" for Java/Groovy support in Google App Engine.

If you haven't heard, Google announced a new service: "Google App Engine". It's essentially a hosted application environment that roughly competes with Amazon's EC2 and S3 services. The initial release only supports applications written in Python. But Google has stated that they are looking into support for other languages.

So if you'd like to see Java/Groovy support in Google App Engine, you can vote for it by starring it here:
http://code.google.com/p/googleappengine/issues/list

Tuesday, April 8, 2008

Simple Java vs Groovy Perfomance Comparison

I recently read a post about doing comparisons with Groovy collections, and there was a snide comment that caught my eye:
Just write a simple helper. I guarantee that it will be 20 times faster than Groovy.
So I wrote some quick and dirty code to test exactly that. It's not scientific by any means, but my simple test showed that the Groovy version was about (edit: 7.5) times slower than the Java version.

That's still slow, but nowhere near as bad as the completely unsubstantiated claim of 20 times slower and not as bad as various other claims I've seen tossed around regarding the Java vs Groovy performance comparison.

And when you consider that Groovy is much younger than Java, that the JVM is only now starting to really get around to optimizations for languages other than Java, and that a main focus of the upcoming Groovy 1.6 release is performance improvements, that's really not bad at all.

For reference, here's the test code and the range of results for several runs. Again, it's a simple test and not scientific, but you can use it to get your own numbers. I'd love to see more people posting comparisons so that we can continue to make a factually based determination of where Groovy performance is slow.

Edit: I changed the Java version to a more compact form using Arrays.asList, increased the interations, and updated my performance numbers accordingly.

Groovy time: between 10781ms and 10688ms
Java time: between 1438ms and 1390ms
Java was roughly 7.5 times faster than Groovy (previous version was only 6 times faster)


GroovyListExamples.groovy:
-------------------------

class GroovyListExamples {

public List listSubtractionTest() {
def smallList = [1,3,5]
def bigList = [1,1,1,2,3,4,4,4,5,6,7,7,8,9]
def result = bigList - smallList
}
}

JavaListExamples.java:
---------------------

import java.util.*;

public class JavaListExamples {

public List listSubtractionTest() {
List smallList = Arrays.asList(new Object[] { 1, 3, 5});
List bigList = Arrays.asList(new Object[] { 1,1,1,2,3,4,4,4,5,6,7,7,8,9 });
return subtractList(bigList, smallList);
}

public List subtractList(List sourceList, List removeList) {
Set removeSet = new HashSet();
removeSet.addAll(removeList);

List result = new ArrayList();
for (Object item : sourceList) {
if (!removeSet.contains(item)) {
result.add(item);
}
}
return result;
}
}

ListExamplesDriver.java:
-----------------------


public class ListExamplesDriver {
public static void main(String[] args) {
GroovyListExamples groovyWay = new GroovyListExamples();
JavaListExamples javaWay = new JavaListExamples();

System.out.println("GROOVY:");
System.out.println(groovyWay.listSubtractionTest());

System.out.println("JAVA:");
System.out.println(javaWay.listSubtractionTest());

int NUMITERS = 1000000;
long start, stop;

start = System.currentTimeMillis();
for (int i = 0; i < NUMITERS; i++) {
groovyWay.listSubtractionTest();
}
stop = System.currentTimeMillis();
System.out.println("GROOVY TIME: " + (stop - start) + "ms");

start = System.currentTimeMillis();
for (int i = 0; i < NUMITERS; i++) {
javaWay.listSubtractionTest();
}
stop = System.currentTimeMillis();
System.out.println("JAVA TIME: " + (stop - start) + "ms");
}
}

HTTP Traffic Monitoring and more with Charles

Just stumbled across this post discussing monitoring network traffic for Grails applications. It's not really Grails specific, but I was surprised that my favorite monitoring Swiss Army Knife, Charles, wasn't mentioned until the comments (though to be fair, it is a shareware product costing $50 after the trial).

If you haven't looked at Charles, and you do web development or testing, you should do so. It's basically a local proxy server that gives you a great set of tools for monitoring and manipulating how your applications communicate via HTTP (if you are behind another proxy server, no worries, Charles can delegate it's calls to that proxy server).

You can see the feature list here, but the highlights for me are request/response capturing (the core of the tool), bandwidth throttling (to test applications at various "internet" speeds), and new in the 3.2 release is breakpoint support. Breakpoints are AFAIK a unique feature to Charles and they allow you to "interactively change requests or responses as they pass through Charles".

I also use Charles for a non web development purpose on my laptop to simplify dealing with proxy settings. Basically, I point all applications on my machine to Charles (e.g. Firefox, IE, Eclipse, etc.) and then I just change Charles to enable/disable the use of an external proxy depending on where I'm connected.

Anyway, it's a very useful tool that is well worth checking out.

Sunday, March 23, 2008

Sequence diagrams without wasting time in Visio

Just stumbled across websequencediagrams.com which lets you create UML sequence diagrams online without having to fire up Visio or your UML editor of choice. Not only that, but you actually generate them from text (it always seems that I end up wasting time fighting tools for these diagrams).

For example, here's the diagram created by this text:

   User->A: DoWork
activate A
A->B: <>
activate B
B->C: DoWork

activate C
C-->B: WorkDone
destroy C
B-->A: RequestCreated
deactivate B

A->User: Done


Pretty nice, and well worth checking out, especially if all you want is a quick diagram without wasting a lot of time.

Saturday, March 22, 2008

Adventures in classpath scanning...

On a recent project I've run across a number of scenarios where I wanted to generically apply some logic across a large number of classes. Previously, I've done things like using Ant for this or used find and grep to create an input file with a list of matches and then writing code that read that file.

But what I really wanted was something much simpler that could easily be used in Java code without a lot of gymnastics. And Spring's ClassPathBeanDefinitionParser had almost everything I wanted, except that it was written specifically to generate Spring bean definitions and didn't expose the internal features that I wanted to use.

So I looked at the ClassPathBeanDefinitionParser source and wrote ClassPathScanner.java
(NOTE: It uses numerous Spring classes internally, so it requires Spring.)

It's a crude start, but the basic idea is there. And the results have been suprisingly easy to work with. For example, if you want to write a generic JUnit test that runs all of your tests:
public class AllTestsRecursively extends TestCase {
public static TestSuite suite() throws Exception {
TestSuite suite = new TestSuite();
ClassPathScanner scanner = new ClassPathScanner()
.basePackage(AllTestsRecursively.class.getPackage().getName())
.assignableFrom(TestCase.class)
.includeFilter(".*Test");
for (Class testClass : scanner.findClasses()) {
suite.addTestSuite(testClass);
}
return suite;
}
}
Not rocket science, but it makes it pretty easy to write a lot of generic code. For example, you could use it to write tests that assert characteristics that might otherwise require aspects to enforce.

Or you could use it to dynamically generate Spring beans in ways not directly supported by ClassPathBeanDefintionScanner (e.g. you could search all of your services and create CXF bean definitions for all services that have the @WebService annotation).

I was surprised that something like this hadn't already been implemented in one of the Apache commons projects (or maybe it has and I just couldn't find it). But it seems like something that could be genuinely useful in many different scenarios.

Tuesday, March 4, 2008

Struts 1 Plugin for Grails

This one is hitting all of the Grails lists, but it's worth repeating. A Struts 1 plugin for Grails was just released.

Not only can you use this plugin to migrate your legacy Struts 1.x application by copying your config xml files, java files, and jsps into a Grails app. But you can also have your struts 1 actions use GSPs for rendering or even write your controller login in Grails controllers.

This is a shining example of how Grails' (and Groovy's) peaceful co-existence with Java can pay huge dividends.

So if you're stuck with a Struts 1.x app and desperately seeking a way to modernize your architecture, check it out yesterday.

Saturday, March 1, 2008

Make sure you have GUTs

There was a pretty good article on InfoQ today titled: "Cockburn on Testing: Real Programmers have GUTs". Basically, it talks about how TDD is just one way to achieve the more important goal, which is Good Unit Tests, aka GUTs.

Alistair Cockburn continues to be one of my favorite of the "methodologists" in that he's one of the few to actually recognize and stress that people are first order components in software development. Because you can push process til the cows come home, and some processes certainly are better than others, but at the end of the day it's the people that make software development projects successful.

And he hits the nail on the head once again with his GUTs observation. People pushing things like TDD, CDD, etc often just come across as methodology bigots trying to push their latest process du jour onto people. And they are losing sight of the bigger picture.

But GUTs is something much easier to agree on. Because GUTs are a measurable artifacts (e.g. using coverage tools), not a process. And at the end of the day, it really doesn't matter if your wrote your tests first, wrote them last, wrote them on a plane, or wrote them on a train. What matters is that if you have them, you can measure them, and they provide tangible benefits.

So I hope that the GUTs term achieves mindshare. If it does, it will make it easier to advocate GUTs in whatever process your company uses in whatever way makes sense for that process without having to fight the uphill battle of advocating an entirely new process. Translation, less time dealing with politics and FUD and more time spent actually getting things done.

P.S. If you are struggling to find a way to emphasize the importance of tests, I highly recommend a tool that can generate a "treemap" showing your test coverage (e.g. Panopticode). Because it's an amazingly concise, visual way to convey coverage.All black is bad. All green is good. Put a picture in your project's weekly status report to convey where you're at.

Friday, February 29, 2008

Implementing LISP's ITERATE macro in Groovy

I've always been a big fan of posts like Why Ruby is an acceptable LISP and Paul' Graham's Revenge of the Nerds, even though I despise the syntax of LISP. I love that, aside from the requisite flame posts, these types of posts tend to stir up great efforts from skilled programmers to show the relative merits of their personal lingua franca.

I've worked with Java for well over 10 years now not because I felt it was the best language, but because I felt that combined with the JVM it offered the best compromise between language features, portability, vendor independence, library availability, and mainstream acceptance. And the emergence of Groovy and Grails on that platform has rejuvenated my confidence in the platform despite the crossfire from the likes of Ruby/Rails, Flex/Flash/Actionscript, C#/.NET, and others.

So with that in mind, I decided it might be fun to play around with the idea of implementing one of LISP's extremely powerful macros, ITERATE, in Groovy. If you haven't seen the ITERATE macro, it's well worth a look because it shows how LISP's macro facility can be used to elegantly implement many looping constructs that often require entirely new keywords and/or syntax in other languages. Here are some simple examples taken directly from the ITERATE manual:

Example: collect the numbers from 1 to 10 into a list, and returns the list
  (iter (for i from 1 to 10)
(collect i)) => (1 2 3 4 5 6 7 8 9 10)
Example: collect all the odd numbers in a list
  (iter (for el in list)
(if (and (numberp el) (oddp el))
(collect el)))
Example: take the keys of an alist and returns a new alist associating the keys with their positions in the original list
  (iter (for (key . item) in alist)
(for i from 0)
(declare (fixnum i))
(collect (cons i key)))
And here's a contrived example from one of the blog posts above attempting to show some of the macro's capability:
  (iter (for x in '(1 2 3 -4 -10 -43 49 49 8934))
(until (= (sqrt 7) x))
(collect x into collection)
(finding x maximizing (abs x) into y)
(finally (return (list collection y))))
;; ((1 2 3 -4 -10 -43) -43)
So with that in mind, I've started prototyping what it might look like in Groovy, whether it can truly be implemented, and whether it's even needed (e.g. the simplest example above is built directly into the Groovy language as 1..10). And I'll be posting results here as I go.