• Terms (Shelley Powers) – comments on the very important issue of the terms and conditions attached to usage of the OpenSocial APIs – I had completely overlooked this. T&C are normally attached to proprietary products, not open standards. So it looks like we are really looking at Google APIs, not open standards here.
• Where the hell is the Container API? (Russell Beattie). Short, to the point, and bang on the money. I’m not in a rush so I’m happy to wait for important web API specifications to be drafted, discussed, refined, voted upon and published via a credible authority. But the OpenSocial development process is not open (a newsgroup of pleading users does not make it so).
• Google OpenSocial: Technical Overview and Critique – Dare Obasanjo. Too much to summarize here, go read it.

All in all I’m beginning to think the use of the term Open in OpenSocial is terribly misleading marketing speak. I’d like to think this is an accident (after all Google care about the continued growth of an open internet right?) but there is such a monstrous gap in the process behind and the function of OpenSocial and how other open APIs and standards are developed that I can only assume that this is all a marketing exercise to misdirect attention away from Facebook at the cost of ushering out a half-baked alternative. The Campfire One video only re-enforces this – it is incredibly corny and lacking in substance!

APIs and standards are sometimes hacked together by partnerships in order to try address immediate market share concerns – this is beginning to look like yet another of these efforts. Hopefully I’ll be proven wrong when the Container API documentation is published but I’m not holding my breath…

Deployment and Continuous Integration from the Trenches, (Fernand Galiana – LiquidRail)

• All about latest developments for Capistrano 2.0 – it seems to have matured considerably in recent months.
• Use multistage_ext
• Use shared project capfiles to keep things DRY
• Use remote repository cache to speed up deployments
• Read Jamis Buck’s blog and the Capistrano Google Group

Really Scaling Rails, (Britt Selvitelle – Twitter)
I’ve seen presentations on Twitter scalability, and even since then they have had a few more high profile outages (at least high profile amongst Twitter users). A couple of interesting takes from this talk:

• Twitter uses Apache, mod_proxy_blancer and mongrel servers
• All user traffic is handled by a single MySQL server. That server does have a slave that can be promoted to master (for redundancy). They have a couple of other MySQL databases for use internally for reporting etc.
• They set mongrel’s num_procs to 1. This means that each mongrel server instance will not queue requests from mod_proxy_balancer – they will only accept one at a time. The side effect is if the concurrent request count > mongrel server count then users start getting error pages. Strangely, they’d rather users got errors than risking loosing queued requests whenever they have to restart a mongrel instance (mongrel apparently waits only 60s before sending itself a TERM signal when shutting down).

Rails Full Text Search with Ferret

A little different to what I was expecting, Ferret provides an indexing service for arbitrary strings (documents), similar to Apache Lucene in many respects.  Worth a look, if you need to support full text search within your rails application.

Tabnav: Do We Really Need a Plugin for Tabbed Navigation? (Paola Dona – Seesaw)

The title of this one was a a bit modest as Paola presented a slew of new Rails Widgets that SeeSaw have developed, all of which seem to be very flexible. Widgets for include tabbed nav (or course), site nav, tables (blocks), nubbins, show/hide blocks, help popups were all demoed. Their widgets integrate very nicely into the rails views/templates – all in all, it looks at least good enough for use in creating rails app prototypes and it appears they might be flexible enough to be embedded into a production application…
The Rest of REST (Roy T. Fielding) – slides

Good historical view of where Roy came from and how the principles of REST have always been such an important underpinning of the IETF’s thinking behind standardization of key web specifications like HTTP, URI and HTML. He provided a good overview of how the web architectural style is defined as a set of constraints:

• client server
• stateless
• caching
• uniform interface
• layered systems
• code-on-demand

There was some interesting discussion on what is missing from Rails though Roy’s first two suggestions drew comments that he might have missed features in Rails that do what he wanted.  His last suggestion, for Rails to guide the developer into using hypertext as the engine for of application state (man they really have to find a shorter name for that!) was a fair comment – seems like an incredibly difficult problem to solve in a generic framework like Rails but as he said, it’d be a first…
Last talk was Craig McClanahan finishing off the day with a short Rails and the Next Generation Web pitch.  Now I hadn’t realised Craig had switched from Java to Ruby development and he seems to be loving it.  Craigs name has all over the Apache code I’ve worked with for years now – he was one of the original Tomcat Catalina & Struts developers and he also co-authored the Servlet and JSF specifications.  He had an interesting anecdote about how the Struts developers all suddenly found themselves working on non-struts based projects…