Brasten, tumbling

Bowling: 2011-2012

Below are my 2011-2012 bowling season results. I’ve been trying to find some sort of useful pattern.

The first thing I see is that I seem to be two different bowlers in 2011 and 2012 — with a nearly 10-pin shift in average.

The other thing I see is a tendency to mix a couple very high point games into a handful of slightly sub-par games. This is a great way to maintain a high-ish average while losing a lot of games — which is exactly what happened.

Things I want from AWS (UPDATED)

A few simple things that Amazon AWS could offer that would make my life a looot easier.

1. SNS notifications triggered FROM an SQS queue

Many times I’d like to ensure that a message is reliably delivered to an HTTP endpoint. A great way to do this would be to feed an SNS topic from an SQS queue — where an error in sending the notification or an error code in response results in the SQS message remaining on the queue.

Note that the opposite is currently available — the SNS topic can post to an SQS queue. But I don’t see the benefit in this. What do you gain from posting to an SNS topic that drops the message off in an SQS queue over just posting directly to the queue itself?

2. Dynamic content origin servers for S3

Similar to CloudFront, I’d like a request for an S3 item to pull the item from a origin source if it doesn’t already exist ( PUTing it at that location on the way back ).

eg. an image thumbnail at a particular size could be generated IFF it’s requested … later requests serve it directly from S3.

3. S3 event notifications (provided by SNS?)

In many cases I’ve had to consider placing a custom service in front of S3 purely to track PUTs, GETs, etc, and trigger additional processing. If an S3 event dropped a message in an SNS topic … or better yet, an SQS queue backing an SNS topic … most of my reasons for building these services would be mitigated.

Any chance of getting these, Amazon?

UPDATE: Apparently AWS rolled out Delivery Policies for SNS the day I wrote this post. While it does not invalidate point #1, it does provide some of the functionality I was looking for.

You’ve got some ActiveRecord in your business model

Your business model is not the same thing as your data-access pattern.

(Unless your in the business of developing ORM frameworks, then maybe it is)

Unfortunately it seems like the “Rails way” of doing things has convinced a lot of otherwise-decent developers that their business model must ultimately be a subclass of ActiveRecord::Base — and all methods on those classes should mimic ActiveRecord operations. This results in methods that go to great lengths to tell me HOW they might fullfil my request, but often fail to describe what exactly they’re useful for.

Here’s an example from a project I’m working on now: 

Device.find_and_update_or_reassign_or_create( user, attributes )

There’s actually a lot of logic code in this method, and it turns out it is pretty core to our business logic. But what does it do? All I can tell you for sure is it will probably perform 2 or 3 DB operations … but when working with a business model, why do I care about that?

Device.provision( user, attributes )

Refactored! In the business domain of this application, I know exactly what it means to provision a device. I do not care (at this level) what DB operations are required to get that done (and they may very-well change over time).

Finally jumping on the Tumblr bandwagon.  Not sure why I didn’t do this sooner.