bashcoder's Profile

Cool - about three weeks after this Railscast Ryan did go into the Russian doll technique, but actually did DHH's post one better. DHH outlines a manual versioning system for fragment content, since fragments can change without updating the models referenced within. As Ryan points out, that can get tricky.

In his Cache Digests Railscast, Ryan outlines how to hash and cache the full contents of a block, including the template and model contents. This eliminates the need for manual cache versioning and resolves some of the gotchas of the previous technique.

Thanks very much for this, Ryan - great timing considering the recent release of Phusion's new premium Passenger Enterprise product, which also allows for rolling restarts. It's good to learn that zero-downtime updates are also doable with 100% open source tools via Unicorn, albeit with increased memory requirements during restart.

Also thanks for including the bit about how to deploy a temporary site maintenance page - a very helpful tip!

Good stuff - I have the same question as this guy, regarding how to integrate ElasticSearch into a model that uses Globalize3.

Thanks for posting about this. Tried it out tonight - good stuff.

Looks like the client has decent caching, and co-processes that keep it up-to-date. Cool!

In Rails 3.1 there is a nicer way to handle conditional attr_accessible calls. See this blog entry.

The argument over Rails' default permissions for mass assignment was reignited after GitHub was hacked on March 4, 2012.

A Russian GitHub user, Egor Homakov, was arguing for more restrictive defaults, but he was rebuffed over a three day period. To make his point, he exploited this weakness on GitHub, where some model attributes were not protected in the code that handles public key submissions, in order to submit this commit to the rails master branch.

As a result, several commits were made to make whitelisting of model attributes the default behavior of rails generators. We will see if these modifications actually make it to the next release of Rails.

Here's how I did it for a blog project using Rails 3.2 and Redcarpet 2.1 (minus the syntax highlighting). Some of the configuration options have been moved into the HTML renderer, while the more generic ones are still at the markdown layer:

module ApplicationHelper 
  def markdown(text)
    markdown = Redcarpet::Markdown.new(Redcarpet::Render::HTML.new(
        :hard_wrap => true, :filter_html => true, :safe_links_only => true),
        :no_intraemphasis => true, :autolink => true)
    return markdown.render(text).html_safe
  end
end

I saw that - great read! Makes sense.

I think the main problem with this approach is that you have to load and use all the recent article models, even when you read from the cache.

If you already have the article models loaded just to build the name of the cache, you might as well just print the link_to entries and skip the cache altogether. I would think the main benefit of caching this section of the page would be to avoid the SQL call that loads the recent article models in the first place.

One interesting difference between rake and thor: If you have a compile error in just one of your rakefiles, "rake -T" doesn't work at all. But if you have a similar bug in a thor file, "thor list" will still display valid tasks from other files.