crickets in peril

We’re targeting amazon’s amazing ec2 service to host our alpha. Computing in the cloud is great for us — no installation/maintenance hassles, elastic expansibility as we need to scale, ability to create peripheral instances (such as staging) on the fly and turn them off when we’re done.

However, I was a bit worried about how the slim machine profile (1.7 G RAM, single processor) would fare for database and solr work. Fortunately, I just discovered that they’ve released new machine profiles with higher RAM, more processor cores, and more, faster storage. Rad. These folks know what’s up, and make it ever easier to run a startup.

Now I just need a solid memcached/web server machine profile (low CPU, high RAM, low storage) that shoots the gap between the small (0.10/hr) and the medium (0.40/hr). Something like 2 cores and 4-8 GB of RAM would be nice. Wonder how long it is before these specs themselves become configurable?

If you want to add search to your site, I highly recommend solr, a search server that builds on the lucene java information retrieval library. It does many powerful things out of the box–faceted search, highlighting, caching, etc–and the community around it is stellar. Plus it plays nice with ruby and python, giving you eval-ready output formats for both languages.

Over at the Rooftop Collective I’ve been hacking together some fun stuff on top it, adding local search and social search to the mix. After working w/ the code for a while, a couple things I really like about solr:

• dynamic fields: This is sweet. You specify a wildcard pattern (say ‘*_f ‘), associate a type with it (say, float) and then can define a new field on the fly as you’re indexing a document (say, my_field_f). This is far more flexibility than I’ve ever seen a database provide, particularly at runtime. In practice, it lets you describe and search your data in ways that evolve as the application runs.
• function queries: functional programming sneaks into Java.  You can create and compose arbitrary functions that run on your data set, mainly for sorting, but also for displaying calculations (like distance from a point).

Messing w/ solr also reminded me that I still don’t like hacking Java. Don’t like the verbosity. Don’t need the type safety–I can think clearly and write unit tests instead, thanks. Also, miss the built-in looping constructs from ruby. Also, miss the built-in fixtures from Rails. Don’t, however, miss the under-documented APIs from Ruby or Rails. Though it’s always fun to skim through random blog posts to figure out just what frob.foo() is really up to, why my computer spits fire when I call it, etc.