So I finally sat down and hacked together a quick ‘System’ screen in my apps. Here’s an example:

System screen for Clipgarden (rendered in Fluid.app)

It tells me:

• How long it’s been since the last deploy
• The currently deployed revision
• Changes committed to the repository that are not yet deployed

This has been pretty awesome for me so far as it’s a really easy way to figure out if a certain fix or feature has been deployed yet (ever given the answer “well it’s committed, but not deployed”?).

Setup

In order for this code to work, you’ll need a Lighthouse account, and set it up to pull in changesets from your repository. I personally do this through Github since it’s just so damn easy. I won’t go into how to do this since there’s plenty of tutorials out there.

The Code

You’ll need to add the lighthouse api to your lib/ folder and then the following code should get you going. This code also assumes you’re using Capistrano or Vlad for your deployment so that a REVISION file is created in your root folder. If it doesn’t exist, there’s no harm done — but you won’t be getting any results.

Note that this also makes this fix a little hard to test in development since the whole idea is that it’s deploy-centric. I’d recommend copying down an old REVISION and throwing it in your rails root (but don’t commit!) for testing.

New model: system.rb

class System

  @@lighthouse_account = "ACCOUNT_NAME[CHANGE]”
  @@lighthouse_token = “BEACON_TOKEN[CHANGE]”
  @@lighthouse_project_id = PROJECT_ID[CHANGE]

  @@revision = nil
  def self.revision
    return @@revision unless @@revision.nil?
    if File.exists?(RAILS_ROOT + “/REVISION”)
      @@revision = IO.read(RAILS_ROOT + “/REVISION”).to_s.strip
    else
      @@revision = “unknown (in development mode)”
    end
    @@revision
  end

  @@deployed_at = nil
  def self.deployed_at
    return @@deployed_at unless @@deployed_at.nil?
    if File.exists?(RAILS_ROOT + “/REVISION”)
      @@deployed_at = File.mtime(RAILS_ROOT + “/REVISION”)
    else
      @@deployed_at = Time.now
    end
    @@deployed_at
  end

  @@lighthouse_project = nil
  def self.lighthouse_project
    return @@lighthouse_project unless @@lighthouse_project.nil?
    Lighthouse.account = @@lighthouse_account
    Lighthouse.token = @@lighthouse_token
    @@lighthouse_project = Lighthouse::Project.find(@@lighthouse_project_id)
    @@lighthouse_project
  end

  def self.changesets_since_deploy
    return [] if self.revision == “unknown (in development mode)”
    all_changesets = lighthouse_project.changesets
    changesets_since = []
    all_changesets.each do |changeset|
      break if changeset.revision == self.revision
      changesets_since << changeset
    end
    changesets_since
  end

end

Get the changesets in your controller

def index
  @changesets = System.changesets_since_deploy
end

Build a simple view

<h1>System Status</h1>
<p>The system was last updated <%= distance_of_time_in_words(System.deployed_at, Time.now) %> ago with revision <%= System.revision %></p>

<% unless @changesets.empty? %>
<h2>Changes made but not deployed</h2>

<div class="metabar">
  <p class="secondary"><%= @changesets.size %> changeset<%='s' unless @changesets.size == 1%></p>
</div><!-- /.metabar -->
<table>
  <tr>
    <th>Change</th>
    <th>Commited At</th>
  </tr>
  <% for changeset in @changesets %>
    <tr>
      <td class="small">
        <%= changeset.body_html %>
      </td>
      <td>
        <%= changeset.changed_at.to_formatted_s(:admin) %>
      </td>
    </tr>
  <% end %>
</table>
<div class="metabar">
  <p class="secondary"><%= @changesets.size %> changeset<%='s' unless @changesets.size == 1%></p>
</div><!-- /.metabar -->

<% else %>
<p>No changes!</p>
<% end %>

Downfalls

There are a few downfalls to this quick & dirty approach. The most noticeable is that each and every one of your requests to this system page make an API call to Lighthouse. However, so long as you put this page in the admin section of your site, you should be fine. In a perfect world, we’d cache the results locally.

Have fun and let me know if you have any improvements, or any way to add this into some kind of useful distributed form (plugin?).

Your margins are doubled in IE6

Here’s a super common pitfall: IE6 will double margins facing the direction of the float. Example problematic code:

.sidebar{
  float:left;
  margin-left:20px;
}

This sidebar will have a 40px left margin in IE6 — almost certainly throwing the sidebar down below the content, and not next to the content as it should be. Easy fix: add display:inline; No side effects in any browser, and IE6 obeys margins perfectly.

.sidebar{
  float:left;
  margin-left:20px;
  display:inline
}

Why it works: By declaring float on an element, you implicitly demand that it must be rendered as a block element — thus rendering the display:inline inert. However, due to IE6’s awesome CSS engine, it fixes a bizarre bug that is the #2 reason I see CSS columns fail in IE6.

Your content is wider than your column

Let’s pretend you’ve got this simplistic setup of code:

.columns{
  width:500px;
}
.columns .main{
  float:left;
  width:400px;
}
.columns .sidebar{
  float:right;
  width:100px;
}

HTML:

<html>
...
<div class="columns">
  <div class="main">
    <img src="/images/awesome.gif" />
  </div><!-- /.main -->
  <div class="sidebar">
    <p>Sidebar rules!</p>
  </div><!-- /.sidbear -->
</div><!-- /.columns -->
...
</html>

Harmless right? You might view this in Firefox and everything will be fine. But then you look at it in IE6 and your sidebar has mysteriously dissapeared below .main. WTF? You look at the HTML, the CSS, and everything’s fine. What could possibly be wrong? A common problem here is if awesome.gif is 510px wide. What this does is push out .main to 510px, and suddenly there’s not enough room for .sidebar inside .columns any longer. Ack!

Easy fix: add overflow:hidden to your columns. This forces the width restriction to crop any extruding content. New magical CSS:

.columns{
  width:500px;
}
.columns .main{
  float:left;
  width:400px;
  overflow:hidden;
}
.columns .sidebar{
  float:right
  width:100px;
  overflow:hidden;
}

Your margins extend past your container

So you’re building out a simple product listing template out, and you throw it in an unordered list:

ul.listing{
  margin:0;
  width:400px;
}
ul.listing li{
  list-style-type:none;
  float:left;
  margin:0 20px 0 0;
  width:85px;
}

HTML:

<html>
...
<ul class="listing">
  <li>Product #1</li>
  <li>Product #2</li>
  <li>Product #3</li>
  <li>Product #4</li>
</ul>
...
</html>

This CSS will work just fine in something like Firefox, but for mysterious reasons you’ll see that Product #4 appears on it’s own line in IE6. What’s happening here? I mean 4 columns x 85px + 3 gaps x 20px = 400px, right? Except that your 4th gap is hanging over the right edge — pushing the true width of the blocks to 420px. Firefox is smart and lets that margin just hang out there — but IE6 will apply that margin within the parent wrapper — throwing the 4th item down since it takes up 20px more than it should have.

The fix? Apply a left margin to each item, with a negative margin to the wrapper. This means that every item has a visible margin, but the whole block of elements are yanked back by the negative margin:

ul.listing{
  margin:0 0 0 -20px;
  width:420px;
}
ul.listing li{
  list-style-type:none;
  float:left;
  margin:0 0 0 20px;
  width:85px;
}

This gets around the nasty solution of adding a class to the first or last item in every row — something I’ve seen with abundance around the web.

Building a CSS framework in no time

Wev’e got to start out with some basic HTML. Here’s what I’ve been using lately:

<html>
...
<div class="columns col2">
  <div class="column first">
    ...
  </div><!-- /.first -->
  <div class="column last">
    ...
  </div><!-- /.last -->
</div><!-- /.columns -->
...
</html>

For different column widths, I’ve been changing out the col2 declaration to things like col2A, col2B, col2C and so on. You could easily give them more semantic names like products-columns too.

Self clearing is the future

The first step for any column framework is self-clearing. It’s easy, practical, and reduces all those damn clearing divs.

.columns:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
}
* html .columns {height: 1%;}
.columns{ display:inline-block; }
.columns{ display:block; }

Float those columns

Next step is to actually float those columns. So let’s add a couple more declarations:

.columns .column{
  float:left;
  overflow:hidden;
  display:inline;
}
.columns .last{ float:right; }

.col2 .first{ width:500px; }
.col2 .last{ width:100px; }

.col2A .first{ width:400px; }
.col2B .last{ width:200px; }

.col3 .first{ width:100px; }
.col3 .second{ width:280px; margin-left:20px; }
.col3 .last{ width:200px; }

Done… uh, what?

Oh, yeah. That’s it. That’s all it takes to create reliable columns in CSS. Really.

Here’s an example page to prove it!

Vlad deploy file

Vlad comes with turnkey deployment for rails with apache and mongrel. We’re using merb, so we’ve got to make a few changes. Under config/deploy.rb go ahead and throw something similar to this in:

require 'vlad'

set :application, "applicationname"
set :domain, "yourserver.com"
set :deploy_to, "/path/to/deploy"
set :repository, 'git://github.com/kneath/greed.git'

namespace :vlad do
  ##
  # Merb app server

  set :merb_address,       "127.0.0.1"
  set :merb_clean,         false
  set :merb_command,       'merb'
  set :merb_conf,          nil
  set :merb_extra_config,  nil
  set :merb_environment,   "production"
  set :merb_group,         nil
  set :merb_port,          4000
  set :merb_prefix,        nil
  set :merb_servers,       1
  set :merb_user,          nil

  desc "Prepares application servers for deployment. merb
configuration is set via the merb_* variables.".cleanup

  remote_task :setup_app, :roles => :app do
    "rake"
  end

  def merb(cmd) # :nodoc:
    "cd #{current_path} && #{merb_command} -p #{merb_port} -c #{merb_servers} -e #{merb_environment} #{cmd}"
  end

  desc "Restart the app servers"

  remote_task :start_app, :roles => :app do
    run merb('')
  end

  remote_task :start_app => :stop_app

  desc "Stop the app servers"

  remote_task :stop_app, :roles => :app do
    run merb("-K all")
  end

  remote_task :migrate_merb, :roles => :db do
    run "cd #{current_release}; rake db:migrate MERB_ENV=#{merb_environment}"
  end

  task :update do
    run "cp #{shared_path}/database.yml #{current_path}/config/database.yml"
  end
end

task :deploy => ["vlad:update", "vlad:migrate_merb", "vlad:start_app"]

(I apologize for no credit given to the author of this, but it was in a pastie I found via ma.gnolia.com and I don’t even know where it is anymore)

Setup the server

Go ahead and run rake vlad:setup and make sure all your ssh workings are going good. It should create a /path/to/deploy/shared folder. Inside of that folder, go ahead and throw down your database.yml file with production passwords in it (You aren’t keeping passwords in your source control are you?).

After that, your server should be all set up!

Gitting set up

Vlad

Got Vlad 1.2+? Git submodule is already installed. You just need to edit your rake file and change the vlad require to something like this:

begin
  require 'vlad'
  Vlad.load :scm => "git"
rescue LoadError
  # do nothing
end

Then in your deploy.rb change your repository location to your git url:

set :repository, 'git://github.com/kneath/greed.git'

The Server

Your server must have git installed in order to deploy from a git repository. Some might think a simple sudo apt-get install git-core would do the trick. Well, almost — you’ll run into the following error if you do that:

fatal: You must specify an archive format

Reason for this: apt-get install git-core installs a 1.4x version of git on your Ubuntu machine, and apparently a default for git archive was added in a later version. Solution: install from source. Go to a temporary source folder and run the following commands:

sudo apt-get remove git-core
wget http://kernel.org/pub/software/scm/git/git-1.5.5.1.tar.bz2
sudo apt-get build-dep git-core
tar xjf git-1.5.5.1.tar.bz2
cd git-1.5.5.1/
./configure
make
sudo make install

All might not be well with those commands though. If you hit something like:

SUBDIR git-gui
MSGFMT    po/de.msg make[1]: *** [po/de.msg] Error 127

You’ll need to install gettext (totally makes sense, right?). sudo apt-get install gettext and then start the previous sequence of commands where you left off.

Deploy

After this, everything worked just fine for me. rake deploy and vlad should update your code, run the migrations, and start up your servers.

Advertising available now

Starting today you can go ahead and order some ads on Warpspire, or if gaming is your thing get some Total Spore ads. This is the first time I’ve ever tried the whole private ads thing, so it’s very much an experiment right now. However, I do want to make it clear that I’m going to do my best to keep the ads relevant to the sites’ respective audiences.

The only thing about private ads is that you’ve got to manage them yourself. And pretty much all ad serving software sucks.

Greed

A while (long while) ago I teamed up with Josh Pigford to build an ad serving application. Things didn’t quite work out, mostly because my own goals were higher than my free time. Well, my free time came back and I kicked down my goals a few meters on the goal post. What came out is Greed.

Greed is a simple ad serving web application written in merb. I’ve never written an application in merb before, so I decided to try it out. Greed is also open source, so fork it, hack it, and use it! I’ll try and post up my thoughts on merb in the next few weeks.

Design is a tricky thing. There’s no one right way to do something — it’s a mix of style, aesthetics, and culture. This means that you can solve any design problem a dozen different ways and still come up with something that is interpreted as a success by your client. It can be easy to fall into a design rut, always falling back to your same old tricks. People encourage you by complimenting the work, but deep down sometimes you might wonder if you could have done something better.

That’s why I think design exercises are an important factor of any designer’s career. Every now and then you need to force yourself to solve a problem differently — it’ll force you to branch out and look for new tools and techniques. It’ll force your brain into a new line of thinking and you might even find a new style of design that you prefer. When I look back on my personal projects’ designs, I find that I’ve almost always forced myself into a design exercise from the beginning. The rewards have been monumental personally, so I thought I might work through some of my past work and how I worked design exercises into them.

Examples from Warpspire’s past

Version 3, circa Summer 2004

Exercise: Work with texture to create an appearance of aging.

Solution: This site came out just before Cameron Moll’s Wicked Worn series (or at least, before I had read it). However, I wanted to design something that was notably non-digital-ly. Forcing myself into this style made me look for new approaches to designing, and two great things came of this: the discovery of the incredible diversity of free Photoshop brushes, and the use of photographs/scans in nonstandard ways.

What I mean by that last point is using a photograph for something other than a picture in the page. Creating the envelope in the upper left was incredibly challenging to me at the time, and the only way I was able to reliably recreate it was to use a photograph of an envelope as a stencil of sorts.

Version 4, circa Winter 2005

Exercise: Use color and create something notably non-bloggy.

Solution: This design of Warpspire marked the first design I had created that used any kind of bold or vivid colors; my past designs had always relied on muted or monochromatic color schemes. Forcing myself to work with color ended up in me throwing out nearly a dozen comps, but it was invaluable experience — by the end of it I felt infinitely more comfortable using color in my design.

Version 5, circa Summer 2007

Exercise: Highlight a diverse collection of content on the homepage while dividing opinion from tutorial-type content.

Solution: Forcing myself to let the content do the designing was really tricky. I strayed away from any unnecessary visual clutter, and couldn’t fall back to cheesy ornamentals throughout the site. I think the single largest benefit of this design style was learning to use stock images better. Even adding a mediocre stock image to a design can make the end result visually stunning.

Conclusion

I think the idea of assigning yourself design exercises is a great idea. If you just design with all the tools you have, your designs will soon get stale and you won’t be adding any new tools to your toolbox. By forcing yourself to solve a problem in a different way it forces you to break your normal thinking pattern and explore. It keeps your creative juices flowing and can force you to design in a style you usually wouldn’t turn to.

I actually do the same technique with my programming — every now and then I learn a new language. Pretty much any problem can be solved with the language of your choice, but it’s a good idea to force yourself into new uncomfortable languages just to broaden your knowledge base.

Well I was oh so wrong. Documenting your own code is critical to future maintenance. It’s been almost a year since I launched the rewrite of Poetry with meaning and it’s become incredibly frustrating maintaining the site. I realized the reason for this is lack of documentation and code testing (more on this later). Coming back to 2,000 lines of code without looking at it for 4 or 5 months is just painful. The problem with the code base is that I was taking too much time commenting the code — and no time documenting it.

Let’s take an example of some commented but not documented code:

# clean the filename
stripped_location = @file_location.gsub(/(.+)\.(.+)/, '\1')
stripped_location = @options[:redo] ? stripped_location.gsub(/(.+)_original/, ‘\1′) : stripped_location

This code doesn’t really tell me anything. Cleans the filename? Coming back to this code months after it was written doesn’t tell me a thing.

What I should have been doing is documenting the code. Documentation to me answers the “what does this do?” question. Here’s an example of some code in progress:

module Overseer
  module Backup
    # Creates a backup for one mysql database. The resulting export will be 
    # gzipped and named with the date first and then the databse name
    #
    # Usage:
    #   Overseer::Backup::Mysql.new(:username => "webdb", :password => "ultimatetest", :host => "mysql.example.com", :database => "pwm_production")
    #   For database called "pwm_production" backed up on April 7, 2008 , the final name will be: 2008.04.07.pwm_production.sql.gz
    #
    # Options:
    # * :username - database username
    # * :password - database password
    # * :host (optional) - the database host name
    # * :database - the name of the database
    class Mysql

      attr_accessor :username, :password, :host, :database

      def initialize(options = {})
        @username = options[:username]
        @password = options[:password]
        @host = options[:host].nil? ? “localhost” : options[:host]
        @database = options[:database]
      end

    end
  end
end

I haven’t even really written anything useful yet — but by writing the documentation I’ll know what I was doing a week from today instead of just blindly looking at the code. My documentation tells me how to use the code, not what the code does.

Documenting your code also forces you to really think the functionality through. It makes you think about the architecture of your code before you write it and forces you to think about how it will be used instead of how it was written. It all comes back to the idea that code is written for humans, not machines — so why not start with writing your code 100% human style? (in text!)

The question that struck me in particular came when someone was badgering him at around what size site would you encounter problems scaling Rails. His response was something along the lines of: “No offense, but you won’t ever build a site popular enough to worry about it.” And it’s damn true.

Who cares if your framework can scale if it’s never going to be big enough to worry about? The truth is that almost all web ventures never become big enough to even need a separate database server, let alone a farm of memcached servers, file servers, and enough computing power to plan a trip to Orion. That doesn’t mean they won’t become profitable. You can be extremely profitable with relatively low traffic.

So don’t worry about scaling — scaling is for nerds. By the time you hit pain points, you can bring in someone who really knows what they’re doing. Most importantly, by the time you hit pain points, you should be profitable enough to not worry about bringing in someone who knows what they’re doing.

And no, just because your site goes down for an hour while on the home page of digg.com doesn’t mean that you need to worry about scaling.

More info on that previous link soon :)

But that didn’t stop him from preaching (all comments are disabled and Arron does not respond to email) that you shouldn’t use the technology. Quite honestly, it pissed me off. I sent an email to Arron shortly after reading his post on Thursday, and Arron seemed fit to ignore my email completely.

Here is the letter I sent to him:

Arron,

While I appreciate your intrigue about Flex, I feel like you’re unfairly damning a technology for all the wrong reasons. As per your technical argument, you’re probably right. However that comes with the caveat that JAWS can rarely navigate the majority of the HTML web as it sits today with any sort of ease. It’s no lie to anyone who’s tried to legitimately use screen readers that the technology is highly divisive and non-functional (different readers render differently, function differently, and support different aspects by default).

The sad and unfortunate fact is that anyone who wants a truly accessible site must work very hard, testing and using various screen readers throughout development. (no free lunch indeed). Using standards & best practices only gets us half-way there.

Suggesting that Flex should not be used (”However, until that happens, I can not recommend Adobe Flex.”) is like saying we shouldn’t move forward with HD programming because some people still have SD TV sets. Flex is a revolutionary technology that redefines the rules of what we’re capable of delivering over the web. It can be accessible, and even more so than HTML ever could if you have the desire (you could script your own narrative to guide visually disabled through the form process, accepting voice input and encoding to textual input to the form if you felt the need).

At the end of the day, if you’re looking to deliver a site targeted at visually impaired people, Flex is almost certainly not your choice. The same way social security benefits advertisements will continue to be broadcast in high-contrast SD programming on TV.

But is that reason to not use a technology?

The summary of the above is twofold:

• Even HTML is not accessible by default. You must work very hard to make a fully accessible website using HTML, CSS and (should you dare) Javascript.
• Flex doesn’t really need to be accessible. That’s not the target of the technology.

Much talk and little action is done on the web in terms of “accessibility” and making sites available to the visually impaired. I encourage anyone who has never used JAWS to go ahead and use it on your own site. Then I suggest you try a couple other competing screen reading solutions. I think you’ll find that it’s kind of a crap shoot. Navigating most “accessible” and semantic web sites is maddening at best. Most of the time it feels as though someone’s asking you to read War & Peace without any paragraphs or headings. Sure, the information’s there — but it’s realistically inaccessible.

My point being: accessibility is not something a technology offers. It’s something that a technology can support (and indeed, Flex supports accessibility just fine) — but it’s not something a technology gives you for free.

Unfortunately I believe that Arron has done his damage to the web community and turned thousands away from an amazing technology simply because he doesn’t personally like it. Undoubtedly, Arron’s response will be: “show me.” My response to that is: Why? You’re persecuting a community without cause. Give me proof Flex is not accessible. All in all, I just think it’s sad — and I hope that anyone reading this won’t throw Flex out because it’s “inaccessible.”

The Basics

The core of all of these effects is a simple sequence of events:

1. The effect function is called on an element (i.e. new Effect.Fade(’myid’))
2. The effect function sets a number of initial styles on the element
3. The effect function then defines an update function that modifies CSS properties of the element in reference to a point from 0 to 1
4. This update function is called repeatedly for a set duration of time passing in the reference point each time
5. A cleanup function is called to re-set some of the original styles, and do the final dirty work.

Defining styles

This step is crucial in any effect. In order for some visual effects to be pulled off, certain CSS properties must be set on the element before anything can happen. The most common styles that are modified during this startup time are the overflow and position properties. This allows us to use CSS properties like width, height, left and top to make the element expand, contract, and disappear out of bounds.

Update function

This function is the most important, and also the simplest part of the javascript effect. It modifies one or more of the element’s CSS properties an incremental amount, in relation to an internal reference point (going from 0 to 1). The easiest example of this is opacity. If we imagine that we are going to repeatedly call this function and pass in the reference value, you could easily change the opacity from 100% to 0% by setting the opacity equal to the reference value multiplied by 100%.

Calling the update function

This is the most interesting part of the javascript effects to me. The update function is called is by setting a timer using setTimeout() every so often (40ms is a good interval to start out with). This update function is called for a set duration of time (500ms, or half a second is a typical duration). While this is going on, an internal reference point (mentioned above) is set to a new value each time the update function is called. The javascript uses a formula to generate this reference value much like this: time spent / total duration = counter.

… except there’s one little catch: linear effects feel very unnatural and robotic to the human eye. This is where I get all geeky about the relation between math and design and how everything ties back into math sooner or later (yes, I’m really that big of a nerd). So - if we can’t use a simple linear timeline, what do we use? It turns out that a Sinusoidal patterns work beautifully. This is the equation that the majority of the effects in Scriptaculous and moo.fx use, but they also offer several others: linear, cubic, circular, flicker, wobble, and pulse.

Here are examples of each of these functions using a simple timeline and colored square (to demonstrate the timeline’s effect on a sample opacity effect) over a 2 second period.

Sinusodial

start sinusodial timeline

Linear

Start linear timeline

Cubic

Start cubic timeline

Circular

Start circular timeline

Flicker

Start flicker

Wobble

Start wobble timeline

Bonus! Start all effects simultaneously

Try mixing up these different timelines in your next javascript effects — it’s a great (and easy!) way to make your app feel just a little different than everything else out there.

Cleanup function

The last part of the process is a very simple step that just cleans up any styles that the effect created that you don’t want lying around. If you happen to set a style in the initialization, it’s usually a good idea to undo that style at the end of the effect.

This is also the time you can apply any finisher properties. For elements that are fading out, or zooming out of view — you’ll probably want to be setting display:none; so they are removed from the layout flow.

Conclusion

Once you get a good grip on how Javascript effects work at their core, you’ll soon realize that they’re not so nasty and complex. The hardest part is the math — and most computer geeks I know are pretty good at math. Play around with trying to create your own effects.

Challenge

If you’d like to challenge yourself, try and use your framework of choice (Prototype, MooTools, YUI, jQuery) and build a javascript effect that moves an element in an elliptical path. Hint: You might try absolutely positioning the element inside of a relatively positioned bounding box.