RAG on Rails

Dopplr will calculate your carbon footprint

I’ve been using Dopplr for quite a while now and I just recently noticed a new tab they added to my profile page.

This new feature looks at your travel schedule retroactively and in to the future and estimates your carbon footprint.  I also noticed that when creating new trips you can select your method of travel (airplane, car, train).  I’m assuming this is to more accurately estimate your impact.  This is pretty neat since normally this type of information is pretty tricky to collect, especially when you are travelling frequently.

OpenSocial… 50% there

I’m starting to really see the gaps in OpenSocial.  That is, the difference between 0.5 and 1.0.  I think a lot of people are forgetting that this is not even a complete spec.  For example, as a OpenSocial application you need to have a notion of “streams”, which in turn have an idea of “folders” in which you create new actions.  The REST API makes no mention of this abstraction.  The purpose of these streams are pretty fuzzy too.

So, who is writing the last 0.5 of the API?  And when can we get the next piece?

Europe, meet Amazon S3

Amazon announced today that they are opening a new datacenter in Europe. This datacenter will be playing host to a new European S3. The goal of this move was to address the concerns that the AWS suite of services were not well suited for global users. S3 has been getting some negative reviews by many Europeans as idealistic and impractical with the primary justification being the terrible latency experienced from across the pond.

ELC uses the AWS toolset extensively. At RailsConf Europe I was very surprised to hear people’s apprehension with S3 and EC2. Many were convinced that S3 was doomed to fail in the web application space because of the poor performance outside of North America. It seems that Amazon was listening.

I was surprised, and frankly excited to see that they have explicitly differentiated the European S3 and the the American S3. Storage and request fees are slightly more expensive in Europe. This may be a reflection of the differing energy costs. Having separate EU and US storage facilities that can be managed by the developers themselves was a smart move on Amazon’s part. This gives application developers the opportunity to optimize the distribution of static content that may be location specific. It also leaves open the option of dynamically switching asset servers based on IP location. Exciting! If they do eventually try to unite the services I hope that they make multi-homed IPs a possibility with S3; then we’ll have a real CDN.

OpenSocial and Ruby

OpenSocial was released late in the evening on Thursday, November 1st with much fanfare. MySpace is now boasting an API, as does Orkutt, and LinkedIn among many others. This is great! Facebook has revolutionized social widgets with the release of their API. Its exciting to see the possibility of expanding the coverage of these widgets across all of the major (and minor) networks. ELC Technologies will be investing quite a bit of time towards developing a Ruby implementation of the OpenSocial set of standards. Expect a first draft of a gem and a Rails plugin by the end of the week.

Josh and I started working on the standard based on the documentation that Google released. They have 4 general APIs that they have pulled together under the OpenSocial banner. The JavaScript API specifies how to build widgets using the same constructs as used in Google Gadgets. The People and Friends data API describes methods for retrieving information about different user’s profile along with their friends information. The Activities data API supports reading and updating a users activities and reading their friend’s activities. The Persistence data API allows for the manipulation of key/value pairs on a OpenSocial compatible network.

New before_filter semantics

Something I posted on the ELC Tech Blog at: here 

It looks like Rails 2.0 will no longer pay attention to the return value of before_filters.  Currently, in our Pre-Rails 2.0 world, before_filters stop processing a request when they encounter a return value of false.  You may recognize the common pattern:

  redirect_to new_session_path && return false

Rails 2.0 won’t require a return value of false for a before_filter to stop the action, but will instead look to see if you called redirect_to or render.  If either of these functions are called the filter chain is halted.  This should clean up a lot of code and remove a lot of repetition.  At the end of the day your before filters look almost the same as they always have, just drop the && return false.