Atomic Object provides some fantastic benefits. For example, Atomic sends each developer to one conference each year. They pay the registration, air fare, and hotel. They also pay as if I had been actually working. It’s fantastic to have an employer that not only wants me to be a better developer, but takes the extra steps to help me improve.
This year, I attended the Google I/O conference in San Francisco. The first day’s keynote was essentially a bird’s eye view of the conference content. The overall theme was that Google wants to advance capabilities of web applications. They understand that their growth is tied to the growth of internet use at large. They understand that internet use will increase as web applications improve. They want to facilitate the improvement of web applications by providing tools for developers to use. As much as possible, these tools are open source, and not bound to Google, as that is the best way to empower the advancement of the internet.
From any other company, I would consider this pure rhetoric, but after those two days in San Francisco, I’m inclined to take Google at its word. All but one of the technologies I looked at is open source and/or an open standard. In addition, they have a financial interest in the continued improvement of internet applications.
OpenSocial is an open standard for integration of third-party social applications. As OpenSocial is an integration standard, it has two sides. Social networks (orkut, for example) act as OpenSocial containers, where their members can add third-party applications to their profile. Third-party developers provide OpenSocial applications which can then plug into an OpenSocial container. This allows, at least in theory, someone to create an application that can run on many different social networks without having to customize for each one. In reality, there will probably be some GUI customization required, and not all OpenSocial containers will allow all OpenSocial applications.
Google App Engine is a web framework designed to scale, hosted on Google’s server cloud. Google App Engine is the one technology covered that is not open source. This is forgivable since it’s specifically designed to run on Google’s server cloud. Since I don’t (yet) have a sophisticated cluster of thousands of servers with crazy infrastructure, I don’t begrudge them the closed source nature.
The intent of Google App Engine is to make it so any application using this framework will automatically scale. The free version allows up to five million page views per month, and the pay version, while not yet available, will be metered, and should, by Google’s estimates, be somewhere in the ballpark of forty dollars a month for 10 million page views per month. The datastore uses Bigtable, Google’s custom database.
Google App Engine provides (almost) guaranteed scalability! In theory, the framework does not allow any operation that is not scalable. In practice, no framework will overcome bad development practices, but this framework makes it a lot harder to screw it up.
The application gets free, high quality hosting running on Google’s server cloud. Up to 5 million page views per month are free.
The application gets convenient access to most Google APIs. It’s super easy to do logins using Google Accounts.
There is currently no support for schema migrations. There is no support for batch data operations. The application may not fetch more than 1000 records in a query. Requests are time-limited. This means I cannot rename a field after it has been deployed. To be fair, it is technically possible, but I would have to make one request for each 1000 records, which would be tedious and error-prone at best.
Bigtable does not yet back-fill default values into existing records when you add new fields to a type. For the old records, the field isn’t null, it’s just not there, and you cannot query for that condition. (Fields may have null values and be queried as such, but these “missing” fields will not match a query for null.) In a production environment, this can lead to vanishing data when querying based on such fields. Currently there is no mechanism (like migrations in Rails) to help you adjust your data.
BigTable does not support substring searches. String equality and begins-with style conditions are supported, but searching based on partial matches mid-string doesn’t work yet.
While Bigtable encourages you to create most objects with a parent object, you cannot move them to a different parent after the fact. The record would have to be deleted and recreated, which would also require updating every reference to that object.
There is hope however. App Engine is a beta product, and the presenter mentioned that they are prioritizing support for offline processing, like schema migrations, as well as full text search.
Google made a big deal about debranding Gears. It is now just Gears, rather than Google Gears. The rationale is that they don’t want corporate branding to hinder adoption. The purpose of Gears is to push browsers forward, not advance Google’s brand. They demoed some new features, that are currently only prototypes.
Gears will allow applications to upload multiple files with a smooth interface, using a multiple file selection box, instead of the current system of one input field per file. Progress information will also be available to the client. Uploads will also be resumable.
Google is putting a lot of effort into making it possible to do more powerful things with web applications. While I didn’t come away with anything that helps me today, I did come away with a new vision for the possibilities of the web, and some tools to achieve those possibilities.