Getting Heroku Cedar and Rails 3.1 Asset Pipeline to Play Nicely Together

I recently migrated a Ruby on Rails 3.1 app from the Heroku Bamboo stack to Heroku Cedar. If you’re doing the same, here are a few notes to help avoid snags on getting the Rails Asset Pipeline working efficiently.

Unlike Bamboo, Cedar does not offer Varnish as a reverse proxy cache, nor does it automatically gzip content. You need to do it yourself. Heroku recommends:

  1. Use memcached, with Dalli as the memcached client. Make sure to follow the Rails 3 section.
  2. Use Rack::Cache as a substitute for Varnish. Heroku links to this article which explains how to integrate Heroku with Rack::Cache. I couldn’t get it to work, so I hunted around and pieced together the folllowing riff.
In your runtime environment file (e.g. production.rb), add this:
require 'rack-cache'
My::Application.configure do
...
  # Enable Rack::Cache
  config.middleware.use Rack::Cache,
   :metastore => "memcached://#{ENV['MEMCACHE_SERVERS']}/meta",
   :entitystore => "memcached://#{ENV['MEMCACHE_SERVERS']}/body"

You can also set HTTP headers in production.rb as follows. (3600 is an example value, make this whatever you want.)

# Add HTTP headers to cache static assets for an hour
config.static_cache_control = "public, max-age=3600"

And you may want to add this to your config.ru to get gzip working:

use Rack::Deflater

References:

Pressly Makes Sense

Hey Jeff and Peter,

I just finished watching the videos of you launching Pressly at TechCrunch Disrupt. Well done. You and your team should be really proud of what you’ve achieved.

I wish you’d been given more opportunity to elaborate on your strategy to win. Instead you had to spend most of the Q&A time defending Pressly’s raison d’etre to Dustin Moskovitz et. al. That was unfortunate; deck stacked against you. But you did a nice job staying the high road and giving solid answers to the skeptical questions.

Jeff, I loved your comment about publishers being great at telling stories, and not so great at building technology innovations to deliver those stories (in compelling new ways, with compelling profitability). It’s true. And it’s good, I think, that Pressly is joining a cadre of other players in this same space. Existence of multiple players is proof that the market is ready. And publishers need lots of options right now, especially ones that let them do fast, cheap experiments. Pressly can help them do that.

I suppose controversy-seekers could frame this as “walled garden versus open web, round 2″. That was my very first thought after watching the video. But that isn’t really the case, is it? Neither the iPad/App Store ecosystem nor HTML is going away anytime soon. There will be multiple winners in this market, with multiple technology bets. Consumers will buy many different kinds of devices, and consume content in many different places and ways. It’s probably more accurate to compare Pressly’s space to the blogging services market back when it was just getting going: Blogger, WordPress, Movable Type, and so on. Lots of experimentation and diversity, with consolidation down the road.

My biggest takeaway on all this is that Pressly makes a lot of sense from a publisher’s point of view. Publishers are losing sleep over how to follow their audiences to digital devices without abandoning all the assets they hold dear: their brand, destination websites, exclusive content, and UX. And with limited capital and time/runway remaining for technology investment (or investment of any kind) they have to be brutally frugal and thoughtful about what bets they make. Pressly has good answers on the economics (very little cash up front), the technology (more open), the user experience (niiice), and control issues. Clearly The Economist and Toronto Star think so, and I bet many others will reach the same conclusion.

I hope Pressly does really well.

Let me know when I can buy some shares.

osh

How to query for count of Facebook Likes and Shares on a specific URL

If you have a site hosting the Facebook Like button you may at times want to query Facebook for the number of Likes displayed within the button. Here’s how.

I couldn’t find a way to do it with Facebook’s Graph API, but there’s good support for it in the FQL API. You can craft up queries by hand, as shown below, and issue them right from your web browser. The response is an XML document with the statistics for the URLs you want to know about. There are also FQL wrapper libraries in several languages… for Ruby I had some success with the fb_graph gem.

Multiple URLs example:

https://api.facebook.com/method/fql.query?query=select  url,like_count, total_count, share_count, click_count from link_stat where url in(“http://bing.com”, “http://google.com”, “http://facebook.com”, “http://twitter.com”)

Single URL example:

https://api.facebook.com/method/fql.query?query=select  url,like_count, total_count, share_count, click_count from link_stat where url = “http://bing.com”

Within the XML results, the “total_count” attribute is the number shown within the Facebook Like widget.

Docs:
http://developers.facebook.com/docs/reference/fql/link_stat/
http://developers.facebook.com/docs/reference/fql/

Follow

Get every new post delivered to your Inbox.

Join 401 other followers

%d bloggers like this: