Spiral Arm Logo

Richard's technical notes

Wednesday, April 27, 2005

Amazon Simple Queue Service

Some months back I received email from Amazon announcing the beta launch of their queue service. I've just checked, and it's still in beta.

The idea is that you can create a queue on Amazon servers and then place messages in the queue and consume messages from the queue. Messaging has been around for quite a while, so what's interesting here? Well, what we have is a company that has invested in an impressive (I assume!) network and hardware infrastructure for the sale of books, and on the back of this they are offering a software service -- and now I get to piggy back on the level of service offered by their investment.

So let's say I, as a company, want to build some new service. Pretend I'm going to accept photographs from customers and turn them into something... print them or put a humorous frame around them.... whatever. I don't have to go out and spend money on a hardware platform to build this on. I can use Amazon's reliability and scalability to accept customer orders (messages going into the queue), and use whatever infrastructure I have to consume orders from the queue as and when I'm able to. I can offer 24x7, 99.999% uptime for customers without the level of investment that this usually implies. That's interesting.

As I said, it's in beta at the moment, so it's free. It's REST and SOAP based, it'll store up to 4,000 4k messages for 30 days, and there's a critique over at XML.com. I can't find any published SLAs or pricing, but presumably they will follow.

Amazon are not the only company with a hardware infrastructure to use in new ways. The obvious other examples are Yahoo! and Google. It'll be a good sign if any other players decide to offer up these kinds of services.

Update 14 July 2006: Amazon SQS has now gone into production, with a cost of "10 cents for a 1000 messages, and 20 cents per Gigabyte of data transferred". No up-front costs, minimum usage or subscription fees. This is astonishingly good, and one of the smartest offerings I've seen from any company.

by Richard @ 9:39 AM 0 comments

Wednesday, April 20, 2005

Change reporting

How to communicate code changes? I could send email, I could maybe read some of the reports from CruiseControl, or I could look at Fisheye (or an open source alternative, such as CvsChangeLogBuilder).

FishEye is nice, but I don't find the need for most of what it can do. What I do use is a text and RSS feed of CVS commit messages. Sure, FishEye does that, but as that's all I want I'll save my US$999 and use a Perl script called cvs2cl that does the job.

cvs co my-project
cd my-project
# Text version:
cvs2cl.pl  --stdout -l "-d>1 month ago" > $OUT/changelog.txt
# RSS version:
cvs2cl.pl  --xml --stdout -l "-d>1 month ago" > $OUT/changelog.xml
xsltproc  filter-cvs2cl.xslt $OUT/changelog.xml > $OUT/changelog.rss

Right now I have that running on the hour every hour, but it's probably not too hard to plug it into a build tool or even have it run after a CVS commit event.

by Richard @ 9:29 AM 0 comments

Wednesday, April 13, 2005

Sony Ericsson V800

V800 Mobile Phone

It's been a few months since I moved away from a P800 to a V800. I wanted a handset that had good enough PIM functions, that would sync with my Mac, had the usual range of bands for roaming, but compared to the P800 I wanted something I could use while walking (it turns out I can't use the P800's stylus and move at the same time).

The Register gave it a positive review, and I think it's fair. The battery life is a little suspect, it's a little larger than it should be, but what can you expect of an early generation 3G handset?

My biggest gripe is with the keypad: too many keys, and the space in the wrong place. I can only guess that putting the space over on the right under the 9 key is either for left-handed people or for two thumb texting. For texting with one hand, when you're right handed, it's a form of torture for your thumb. (The middle zero key is where the space should be).

I wouldn't have touched the handset if it didn't come with a generous selection of Java APIs: MIDP 2, CLDC 1.1, Nokia UI, WMA (JSR-120), MMAPI (JSR-135, for audio and video playback, and camera snapshot), JTWI R1 (JSR-185), KDWP, but not the bluetooth API (JSR-82). The applications we've written run fine on it, although I'll be re-reading the RMS spec because I've made some gross assumptions about record ordering in Punch.

The handset also supports SVG-T and Java 3D (JSR-184). As we've recently been working on some 3D data visualization, I'm looking forward to see what the mobile Java 3D can do.

I'm not yet convinced by the clam shell design. On all the previous phones I've owned, some part of the screen is always visible. That's great for spotting a missed call or message. To get round the lack of feedback, the V800 has a 2.2 inch TFT display in the lid of the phone. This works fine, but feels a bloated solution. There must be a simpler way.

by Richard @ 11:09 AM 0 comments

Thursday, April 07, 2005

Persistence options

When it comes to writing an application that uses a relational database (and that's pretty much all of them, for me), I like to use a tool that hides the details of the database I'm using, and reduces the tedium and error involved in mapping code to database structures. For me, that was JDO - a Java standard that has a great open source implementation in terms of Jpox.

The goal of picking a persistence framework is, amongst other things, to end up using one that isn't going to be obsolete. This is, of course, impossible. Sooner or later everything becomes obsolete. With JDO going into a version 2 specification process, having gained plenty of vendor and open source support, and also being well thought-out to start with, it looked like a good horse to back. But no.

Some consider there to be too many ways to do persistence in Java, and something had to give. Sun's Letter to the Java Technology Community makes it clear that JDO isn't the one to back. What we want, apparently, is a single persistence framework for both J2EE and J2SE. That's a good thing, but it's not ready yet.

The Thing That Replaces JDO is going to be specified as part of the EJB 3 process, so you can guess that EJB 3 is going to have a big influence on The Thing That Replaces JDO. I should make it clear that this doesn't technically kill JDO. The interview with the JDO spec lead, Craig Russell, shows that there's a commitment to support JDO and for vendors to help migrate us over to The Thing That Replaces JDO. But still, who's going to invest their time in using JDO when it's already flagged as obsolete?

While this plays out, then, it seems that the only good bet is going to be Hibernate. It's not based on a community specification, but it is open source, has lots of users, and has been around for quite a few years. It's the one I'll be using.

Paul's been using it for a while, and suggested I look at the Hibernate in Action book. There's also a long but useful presentation over at Javapolis. So far I'm impressed: it has that battle-hardened feel to it that gives you confidence that someone else has already suffered the pain in finding and fixing any nasty problems.

by Richard @ 2:52 PM 0 comments