I've been really getting into the mongodb document-oriented database recently.  For those of you yet to join the NoSQL party, mongodb is a fast, easy to use JSON-based document store.  For a nice, quick overview, check out this slideshow:

The mongodb command set isn't huge, but it's always useful to have a cheatsheet to hand when you're learning a new technology.  I found the one at http://cheat.errtheblog.com/s/mongo to be pretty good.  I thought about saving it to a text file for easy access when working in a terminal - then I noticed that the author has been refreshing the cheatsheet as mongodb matures and the command-set changes.  Now, an out-of-date cheat-sheet isn't much good, so I thought I'd knock together a quick shell script to deliver the latest version to my terminal.

The script is implemented using curl and a Groovy one-liner. The wonderful @Grab annotation is great for this kind of thing - I've built up a bunch of Perl one-liners like this over the years, but I'm starting to discover that Groovy trumps Perl for many little text-processing jobs like this.

Append this line to your .bashc script, then the next time you can't quite remember the syntax of a mongodb command, simply enter mongocheat | less

(Note: The first time you run this, it'll probably take a while, since Groovy may have to download the NekoHTML libraries.  Subsequent executions will be much faster!)

For the most part I love the expressiveness and conciseness of Groovy when compared to Java.  Most days I really enjoy writing Groovy code, and love the productivity boost that comes from not having to write and test so much boilerplatery.  However, other days Groovy can feel a little flaky, and I miss the predictability of good old Java.  More importantly, with Groovy you will occasionally come across some pretty obscure behaviour which leaves you scouring Nabble and JIRA for solutions.

Case in point: when new to Groovy, one of the first things you will learn is that while in Java the == operator test for object identity, in Groovy the same operator tests for object equality, using the equals() method of the object to the left of the operator. (In Groovy, object identity is tested using the is() method).  So far, so good.  However, what you might not learn is that if the object on the left of the == operator implements the Comparable interface, the == operator will test for equality by calling compareTo() == 0.

It's very easy to get tripped up by this, especially if you have overridden the equals() method:

The solution, in cases like these, is to either a) ensure that x.compareTo(y) returns 0 in all cases where x.equals(y) would return true (or vice-versa), or b) remember to use x.equals(y) instead of x == y, whenever the class of x implements Comparable.

Personally, I feel the principle of least surprise applies here, and the == operator should always call equals().  However, I'm aware that there are no doubt some cases (particularly where other comparisons such as <, >, <= and >= are being used) where the principle of least surprise would dictate that the current behaviour is preferable.

If you have strong arguments either way, I'd be interested to hear them in the comments.