Compulsivo

How to Set an Expires Header in Apache

Setting an Expires (or Cache-Control) header in Apache will help speed up your Web site.  We’re running Apache 2.x, and define an expires header for all of our static assets (images, stylesheets, and scripts).

Just add the following to your <VirtualHost> section of your Apache configuration:

ExpiresActive On
ExpiresByType image/png “now plus 365 days”
ExpiresByType image/jpeg “now plus 365 days”
ExpiresByType image/gif “now plus 365 days”
ExpiresByType application/javascript “now plus 365 days”
ExpiresByType application/x-javascript “now plus 365 days”
ExpiresByType text/javascript “now plus 365 days”
ExpiresByType text/css “now plus 365 days”

You can read all about expires headers by reading Yahoo!’s Best Practices for Speeding Up Your Website guide.

Also, be sure to check out our post on how to speed up your Website by Configuring Apache to Gzip Your Components.

How to Configure Apache to Gzip Your Components

Compressing your Web components will help speed up your Website.  The majority of your visitors will benefit as most all Web browsers support gzip compression.  You’ll want to compress all text, which includes html, css, javascript, xml, json, etc.

Apache 2.x uses mod_deflate, and all you need to do is add the following to your <VirtualHost> section of your Apache configuration:

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

All you truly need is the first line.  The BrowserMatch lines are there to handle issues with old browsers.

You can read all about gzipping by reading Yahoo!’s Best Practices for Speeding Up Your Website guide.

Also, be sure to check out our post on How to Set an Expires Header in Apache, which will also help speed up your Website.

Announcing Major Enhancements for Prefinery

Some major enhancements are coming to Prefinery on December 10, 2008.  Here’s the complete run-down:

Personalized subdomains

Every company account gets a free, personalized subdomain.  In addition to giving you the opportunity to add a bit of branding to the URL, you will now log in to administer your betas using this new subdomain.  For example, if your subdomain is “adobe” you will now log in at http://adobe.prefinery.com/admin

Separate administrator and tester areas

As an administrator of a beta program, you will log into Prefinery using your personalized subdomain (e.g., http://adobe.prefinery.com/admin) and will interact with a management console.  Testers will access your beta at a separate location and view a unique set of pages that you have customized.

Complete user interface redesign

The first thing you’ll notice when you log in is that Prefinery has received a major facelift.  We’re not talking a nip here and a tuck there.  We mean Prefinery fled to a country without extradition and got a brand new identity.

Landing / Welcome page

Create a custom landing page for your testers using our easy to use Web page editor.  You don’t need to know any HTML to create a beautiful welcome page.  We’ll add generic log in and join links to the page, but the rest of the content is up to you.

Improved custom branding

When you subscribe to a plan with custom branding, you’ll be getting a blank slate.  You’ll have complete control over the content and styling of the page so that you may provide your testers with a familiar experience.  In fact, once you add your logo to the page, testers may not even realize they’re not on your site.

Guestbook creation

Specify what contact information is required to be gathered from testers when they join your beta.  Pick from email address, name, address, employer, job title, and telephone.

Require a survey to join

Require testers to take one of your surveys prior to joining your beta.  Perfect if you want to collect more information than the guestbook supports.  Also a great way to attach a sign up application to your beta.

Require a survey to download files

Require testers to take one of your surveys prior to downloading a specific file.  Perhaps anyone can download version 1.0, but you want to require the survey “1.0 Feedback” prior to downloading version 2.0.

Sexy survey results

We’re using a whole new package for our graphs and charts.  They’re faster, interactive, and look great when sporting your data.

Bugs, comments consolidated

We’ve combined bugs and comments.  Prefinery is not competing in the bug tracking and ticket management space.  Plenty of excellent tools already exist.  So, we’ve merged bugs and comments since both are nothing more than tester feedback.  You’ll still be able to export the data.

Plus, dozens of tiny improvements

We hope you enjoy these additions and enhancements.  We’d love to hear your feedback!

Calling Rails Render Partial in a Model or Background Task

Why?

You want to store raw HTML in the database for a given model and you want to do this with the ease of partials and not a bunch of nasty string manipulation.

Rails makes this difficult for you by not giving you access to the render method when not called from ActionController.  However, you’d like to call the partial helper from within a model, or a background task (such as BackgrounDRb or Starling).

How?

As an example, let’s say you have a Page model made up of a title and a body.  You’d like to cache what a rendered page would look like in the model as the attribute cached_content.

The old way.  This really sucks.

class Page < ActiveRecord::Base

  def write_cache
    the_content = "<div class='title'>"
    the_content += "<h1>#{self.title}</h1>"
    the_content += "</div>"
    the_content += "<div class='body'>"
    the_content += "#{self.body}"
    the_content += "</div>"

    self.cached_content = the_content
    self.save
  end

end

The new way.  This is so much easier and cleaner.

class Page < ActiveRecord::Base

  def write_cache
    self.cached_content = ActionView::Base.new(Rails::Configuration.new.view_path).render(:partial => "pages/show", :locals => {:page => self})
    self.save
  end

end

app/views/pages/_show.html.erb

<div class="title">
  <h1>
    <%= page.title %>
  </h1>
</div>

<div class="body">
  <%= page.body %>
</div>

Pilot your Project with Cockpit

This past weekend we competed in RailsRumble 2008 - a 48-hour Ruby on Rails programming competition where the goal is to produce a complete application in a weekend.  We partnered with Marcus Mateus of SimpliTex to create Cockpit.

We were tired of constantly logging in to various sites to see key data for the various projects we were working on. While RSS feeds can provide much of the data, digging through RSS feeds doesn’t provide you with a true executive level overview of your project. You really want to see only the most important, relevant, and timely data… and ideally act on it. Cockpit is our answer to this most annoying problem.

In the 48 hours we had for the competition we decided to focus on getting a simple proof of concept view of key data from just four widely used web services. Lots of other sites provide similarly useful data, and full interactivity would be great, but the clock was a tickin’, so we limited our scope to the following:

• Basecamp messages, todos and milestones
• Github source code commits
• Lighhouse bug tickets
• Hoptoad exceptions

We have high hopes that with the feedback that comes via the competition we will be able to create an application to help rescue all of us from project overload. Over the next 10 days, anyone can vote for Cockpit.  So far we’re off to a great start.  As of the first day we’re ranked #10 of 131 in the Usefulness category — in our opinion the only category that truly matters in the long run.

The competition was a blast, even if tiring. A great big thank you goes out to all the organizers, volunteers, and sponsors.

Note: Most of this article was authored by Marcus Mateus and was originally posted to the SimpliTex blog.