In late April, we added screenshots to the Realized-app product tour. Our design drew upon an idea we saw at AgileZen.com, where clicking a thumbnail expands into a larger screenshot lightbox.

The Realized-app already makes use of jQuery, mainly for client-side processing of stock ticker choices. To animate our screenshots, we adopted the jQuery plugin that AgileZen uses, Fancybox. Our configuration:

$(document).ready(function() {

  $(".fancybox > a").fancybox({

    'hideOnContentClick':true,

    'titleShow':false,

    'transitionIn':'elastic',

    'transitionOut':'elastic',

    'speedIn':800,

    'speedOut':800,

    'easingIn':'easeInOutExpo',

    'easingOut':'easeInOutExpo'

    . . .

One interesting aspect of configuring Fancybox is its support of the Easing plugin to control the transitions. Easing controls how an animation progresses over time by varying its acceleration, giving each transition a more natural effect.

Having a staging environment to verify changes adds an extra measure of confidence to each deployment. Git is the primary means for deploying apps to Heroku. For Heroku, a staging environment corresponds to another app. For Git, it is just a branch.

Thomas Balthazar has written a full outline of how to deploy multiple environments on Heroku and still host your code on GitHub. With the Heroku and GitHub repos thus configured, our local repo has three branches:

• Working
• Staging
• Production (master)

Why do we use Git?

We build and test all changes in the Working branch before merging with the Production master. Our workflow to deploy a tested change from Working through Staging to Production:

# standing in /rails_app_root

git checkout -b working

# after committing a change

git status

# nothing to commit (working directory clean)

git checkout staging

git merge working

# 'see' Fast forward

git push heroku_staging staging:master

heroku maintenance:off —app staging_app_name

# exercise the staging app to verify change

heroku maintenance:on —app staging_app_name

git push  # to GitHub

git checkout master

git merge staging

# 'see' Fast forward

heroku maintenance:on —app production_app_name

git push heroku_production

heroku maintenance:off —app production_app_name

git push  # to GitHub

git checkout working

# go forth and make more changes

Witness the ease with which a local Git repo operates with remotes on GitHub and Heroku. Those who have not yet tried Git may not know what they have been missing.

Some months ago we adopted delayed_job as our asynchronous background processor. In Realized-app several tasks, particularly tax lot setup, benefit from background processing.

Taking the advice from this blog post on GitHub, we reduced the coupling between models and the message queue by placing the background methods in lib/msg_queue.rb.

module MsgQueue

  class UserActivationConfirm < Struct.new(:user_id)

    def perform

      user = User.find(user_id)

      user.activation_confirmation_email

    end

    . . .

We create the corresponding delayed job in models/user.rb.

class User

  def activation_confirmation_mq

    mq = MsgQueue::UserActivationConfirm.new(id)

    Delayed::Job.enqueue(mq)

  end

end

The call to Job#enqueue remains within each model to allow for passing a priority parameter, should that be needed.

Deployment on Heroku

Heroku began limited support for delayed_job in July. Yesterday Heroku broadened that support with a new feature that provides for multiple delayed_job workers per app. That capability sealed our decision to deploy, at least initially, on Heroku.

Some of the more rudimentary aspects of unit testing involve validation. These tests may exercise ActiveRecord or the database constraints created by a migration.

In a chapter from Enterprise Rails, ‘Database As a Fortress’, author Dan Chak advocates for employing the data integrity features of modern databases, particularly PostgreSQL. With Realized-app, we use PostgreSQL as a persistent data store.

To go beyond just testing the ActiveRecord model validations, in testing a database constraint Dan suggests using the following test_helper.rb method:

def expect_db_error(&block)

  begin

    yield

  rescue ActiveRecord::StatementInvalid

    database_threw_error = true

  rescue

    something_else_threw_error = true

  end

  assert !something_else_threw_error, 'defective case'

  assert database_threw_error && !something_else_threw_error

end

One difficulty with testing database constraints is that the ActiveRecord model validations may catch some errors before they reach the PostgreSQL database. As a work-around, we can add another method:

def svf(obj) obj.save_with_validation(false) end	

Using these test helpers, this test will properly exercise the database constraints defined by a migration.

test 'name too long' do

  expect_db_error { svf(some_model_save(:name => 'name_too_long')) }

end

Such validation tests tend to be similar among different models. Just as concerned_with allowed for division of model logic into discrete files, we place unit test validation tests in a separate /test/unit/validation directory. This prevents cluttering model-specific logic with boilerplate validation checks.

Most web apps can benefit by leveraging a CSS framework to follow best practices. Realized-app is no different.

Our chosen CSS framework, Object Oriented CSS stood out because of two underlying principles:

• Separate structure and skin
• Separate container and content

With Object Oriented CSS, columns or grids control width. Content controls height. Modules provide containers. Skins are applied to any of these structures.

Like Rails, the framework continues to evolve. Our adoption of Object Oriented CSS divides it into three parts:

• Core
• Core mods
• Skins

The core consists of five .css files: libraries, template, grid, content and module. Rather than modifying the core, we place any modifications to the core in five core mods files. We then associate a distinct skin.css to each of the core elements. As the core files evolve, we simply replace them without disturbing the remaining files.

Several models within our web app, Realized-app, have grown to more than 500 lines. Rapidly grasping the relationships among methods in these models had become difficult. Some means of dividing the models into coherent pieces was needed.

An elegant fix came about while reading the code for the rails-based forum, altered_beast. First, app/models contains a ‘user’ directory. Near the top of models/user.rb, also note a call to concerned_with:

class User < ActiveRecord::Base

  concerned_with :validation, :states, :activation, :posting

  . . .

One of the rails initializers defines concerned_with. Four files named by the symbols passed to concerned_with reside in app/models/user. The user methods pertaining to validation are found in models/user/validation.rb. Without the separation provided by concerned_with, this validation logic would exist in models/user.rb.

Using concerned_with, we have refactored the largest models in Realized-app. Now, at a glance, most of the functionality unique to a particular model becomes readily apparent.

For a good perspective on the origin of concerned_with and how to use it, see this post by Paul Barry.

Welcome to our blog. We have been working for nearly five months to create a simple and effective stock portfolio management tool.

Much of our energy this year has been devoted to building our web app, Realized-app. Taking a few hours to look into a blog architecture was a welcome change in direction. Very quickly we settled on Jekyll for use as a blog generator.

Jekyll is written in Ruby. Because of that, we are confident that if our needs outgrow Jekyll, we should be able to bolt something on without too much difficulty. One of its early proponents, Henrik Nyh did just that by adding support for Haml. Using Haml allowed us to streamline the design of our blog archive page.

Look for the launch of the Realized-app blog soon, also to be built on Jekyll.