Sunday, April 5, 2009

Succinctly Groovy

I was reading a post on displaying Google Visualization charts in Grails on mrhaki's blog and noticed something interesting. In his code, mrhaki wanted to get a handle on the newest (most recently modified) file in a directory. His approach was to list the files in the directory, sort them (in ascending order), reverse that, and then get the zeroth item:
def xmlFile = dir.listFiles().sort{ file -> file.lastModified() }.reverse()[0]
It's a nice example of how you can express a somewhat complex flow in a single line of Groovy. Still, it seemed like overkill to me and another reader who failed to identify him or herself. That reader linked to the Groovy Collections page and suggested using a Comparator that sorted the list in descending order to start with, but didn't include a code snippet. I liked the fact that this approach avoids the extra work to reverse the sorted list, but I wasn't sure it would be possible to express it so compactly and it still seemed more complicated than necessary. I looked over the Collections page and was reminded of the min(Closure) and max(Closure) methods available on Groovy's enhanced collections. So, rather than sorting the list of files, you can just ask for the max as determined by last modified date:
def xmlFile = dir.listFiles().max{ it.lastModified() }
Nice and simple, eh? Ignoring the overhead of imports and class/method declaration, neither of which are necessary with the Groovy snippet, here's the most compact way I know of expressing this using the Java standard libraries:
File xmlFile = Collections.max(Arrays.asList(dir.listFiles()), new Comparator<File>() {
  public int compare(File file1, File file2) {
    return (int)(file1.lastModified() - file2.lastModified());
  }
});
I'm glad Groovy's out there!

Saturday, March 14, 2009

A Teeny Tiny Bit of Fame

When I noticed I was credited for a fix on the changelog page for Tomcat 5.5.27 (search for "Passell" on the page if you don't believe me!), it made me feel a bit giddy. Does that make me a total dork? Well, I've been using Tomcat since it emerged out of the Apache JServ project many years back, so it makes me proud to think that I've helped make it better, even if just a little bit.
 
Update: my fix was incorporated into Tomcat 6.0.20 as well.

Why Twitter?

I'm not a technophobe. I don't blog as often as I mean to, but when I do, I enjoy it. I use IM on a regular basis. So, why do I have no interest in using Twitter? What do others see in it that I don't? Anybody out there reading this who can explain it to me?

Update: I have similar feelings about Google Buzz – I believe I have a good understanding of how it works, but I don't understand its value.

Friday, March 13, 2009

Amazon EC2 Reserved Instances

There have been some exciting developments recently in the world of Amazon EC2. For a long while, they've had compelling offerings for batch-oriented services and ones requiring dynamic scaling, but weren't as strong from a pricing perspective for interactive services with fairly steady demands. Well, that's no longer the case. Amazon just announced the introduction of "reserved instances" on EC2, which are different from regular ones in two primary ways. Reserved instances are guaranteed to be available when you ask to activate them and their pricing structure involves an up-front fee in return for a lower hourly operating cost. The availability guarantees are certainly an interesting development, but I'm not going to discuss those here. What currently excites me are the pricing options and what they mean for some architectures and demand patterns.

Others have already done the math comparing Amazon's reserved instance pricing with other hosting options and with standard EC2 on-demand pricing, but I've haven't seen anyone pointing out where the break-even point lies for a reserved instance versus an on-demand one. For example, a small instance costs 10 cents/hour on-demand and $325 (1 year plan) or $500 (3 year plan) and 3 cents/hour reserved. You'll only need to use a reserved instance for 4643 hours on a 1 year plan or 7143 hours on a 3 year plan before the reserved instance starts being cheaper per hour on average than an on-demand one. I've based this on the following equation: .1 * hours = upFrontCost + .03 * hours. For a 1 year plan, that works out to be 193.5 days/year, 16.1 days/month, or 53% of the time. For a 3 year plan, it's 2381 hours/year, 99.2 days/year, 8.3 days/month, or 27.2% of the time. (I'm not factoring in the time value of money here [paying $325 or $500 up-front is not the same as being able to spread it out over 1 to 3 years]. I'll leave it to the reader to do that.)

What does this all mean? If your architecture or typical demand requires 3 instances be running all the time, but you want to be able to dynamically scale up your instance usage, you can reserve the 3 consistently required instances and use on-demand ones to handle spikes in demand. In fact, it might even be worth reserving more instances even if you expect (with higher than 53% confidence), but aren't sure, you'll need them.

Update: On August 20, Amazon announced lower pricing for reserved instances.  I'd redo the math above, but Thomas Brox Røst did a particularly nice job in a post on his blog, so I'll let that do the talking.

Tuesday, March 3, 2009

Grails Demo Webinar

I just found out yesterday that Graeme Rocher, SpringSource's Head of Grails Development, will be giving a Grails demo webinar on Thursday, March 19. It will consist of building a Twitter clone using Grails. I've seen similar demos at SpringOne 2008 and JavaOne and I'd highly recommend "attending" if you're interested in seeing what Grails can do.