I’ve been doing a little free-lance web development again lately. It’s been a while and the landscape’s changed in the 2 or 3 years since I was last freelancing. Specifically the ‘minimum requirements’ for a public facing site and the quality of the ‘cheap’ generic hosts have both increased (for the better). In light of these two factors I’ve been having a go at making some basic ‘web-presence’ sites using ruby on rails.

Learning enough rails to make a simple site was easy enough, but the deployment turned out to be a bit of a puzzle. Particularly as bluehost, whose control panel is otherwise excellent, just doesn’t seem to have its rails story sorted. To make matters worse, every “rails bluehost” tutorial out there starts with “you need SSH access” and bluehost now requires a faxed or emailed copy of the account-holder’s drivers license to grant SSH access. Seeing as my clients are generally the hosting account holders, this wasn’t an option for me.

After a bit of trial and error I’ve discovered that you can indeed deploy a basic Ruby on Rails site to bluehost without SSH access (assuming you have ftp access). Here’s how:

1. Create rails directory.Use your ftp client to create a directory alongside the {app} directory to which the domain/sub-domain points.I’ve called mine {app}_rails, but it can be called anything.

2. Upload rails app.Upload your rails app into the newly created {app}_rails directory.

3. Symlink to rails public directory using temporary PHP.We need to symlink the {app} directory (to which the domain/sub-domain points) to the {app}_rails/public directory. Ordinarily we’d use the trusty ln -s command, but we can also do it without SSH access by using PHP’s symlink function.

   Create a php script on your local machine (I’ve called mine symlink.php) with the following contents (replacing the {account} and {app} tokens with your own). Make sure the {app} directory doesn’t already exist (rename/move/delete it if it does).

   <?php symlink('/home/atfraser/public_html/maketimelapse_rails/public', '/home/atfraser/public_html/maketimelapse'); ?>

   Upload the symlink.php to an accessable directory and then browse to it in your browser. If the script succeeds you’ll be greeted with a blank page (otherwise you’ll get errors). Once run successfully, you can delete the symlink php script (it’s no longer needed).

4. Ensure dispatch.fcgi exists.To run under apache, a rails app needs fcgi dispatchers. My understanding is that rails 2.3 no longer fcgi dispatchers by default so if you didn’t use the --with-dispatches option when you created your app (I didn’t) you’ll need to create them on your local machine using the following command:

   rake rails:update:generate_dispatchers

   Then upload the created dispatch.fcgi, dispatch.cgi and dispatch.rb files from your localpublic directory to {app}_rails/public directory on bluehost.

5. Enable dispatch.fcgi in .htaccess.Create a .htaccess file inside your {app}_rails/public directory with the following contents:

   AddHandler fcgid-script .fcgi
   AddHandler cgi-script .cgi
   
   RewriteEngine On
   
   RewriteBase /
   RewriteRule ^$ index.html [QSA]
   RewriteRule ^([^.]+)$ $1.html [QSA]
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
   
   ErrorDocument 500 “<h2>Application error</h2>Rails application failed to start properly“

6. Check permissions using FTP client.We need to check/set some permissions. Again, we can’t use the standard chmod command without SSH access but luckily most modern ftp clients can also view/set permissions (select the file/directory then ⌘-i in Transmit or ‘right-click > File permissions’ in FileZilla). Set the appopriate permissions for the following files/directories (list courtesy Jack Danger Canty):

   File/Directory	Permission
   {app}_rails/public	755
   {app}_rails/public/.htaccess	755
   {app}_rails/public/dispatch.fcgi	755
   {app}_rails/public/dispatch.cgi	755
   {app}_rails/log	775
   {app}_rails/tmp	775

7. Handling rails gems version issues.If you're app still isn't working, check the error logs in cpanel. It may be that the version of the rails version you built against isn't available on the shared host. In this case,you'll need to either freeze the gems into your app locally (then upload the vendor/gems directory) or comment out the following line in environment.rb which refers to their specific version (risky).

   rake rails:freeze:gems

That should be it!

Step 1. Move bookmarks to delicious.com

About 2 years ago I moved all my bookmarks to delicious.com, a ‘social bookmarking’ service which stores your bookmarks and enables you to access, share and organize (via tagging) these bookmarks over the web. Over time it’s become second nature to save anything interesting I find to my delicious account.

Step 2. Install delicious.com browser extension

Whilst delicious (and its ilk) can be used via the web interface, things really get interesting when you install the relevant browser extensions. These give you an experience much like regular browser-based bookmarking, but with synchronization and superior bookmark search.

• Official Delicious Bookmarks extension for firefox (any OS). Best.
• Official Delicious Bookmarks Add-on for Internet Explorer (windows)
• Unofficial DeliciousSafari plugin for Safari (mac)
• Unofficial Bookmarks app for iPhone

Step 3. Specify “everyday” bookmarks

We all have bookmarks we use everyday. Delicious allows me to group mine together by applying a common tag (I use the tag “me”). I then tell the Delicious Bookmarks extension for firefox that the “me” tag denotes my favourites and viola! All my everyday bookmarks appear in Firefox’s toolbar. Better still, any additions or edits I make to this list of favourite bookmarks are propagated across all my browsers and computers.

Step 4. Bring on the favicons!

Although the Delicious extension for Firefox is great, it pays too much head to Firefox conventions for my liking. Specifically it doesn’t display favicons on mac (firefox doesn’t do toolbar favicons on mac by default) and doesn’t offer the ability to hide toolbar labels (which take up space). Luckily Firefox is highly customizable so I’ve managed to put together a simple Firefox extension which overrides these design decisions (and fix an intermittent “huge favicon” issue on mac Firefox). Behold: my Delicious Bookmarks Toolbar extension.

By the way, if you thought this blog post was written simply as an excuse to link to that simple extension, you’d be right.

<html>
<head>
<title>'Millenium' era</title>
<style type="text/css">
div.redSubHead {
  color: red;
}
p.greyText {
  color: #666;
}
td.columnHeaderCell {
  font-weight: bold;
}
td.oddRowCell {
  background: #eee;
}
td.evenRowCell {
  background: #ddd;
}
</style>
</head>
<body>

  <div class="redSub">sub 1</div>
  <p class="greyText">blah</p>
  <table>

    <tr>
      <td class="colHeader">A</td>
      <td class="colHeader">B</td>
    </tr>

    <tr>
      <td class="oddRow">1</td>
      <td class="oddRow">2</td>
    </tr>
    <tr>
      <td class="evenRow">3</td>
      <td class="evenRow">4</td>
    </tr>
  </table>

</body>
</html>

<html>
<head>
<title>'Semantic' era</title>
<style type="text/css">
.section h2 {
  color: red;
}
.section p {
  color: #666;
}
.section thead th {
  font-weight: bold;
}
.section td {
  background: #ddd;
}
.section tr.odd td  {
  background: #eee;
}
</style>
</head>
<body>
  <div class="section">
    <h2>sub 1</h2>
    <p>blah</p>
    <table>
      <thead>
        <tr>
          <th>A</th>
          <th>B</th>
        </tr>
      </thead>
      <tr class="odd">
        <td>1</td>
        <td>2</td>
      </tr>
      <tr>
        <td>3</td>
        <td>4</td>
      </tr>
    </table>
  </div>
</body>
</html>

One pillar of the ‘semantic’ technique is the sparing application of class attributes, primarily to container elements. Elements are ‘caught’ using CSS ‘descendant’ selectors (multi-part) which target hierarchies rather than using simple class selectors which require a directly applied class attribute. Using descendant selectors respects the hierarchical nature of the DOM but makes writing bulk CSS quite tricky. Why? Mainly because CSS stylesheets (and style blocks) are fundamentally rule lists, but the DOM elements which our descendent selectors target are obviously trees. How do we bridge the gap between these fundamentally different structures?

Enter ‘ragged’ CSS

In 2006 I (then a contracting developer) found myself filling the shoes of a fantastic design contractor whose contract was up but sadly not extended (project managers eternally underfund and misunderstand UI). I was the new ‘CSS guy’ for a project with scores of developers, hundreds of pages and crippling compatibility/accessibility requirements. I wasn’t really qualified for the task, but my predecessor gave me a CSS tip that got me through: “don’t sweat the properties, focus on rule hierarchies”.

This rule-centric approach is most clearly evident in the CSS formatting style I picked up on that project and used ever since; a style I call ‘Ragged CSS‘.

.section h2 {
  color: red;
}
.section p {
  color: #666;
}
.section thead th {
  font-weight: bold;
}
.section td {
  background: #ddd;
}
.section tr.odd td  {
  background: #eee;
}

.section { }
  .section h2 { color: red; }
  .section p { color: #666; }
  .section table { }
    .section thead th { font-weight: bold; }
    .section td { background: #ddd; }
      .section tr.odd td { background: #eee; }

It differs from the common ‘tall’ CSS formatting style in only a few (primarily cosmetic) ways:

1. One line per rule, one rule per lineThere may be hundreds of rules, but each will only have a handful of properties.
2. Indent CSS rules to represent target element hierarchyA block of markup (e.g. a calendar) will typically involve several rules (perhaps dozens). Indenting rules more clearly indicates how their properties will cascade.

3. Make rules for ‘landmark’ elements (empty rules if necessary)Adding an empty rule for element’s whose classes are used in subsequent selectors makes indentation hierarchy far clearer (improves readability).
4. ‘namespace’ your rules to avoid conflictClass names may be repeated on large projects unintentionally. Target ‘abc’ class elements inside ‘xyz’ class elements using a ‘.xyz .abc’ selector rather than a global ‘.abc’ selector to avoid tainting someone else’s unrelated ‘abc’ class.
5. Avoid element prefixes sparingly in your selectorsDon’t use a 'span.content' selector where a plain '.content' selector will do. Dogmatic prefixing (i.e. increasing specificity unnecessarily) makes your rules unnecessarily vulnerable to otherwise inconsequential markup changes (changing the span to a div for instance).

I’ve been using this formatting style for a few years now and it’s made complex CSS development a snap (browser quirks aside). If you’re writing ‘tall’ CSS (or using a tool which generates it), give ragged CSS a go on your next project. Your future self (and/or your successor) will thank you for it!

an IM icon created for a friend (whose name is a homonym for che’s)

In the process I decided to adorn my IM profiles with the mighty ‘Pico’ icon, something that had slipped my mind for years.

 
My new IM icon (based on my Pico character)

The original artwork dates is from the flash-based pico game I made for a uni assignment at Hong Kong University in 2002. As I spent all my free (and a fair chunk of my uni) time exploring Hong Kong with my friends, the assignment was developed in a marathon 48 hour cram session in the HKU multimedia labs. 

The game wasn’t always called Pico 

The game itself is a pretty basic affair, but still makes me laugh when I see the artwork and animations. As a bonus, it’s fiendishly difficult (being alone in a CS lab at 4am does tend to warp a coder’s mind). Give it a go, it’s a great cure for apathy.

 
Hong Kong Island (including HKU) is an festival of stairs and elevators

The whole 2-day stint was surreal; the deadlines, the long walk along pok fu lam road, the long hours, the great music, the septuagenarian tai-chi club which trained (complete with weapons) right outside the labs at dawn (their existence was unknown to me previously and seems unreal still).

 
Pok Fu Lam road, connecting HKU campus to the halls

My previous attempts had all involved reducing each image to a weighted list of ‘popular’ colours. The search UI let the user pick from the web (216) palette, with only images possessing a healthy portion of that colour being returned in the results. At one time I even allowed users to select a secondary colour along with RGB/HSV/CMYK (synchronised) sliders, but that was as complicated to use as it sounds, so I let it go. The problem was that this ‘popular colours’ approach ignored the fundamental truth that people just don’t search for drab browns, faded yellowy-greens or most of the other colours which make up these palettes. From a colour-space perspective, when people say ‘colour’, they mean ‘hue‘.

So earlier this week (on the train) I set about re-writing the whole colour search feature to actually be a hue-based search feature (the word colour remains because ‘hue search’ just doesn’t light up anyone’s eyes, not even mine). After a few train trips and most of Saturday I had the hue-parsing algorithm implemented and had written a console app which re-indexed all the existing images in the library. I also updated the relevant portions of the batch uploading tool and the admin web site to be hue-aware. Things were going well, but I had only a vague idea of how the actual search UI would work.

Initially I thought another slider would be the best approach, but decided it was overkill after looking around at existing html slider implementations (yahoo UI library as a nice slider, but I didn’t want the added dependency for what is essentially a minor feature). Eventually I set about rolling my own control for the job. I think the hue picker widget and the hue search feature as a whole turned out really well, and will continue to improve as the number of images in the library grows.

Now I’m thinking of packaging up the  Hue Picker for free distribution. You know, just for kicks.

Hi-lights include

1. .Net 1.1 to .Net 2.0 upgrade (long live the MasterPage)
2. Amazon S3 for all image storage (dramatically reduced bandwidth and hosting costs)
3. Google map-based location search.
4. Creation of “Pusher”, a fire-and-forget image watermarking, batch uploading and data-entry smart client app (to create the 12+ thumbnail and preview versions of each image).
5. Creation of “S3 Viewer”, a smart client app for viewing/maintaining the thousands of S3 items and buckets which support the site.
6. ‘New Images’ atom feed (surprisingly easy to get going).
7. SQL Server 2000 to SQL Server 2005 upgrade (Common Table Expressions are the goods).
8. GeoRSS feed to (hopefully) ensure photographs appear in search results as geo-tagged objects.
9. Tag-clouds for hierarchical image categories.
10. Colour search (still beta, currently rewriting the search algorithm to favour colour coverage rather than colour fidelity).
11. Cleaner UI design.
12. Xhtml transitional doc type with vastly improved markup validity (flash still causing some issues here). Some tables remain, to be slowly phased out when I have time.
13. Flash 9 homepage scroller (flash cs3 didn’t play nice with my old flash 6 swfs).
14. Self installed and configured SSL.
15. New hosting provider (discountasp.net, very impressed so far)

All told the upgrade took about 3 months’ worth of train trips, nights and weekends (around my day job). It’s meant an overall reduction in sleep, but ultimately worth it. Now I have just to force myself to stop tinkering with it.