Archive for Web/Technical

The “February 25th Release” was very poorly named.

Well.  I made a personal deadline to roll out a new release of Hopville by February 25th, the site’s second birthday, but things have changed quite a bit since I was making any personal dealines.  First, I was unexpectedly asked to audition for a band.  I managed to pass, so now I’m practicing with and gigging with and learning dozens of new songs for a band…which is time-consuming.  Meanwhile, the job I started in February ended up having a pretty intensive, high-productivity work environment with long hours and very little wiggle room.  No complaints here – the new band and new job are great – but much of the free time I might’ve had over the last month and a half simply…vanished.

Thinks are calmer now as I settle into both new roles, and I continue to make progress on the site.  I’m now aiming to roll out the new stuff by the end of March. You can mark my words, or cross your fingers, or knock on wood – not really sure how to instruct you at this point.  But anyway…what is the new stuff?  I’ve boiled this release down to two major updates: better site navigation and improved Beer Calculus performance.


The performance improvements are what made this release a challenging one.  I rewrote all the front-end parts of Beer Calculus to make them easier to maintain and to improve the way the front-end communicates to the back-end.  Current users won’t be shocked by the changes, but their ongoing use of the site will be every-so-subtly more fun and rewarding.  Like buying a newer, noticeably-faster-at-first computer.  And on my end, the code is already cleaner and easier to manage, which means I hope to build new stuff at a faster pace than before.  I’m definitely looking forward to getting this release out the door – when a new launch (including lots of small UI improvements) is overdue by a whole month the existing site becomes quite an eyesore.


Since this blog post announces that there is nothing new to see, I figured I’d use this opportunity to describe those behind-the-scenes changes that nobody will notice or want to hear about on launch day anyway.  Here’s what I’ve been working on:

  • All Beer Calculus HTML will be rendered via HAML templates instead of ERB.  Net effect? The HTML will be more structurally and semantically sound, making the pages easier for browsers to render, easier for search engines to crawl, and easier for humans (especially me) to read.
  • Beer Calculus code goes RESTful.  Net effect?  Lighter pages and simpler, more AJAX-centric page requests result in a zippier interface that’s more responsive and fun to use.  Ever notice the the scary message your browser sends you every time you try a page reload on Beer Calculus?  Yeah…that won’t happen anymore.
  • JavaScript moves to the jQuery framework.  I came late to the jQuery party but there’s no stopping me now.  Net effect? Smoother and more responsive effects – web interfaces getting closer and closer to behaving as well as desktop software, without having to resort to Flash.  I still thought I’d have to resort to Flash (meaning, rewrite the calculator all over again in ActionScript) as of about six months ago, so it’s big news that JavaScript has matured to this inflection point.  Lots of cooler interface stuff to follow.

Current recipe count: 13,687


Comments (3)

automatic color palette for Rails

It’s difficult trying to standardize colors across a site. I picked up a tip somewhere to keep a legend at the top of a stylesheet, something like this;

F9F9FF off white
4a443c main text
B34700 link text
FF6600 action link text
eeeeee tiger body

Then you have an easy hex color reference right at the top of your main stylesheet. But “easy” becomes relative. On Hopville, I ended up describing shades of green as “medium”, “medium light”, “lightest”, and “extra-lightest”. Extra-lightest green? Which one was that again? And as the site’s color scheme has evolved, the legend has gotten out of date.  Some of the colors on the site aren’t in the legend any more, some of the colors in the legend aren’t in use anymore, and so on.
It just occurred to me that this could be automated, that I could scan all the stylesheets with a script, pull out the color attributes, and generate a color swatch page on the fly.  So when I want “that one shade of green”, I can go look it up and cut and paste the hex value, without having to dig through stylesheets or maintain a color palette legend.  Rails made it easy to generate it on the fly with an erb template (ignoring MVC for simplicity’s sake) and not even have to set up a cronjob.

Dynamic color palette browser created from stylesheets in Rails.

Dynamic color palette browser created from stylesheets in Rails.

The code:

stylesheet_dir = RAILS_ROOT + '/public/stylesheets'
files =
css_files = []
colors_in_stylesheets = {}

files.each do |file|
  if file.match(/\.css$/) + '/' + file).each do |line|
        if line.match(/\#([0-9a-f]{3,6})\;/i)
          unless colors_in_stylesheets[file]
            colors_in_stylesheets[file] = {}
          colors_in_stylesheets[file][$1.downcase] = 1

block_size = 100

<style type="text/css"> {
  width:<%= block_size %>px;
  height:<%= block_size %>px;
  border:1px dotted #ccc;
} span {
  border:1px dotted #ccc;
h2 { clear:left; }

<h1>Color Swatch</h1>
<% colors_in_stylesheets.keys.sort{|a,b|
   colors_in_stylesheets[b].size <=> colors_in_stylesheets[a].size
   }.each do |stylesheet| %>
  <h2><%= stylesheet %></h2>
  <% colors_in_stylesheets[stylesheet].sort.each do |color, garbage| %>
    <div class="swatch-block" style="background-color:#<%= color %>;">
    <span><%= color %></span>
  <% end %>
<% end %>

This works great for me since I always use hex colors, but I imagine it could be tweaked to find other color definitions as well.

Leave a Comment