Last weekend I was lucky enough to attend RailsConf in Portland OR. For the unfortunate who weren’t able to attend, it was a 1600 nerds attending dozens of seminars on the latest and greatest technologies and techniques for working with Rails. Some of the stuff was really niche and I didn’t really feel like it applied.

I hope amazon paid an ton for the 3+ sessions that where devoted to S3 and EC2. I know this is new exciting technology, but it seems like it only applies to the thoroughly scaled application and not so much for the lowly startup.

I learned a lot about different testing methodologies and got a good dose of REST, these are two things I will soon be focusing my development on, so I was excited to learn more about them from the proverbial horses mouth.

I have the best of intentions of writing an article about each of the sessions I attended, but it might take me a while to get it all written and posted, so don’t hold your breath.

In the mean time:

Conference Slides
Official Conference Website

The wiki is probably most pertinent for those who want to know what actually happened, not just what was expected.

To make short 45 minutes of frustration… Yes it is possible to fragment cache your rjs data. The only difficulty is that you can’t do it within RJS.

If you can’t bring a horse to water you bring water to the horse.

So at this point I toyed with the idea of renderng rjs templates *within* rhtml templates. The first barrier to entry is the return type, but you can fix that by changing the header in your controller, before you render:

@headers["Content-Type"] = 'text/javascript'
render :action=>"index_render_rjs", :layout=>false

By rendering an rhtml template this gives you the ability to cache inline. I tried a couple theories on how to render rjs in my rhtml template and the following worked for me:

<% cache("token") do -%>
<% prepare_data() %>
<%= render :update do |page|
page.call("Something")
page.visual_effect :appear, 'a_field'
end%>
<%end%>


This put together works pretty well.

The only reason to do this is if you push your sql calls into the cached section of the page so that they aren’t executed when the page is cached. This is breaking with MVC and a memcache solution is probably semantically superior, but this works too and makes the whole process a lot faster.