Ryan Daigle rwdaigle

Though slightly more complex, using a CDN is the most performant option for serving static assets. See the [CDN asset host](cdn-asset-host-rails31) article for more details.

Ruby on Rails applications should use Rack::Cache to efficiently serve assets on the Cedar stack. Proper Rack::Cache usage improves response time, decreases load and is important when serving static assets through your application.

This article will summarize the concepts of caching assets using Rack::Cache and walk you through the appropriate configuration of a Rails 3.1 application and the asset pipeline.

Sample code for this article's [reference application](https://github.com/heroku/rack-cache-demo) is available on

This article includes contributions from [Lee Reilly](http://www.leereilly.net). Lee is a toolsmith and master pintsman hacking on [GitHub Enterprise](https://enterprise.github.com).

Static sites are sites that don't contain any dynamic server-side functionality or application logic. Examples include brochure sites made up completely of HTML and CSS or even interactive client-side games built in Flash that don't interact with a server component. Though these sites only require a web-server to deliver their content to users it's still useful to use a platform like Heroku to quickly provision and deploy to such infrastructure.

Using the Rack framework, static sites can be quickly deployed to Heroku.

Source for this article's sample application is [available on GitHub](https://github.com/leereilly/static-site-heroku-cedar-example) and can be seen running at [http://frozen-hollows-6619.herokuapp.com/](http://frozen-

I've spent some time working with the GitHub Gist API for the development of Gisted and have some thoughts on its usability. My workflow may be unique, but I suspect my needs are representative of more general purpose use-cases as well.

Gist updated_at

The gist.updated_at field is not updated when its child file objects are updated. This makes it very difficult to perform last-modified queries since all API calls are invoked at the gist level. Clients are required to fetch all gists to determine if there have been any updates since the last call, forcing a very inefficient workflow and burning through users' hourly request limits.

List filtering

It would be very helpful to have a set of adjectives to perform filtering against the Gist list call. Specifically an updated_since param would be helpful to only fetch Gists updated since the given timestamp.

The problem

When working with large, high volume, low latency systems, it is often the case that processing data sequentially becomes detrimental to the system's health. If we only allow 1 process to work on our data we run into several challenges:

Our process may fall behind resulting in a situation which it is impossible for our process to catch up.
Our singleton process could crash and leave our system in a degraded state.
The average latency of data processing could be dramatically affected by outlying cases.

For these reasons, we wish to design a system which allows N number of processes to work on a single data set. In order to arrive at a possible solution, let me outline some assumptions of the system.

Preventatives:

Publishing friction: Have something to share but have to get approval first, or go through editorial process. Anything that puts time between thought inception and publishing is detrimental. Personal blogs/Tumblr excel at this, highly edited sites do not.
High effort: Longer-form, high quality writing takes a lot of effort. When writing is a side-project or labor of love it's tough to justify high-cost.
Expectation: If I write something, will people expect me to write again? I'm not sure it's an expectation/pressure I want to create for myself. Personal blogs can create this sense of expectation whereas community sites don't.
Channel mis-match: This thing I want to talk about isn't right for channel X (where X is a personal blog, company blog, etc…). Could be because of the topic, scope or medium.
Lack of topic confidence: I'm not confident my ideas are worthy or not. What if I'm wrong? Afraid to expose myself to public shaming.

Motivators:

	if(Rails.env.production?)
	ActionMailer::Base.smtp_settings = {
	:address => 'smtp.sendgrid.net',
	:port => '587',
	:authentication => :plain,
	:user_name => ENV['SENDGRID_USERNAME'],
	:password => ENV['SENDGRID_PASSWORD'],
	:domain => 'heroku.com'
	}
	ActionMailer::Base.delivery_method = :smtp

	#
	# This file configures the New Relic Agent. New Relic monitors
	# Ruby, Java, .NET, PHP, and Python applications with deep visibility and low overhead.
	# For more information, visit www.newrelic.com.
	#
	# Generated June 03, 2013
	#
	# This configuration file is custom generated for Barsoom

	body {

	width: 800px;
	margin-right: auto;
	margin-left: auto;

	font-family: Helvetica, arial, sans-serif;
	font-size: 14px;
	line-height: 1.6;
	padding-top: 10px;

	/*
	This document has been created with Marked.app <http://markedapp.com>, Copyright 2011 Brett Terpstra
	Please leave this notice in place, along with any additional credits below.
	---------------------------------------------------------------
	Title: Swiss
	Author: Brett Terpstra
	Description: Clean, Swiss typography with no frills.
	*/
	body{-webkit-font-smoothing:antialiased;font:normal .8764em/1.5em Arial,Verdana,sans-serif;margin:0;margin-left:auto;margin-right:auto;width:500}html>body{font-size:13px}li{font-size:110%}li li{font-size:100%}li p{font-size:100%;margin:.5em 0}h1{color:#000;font-size:2.2857em;line-height:.6563em;margin:.6563em 0}h2{color:#111;font-size:1.7143em;line-height:.875em;margin:.875em 0}h3{color:#111;font-size:1.5em;line-height:1em;margin:1em 0}h4{color:#111;font-size:1.2857em;line-height:1.1667em;margin:1.1667em 0}h5{color:#111;font-size:1.15em;line-height:1.3em;margin:1.3em 0}h6{font-size:1em;line-height:1.5em;margin:1.5em 0}body,p,td,div{color:#111;font-family:"Helve