Firsthand Web Design, Ruby on Rails, Montréal

Ron Jeffries on Requirements

2013-05-07T07:33:00.001-04:00

This is one of my favourite quotes on requirements:

Most of us were taught to write down all our requirements at the very beginning of the project. There are only three things wrong with this: “requirements,” “the very beginning,” and “all.” At the very beginning, we know less about our project than we’ll ever know again. This is the worst possible moment to be making firm decisions about what we “require.”
From Estimation is Evil, Ron Jeffries: Signatory of the Manifesto for Agile Software Development

Recently Launched: Tarkett Sports CMS and Websites

2013-04-26T09:04:00.001-04:00

An ongoing project I have been working on at Dynamo over the last year with Hugo Frappier is a custom CMS for Tarkett Sports, a division of the Tarkett Group, "a worldwide leader of innovative and sustainable flooring and sports surface solutions".

A multi-Site, multi-lingual CMS

Tarkett Sports required a multi-site, multi-lingual CMS to serve all the sites of their subdivisions. FieldTurf (North America) was the first to be launched on the new platform, followed by FieldTurf Europe and an API for their iPad sales tool, "Link". At the time of writing, Beynon Sports Surfaces and Tarkett Sports Indoor (North America) are set to launch within the month.

Built on Ruby on Rails and MongoDB

The CMS was built with the usual Rails stack, however MongoDB was used with Mongoid, an Object-Document-Mapper, instead of ActiveRecord and a relational database. This was my first venture in the world of NoSQL, and working with a schema less data store was a perfect match for the CMS. However, it did require a new way of thinking, such as being comfortable with de-normalizing data structures and ensuring those data structures can be properly index. For example, MongoDB does not allow indexing of parallel arrays.

Support a large content-base

Why a custom CMS? Why didn't we just use one of the prominent offerings such as RefineryCMS? I've implemented five RefineryCMS installations over the last couple of years, and Refinery's sweet spot is small websites. Tarkett Sports currently holds over 10,000 content items. Refinery's UI and tree data structure is just not appropriate for such a large content-base.

Publish content collections anywhere in the page hierarchy

We also took a novel approach to the page hierarchy. With platforms such as RefineryCMS and Radiant, structured content (think news and product catalog) containing large data sets are typically supported by creating custom Rails model view, and controller classes. There's usually wrangling to unify the site URLs with the routing system. The Tarkett Sports CMS supports the concept of a collection. A collection of structured content, small or large, can be published anywhere within the page hierarchy. No URL wrangling required, no custom controller class. Collections are a first class citizen.

Reduce custom classes, increase content type re-use

The benefit of all this is that it has reduced the number of custom classes required for a site by increasing the reuse of existing collections and content types. In the past, I have found myself creating custom controllers and models just to support a different content type with the same structure just so I can use it in a different part of the page hierarchy. The concept of publishable collections has solved this.

Below are a few screen shots, showcasing the different sites and portions of the administration screens.

FieldTurf (North America) Home Page

FieldTurf (Europe) Home Page

FieldTurf Products

FieldTurf Product Detail

Tarkett Sports CMS Admin: Pages

Tarkett Sports CMS Admin: Page Detail

Tarkett CMS Sports Admin: Page Publishing

Open Gems with vim-bundler

2013-04-22T07:21:00.001-04:00

When working with platforms such as Spree and RefineryCMS it's more than likely that I will be extending their models more often that not. This means opening the Gem to identify a specific behaviour I want to override. Vim is my text editor of choice, and I typically try to restrict my self to one instance of the editor running. It makes working with multiple buffers a lot easier! Whenever I want to open a Ruby Gem, it always irks me that I have to open another instance of the editor, in a separate window/pane (although Tmux reduces the pain of this a wee bit).

Vim does offer a client-server option, but admittedly I couldn't get this working and in my search I came across Tim Pope's vim-bundler. From the README:

An internalized version of bundle open : :Bopen (and :Bsplit , :Btabedit , etc.).

Exactly what I wanted, a way to `bundle open` within Vim. Here's a quick demo of using vim-bundler to open Spree's `Order` model and navigate to the `add_variant` method.

vim-bundler from Nicholas Henry on Vimeo.

Taming the pile of unread books

2013-04-09T08:07:00.001-04:00

Recently I posted to Facebook:

You know you have a book buying problem when... you discover that you have two copies of the same book on your bookshelf. Unread.

Yes, I have a book buying problem. And after that post I decided it was time to do something about it. I love reading. I find it extremely motivating and inspiring. But having a few dozen unread or partially started books is not only a waste of money, but just another open loop in my life that just doesn't need to be there. Jumping from book to book also inhibits in my ability to really understanding a book.

And before you start thinking I'm talking about a pile of trashy romance novels, I am talking about computer and business related books!

So how did it get this way?

I have always had a stack of unread books around, but I typically got through the queue. However, with eBooks it really has got out of control. I start with reading an inspiring blog post, or watching a video of a conference talk, it references a book and wham! Next moment, I'm online purchasing that sucker.

So what have I done to resolve this?

It was pretty simple really. I present to you, my three step plan:

First, I took inventory. I identified the books as unopened, "briefly" started (read a few chapters), and "well" started (at least half way through).
For those that were briefly started, I removed bookmarks, virtual or physical, and added them to the unopened pile. Basically, calling bankruptcy on the "briefly" started. This cleared a lot of open loops. A lot.
With the "well" started books I recorded them in OmniFocus. This has helped me to keep conscious of how many books I have on the go. This ended up being four in total. The goal is to have no more than two in progress.

Since starting this two weeks ago, I have completed one book, and will finish the second this week. I will be at my goal of two in progress. Oh, and I haven't bought any new books in the last two weeks -- there have been a couple of occasions where I would have.

Yes, I know this all sounds pretty ridiculous. However, I bet I'm not the only developer out there, with a book addiction. If you are, please let me know in the comments, how you have curbed your book buying behaviour, or please give my recovery plan a go!

Have you tried ctags with Vim?

2012-11-30T16:55:00.001-05:00

After reading Mislav Marohnić's excellent post on Vim, I decided to add ctags to my development environment. What does it buy you? It allows you to jump to method or class definitions with these commands:

<C-]> / :tag foo # jump to tag under cursor/named
g<C-]> / :tjump foo # choose from a list of matching tags

Setup is pretty easy:

brew install ctags

You can generate tags with:

ctags -R --languages=ruby --exclude=.git

But you probably won't want to do all that manually. As Mislav points out in his post, Tim Pope shows us how to automate tag generation with git hooks.

I've been using ctags this afternoon and already it has turned Vim into a completely different editor for me.

Using Google Site Search for Content Sites: Things to Keep in Mind

2012-11-12T14:09:00.001-05:00

I've used Google Site Search for a couple of unstructured content sites (opposed to applications or structured content such as catalogs) and pretty happy with it, but there a certainly some things you should be aware of before committing to this service:

The service's crawler works the same on Google.com. This means, it will only index publicly available pages that it can access. So you cannot use it on password-protected staging sites.
If you consider removing the password from the staging site you won't want to do that either, as your site must be registered with Google Webmaster tools, so your staging site will eventually end up in the Google.com index. But there's also another issue.
Indexes to URL's contain the domain of your site, so you can't index your staging site, then hope to use that index in your live site.

If you're re-launching an existing site -- your only option is to enable search after you have made that site publicly available via the production domain. If it's a new site, and you have the option, make the site publicly available a couple of days before hand and index the site. Google Site Search provides on-demand indexing, updating the index within 24 hours.

When indexing the site, you have three options for supplying URL's:

Individual URL's only
URL's linked from a specific page or Sitemap
URL's in a Sitemap only

Again, you must have your site registered with Google Webmaster Tools for the indexing to work.

For more information on indexing checkout Custom Search Help documentation.

Domain Patterns are Alexandrian Patterns

2012-10-26T18:48:00.001-04:00

It's been a while since I have posted on this blog. So just to let you know that I'm still alive, this is what has been keeping me occupied. It's best summed up by a quote from the book Object Thinking by David West. This is a must read for any Rails developer who is following the object-oriented Rails culture.

Patterns most useful to object thinkers should be derived from the problem domain, just as objects are. They should facilitate thinking about co-ordination and scripting of objects or about useful ways of assembling objects into components or applications. They could be considered Alexandrian patterns. Few of the patterns (about 6 of the 23) presented in the GoF book satisfy this demand. Martin Fowler’s book on Analysis Patterns presents examples derived from a domain and is much closer to Alexander’s intent than the GoF book.

My intent is to post more on Domain Patterns in a Rails context in the near future. We'll see.

Testing Terminology: Spies, Stubs and Mocks

2012-03-09T10:48:00.001-05:00

When referring to the definitions of Spies, Stubs and Mocks I like to return to XUnit Test Patterns:

Test Spy: "We use a Test Double to capture the indirect output calls made to another component by the SUT for later verification by the test."
Test Stub: "We replace a real object with a test-specific object that feeds the desired indirect inputs into the SUT."
Mock Object: "We replace an object the SUT depends on with a test-specific object that verifies it is being used correctly by the SUT."

You may have noticed that a Spy and Mock seem to have similar definitions, and do serve similar purposes, however Mocks specify expectations up-front and don't require assertions in contrast to Spies, that verify after the fact. Here's an example that compares Rspec Mocks with Bourne's Spies:

SUT is an abbreviation for System Under Test.

describe Transfer, "using Rspec Mock" do
  it "deposits amount into destination account" do                                            
    source_account      = stub("source account", withdraw: 10)
    destination_account = mock("destination_account")

    destination_account.should_receive(:deposit).with(10)

    transfer = Transfer.new(source_account, destination_account)    
    transfer.call
  end                                             
end

describe Transfer, "using Bourne Spy" do
  it "deposits amount into destination account" do                                            
    source_account      = stub("source account", withdraw: 10)
    destination_account = mock("destination_account")

    transfer = Transfer.new(source_account, destination_account)    
    transfer.call 
    
    destination_account.should have_received(:deposit).with(10) 
  end                                             
end

The above patterns are collectively know as Test Doubles: "We replace a component on which the SUT depends with a test-specific equivalent." Rspec's built-in mocking library includes a double method/alias, see An Example using RSpec double, mock, and stub.

Double-Ruby (RR) is another example of a test double framework implemented in Ruby.

Heads up: Use spork-rails if you want to use spork 1.0rc in your Rails project

2012-02-12T08:35:00.001-05:00

If you are using Spork 1.0rc in your Rails project and wondering why your controllers etc are not reloading, it's because this functionality has been extracted to the spork-rails plugin gem. Remove the spork reference from your Gem file and add 'spork-rails' instead. spork-rails will include spork 1.0rc as a dependency. This follows the convention for other gems such as rspec-rails and factory_girl_rails. Note spork-rails follows the versioning of minor Rails versions. For example, the current version is 3.2.0, compatible with Rails 3.2.x down to 3.0.0.

Some rules to remember when writing Ember.js code

2012-01-03T10:11:00.001-05:00

Display logic only goes in the view layer
Never modify the DOM in View API
App logic only goes in the controller layer
Limit custom code in the controller
Domain logic only goes in the model layer
Server calls belong to the model layer
Only cross layers going up (V -> C -> M)
Never observe across layers

From Sproutcore Training: Part 2 - Core Concepts

Your Rails Application is Missing a Domain Controller

2011-12-24T15:14:00.002-05:00

The mantra of Skinny Controller, Fat Model reminds us to keep our business logic in our models, not in Rails Action Controllers. We know Action Controllers, sub-classes of ActionController::Base, are only responsible for delegating service requests to the domain layer. These models, which encapsulate this business logic, forming the domain layer, represent entities such as a person, place, event or thing. They are often, but not always, mapped directly to database tables through the inheritance of ActiveRecord::Base. When we develop our domain layer for our complex Rails application, purely with models representing entities, we encounter two problems:

Incoherent domain API

When Action Controllers interact with model entities directly, the API to the domain layer becomes clouded. It is unclear what services the domain layer offers and how the UI should request those services. Rail’s ActiveRecord exasperates the issue, for example, there are several ways to create and update model entities and their associations.

Bloated domain models

Business logic that is workflow-oriented involving multiple entities is assigned to a single entity, bloating it’s responsibilities. It becomes difficult to differentiate the entities in the domainrepresenting what the system is, from the use cases or workflow representing what the system does¹.

The solution is a Domain Controller. A Domain Controller is responsible for co-ordinating service requests from your Rails Action Controllers. A Domain Controller can come in two flavours, a facade or a use case.

A clarification on terminology: Throughout this blog post I will refer to the typical Rails model as a Model Entity, meaning a model that represents a person, place, event or thing.

Facade Controller

A Facade Controller represents the overall system that encapsulates the domain layer. For example a Catalog object can act as facade for the domain layer containing taxonomies, taxons, product groups, products and variants.

Without the Facade Controller, our service requests to the domain typically look like this:

Product.active
Taxon.active.find(1)
Product.create(:name => 'Ruby Meta-Programming')

With a Facade Controller instance, in this case, a catalog object, service requests appear as the following, delegating to the appropriate Model Entities:

catalog.fetch_products
catalog.fetch_taxon(1)
catalog.create_product(:name => 'Ruby Meta-Programming')

The Facade Controller provides a clear, explicit interface into the catalog domain layer that a programmer can grok within seconds.

Use Case Controller

A Use Case Controller is useful for more complex workflows. They are also helpful when a Facade becomes bloated and you wish to split the incoming service requests across multiple Domain Controllers. It’s important to note, you can use more than one Domain Controller for your application.

Let’s look at an example. The code below represents the processing of a Payroll². Often this type of workflow logic gets placed in a Model Entity that it doesn’t belong to or worst, left in a Rails Action Controller.

date = Date.today
employees = Employee.active
employees.each do |e|
  if e.pay_date?(date)
    pc = PayCheck.new(e.calculate_pay(date))
    e.send_pay(pc)
  end
end

So what object is responsible for this workflow logic? We know a Rails Action Controller isn’t a candidate. Its responsibility is to handle HTTP requests and delegate to the domain layer. Neither the models Employee or PayCheck are valid candidates. They represents the entities in our domain layer. Therefore we, require a new object PayDayService to encapsulate the logic, a Use Case Controller.

class PayDayService
    def initialize(date=Date.now)
      @date = date
    end

    def call
      Employee.active.each do |e|
        if e.pay_date?(@date)
          pc = PayCheck.new(e.calculate_pay(@date))
          e.send_pay(pc)
        end
      end
    end
  end

The benefit of this approach is that we have encapsulated this workflow logic without bloating existing Model Entities and allows the reuse of this logic in different contexts.

Domain Controllers in a Rails Application

When an application has multiple Domain Controllers I place them in a dedicated directory under app called services to keep them separate from the Model entities in app/models. This helps communicate that Rails Action Controllers should delegate to the Domain Controllers, not directly to Model Entities. The Domain Controllers and Model Entities together, represent the domain layer of the system. I have also discussed extracting the entire domain layer from the Rails framework, but that’s another discussion. Let’s keep this blog post civil for now!

I hope the Domain Controller pattern provides you with another tool for modelling your domain, reduces the coupling with the UI, and provides a clean API to your application logic.

Footnotes:

“What-the-system-is” and “What-the-system-does” terminology is from the book Lean Architecture by James O. Coplien and Gertrud Bjørnvig.
Logic based on the Payroll case study in Robert Martin’s Agile Software Development.

An Example using RSpec double, mock, and stub

2011-12-21T15:30:00.000-05:00

This is a follow-up post for RSpec double, mock, and stub from earlier this year. A reader asked for an example code to illustrate the various double aliases in RSpec.

For this example we will spec a Transfer class that encapsulates the use case of transferring an amount between two accounts, the source account and destination account. The Transfer is the subject of our examples, while the source and destination accounts are the collaborators.

In the spec below, the first example "should decrease source amount by 10", specifies the interaction for the source account, hence the use of the mock to generate the test double. In this example, the destination account is treated as a secondary collaborator, as we are focusing on the role of the source account. Any object can play the role of the source account, as long as it responds to the #decrease method.

In the second example "should increase destination account by 10", the destination account is the primary collaborator. The use of mock to generate the source account communicates this intent.

describe Transfer do
  context "transfer with amount of 10" do
    it "should decrease source account by 10" do
      source_account      = mock('source account')
      destination_account = stub('destination_account').as_null_object
    
      source_account.should_receive('decrease').with(10)
    
      transfer = Transfer.new(source_account, destination_account, 10)
      transfer.call
    end

    it "should increase destination account by 10" do
      source_account      = stub('source account').as_null_object
      destination_account = mock('destination_account')
    
      destination_account.should_receive('increase').with(10)
    
      transfer = Transfer.new(source_account, destination_account, 10)
      transfer.call
    end
  end
end

However, there is some duplication in this spec which can be eliminated by moving the test doubles to let blocks. It's appropriate to use double here to generate the source and destination accounts as both play primary and secondary collaborators in the following examples. Below we stub the methods for each collaborator, then set expectations on those methods for the appropriate examples.

describe Transfer do
  context "transfer with amount of 10" do
    let(:source_account) { double('source account', :decrease => nil) }
    let(:destination_account) { double('destination_account', :increase => nil) }

    it "should decrease source account by 10" do
      source_account.should_receive('decrease').with(10)
    
      transfer = Transfer.new(source_account, destination_account, 10)
      transfer.call
    end

    it "should increase destination account by 10" do
      destination_account.should_receive('increase').with(10)
    
      transfer = Transfer.new(source_account, destination_account, 10)
      transfer.call
    end
  end
end

Update: Radoslav Stankov provides a cleaner refactoring of the spec.

The implementation of the transfer class may look something like this:

class Transfer
  def initialize(source_account, destination_account, amount)
    @source_account      = source_account
    @destination_account = destination_account
    @amount              = amount
  end
  
  def call
    # In a complete implementation, it would make sense to have the following 
    # lines wrapped in a transaction, but I wanted to keep this example simple
    #
    @source_account.decrease(amount)
    @destination_account.increase(amount)
  end
end

It's important to remember that double, mock, and stub all return an instance of RSpec::Mocks::Mock. While the concepts of mocking, (i.e. setting a method expectation), and stubbing are "method-level concepts"[1], the use of mock and stub can communicate which collaborator you are specifying the behaviour for.

[1] For a more complete discussion on this, checkout The RSpec Book.

Recent Launch: Yellow Bird Project Redesign

2011-12-21T14:17:00.004-05:00

Earlier this year, I upgraded the Yellow Bird Project, a Spree store, from a forked version pre v0.90.0 to v0.50.x. For for my final project of the year, I upgraded Yellow Bird Project to v0.70.x, along with the implementation of a UI redesign. Jenna Holcombe (Dynamo) did a great job moving the YBP look to a grid-based design, which Daniel Wright (Dynamo) implemented this in Sass/Compass.
Since the redesign initiative included an upgrade to the latest version of Spree, I decided to upgrade the existing site and deploy that to production, before launching the redesign. This allowed me to upgrade our custom extensions to work with 0.70.x and iron out any kinks in the new version. While this was a smoother process than the upgrade earlier this year, it was the first time I had deployed to Heroku's Cedar stack using Rails 3.1 and the asset pipeline. I'm a big advocate of breaking down a project, separating major changes, and getting changes pushed to production early, even it there is a little duplication in work. The separate pushes to production for the upgrade and the redesign reduced the risk of something really going haywire with pushing both of these at once.
The redesign benefited the application from a platform, merchandising, and coding perspectives:

Platform: While this initiative did not include a mobile version, the new grid-based design will allow us to cleanly develop a responsive design for mobile platforms in the future using media queries. Replacing hacks like Cufon with more modern technologies like web fonts just makes the UI code cleaner and performance snappier.
Merchandising: The store now fully utilizes Spree's powerful Taxonomy and Product Group features. This allows YBP to respond to different marketing initiates such as seasonal events, for example Warm Winter Wear.
Code: One of the cool things with this upgrade was the chance to refactor the code base. Shifting from ERB to Haml and plain CSS to Sass/Compass was a definitely a plus, however implementing a data model that capitalized Spree's catalog management was the biggest win. I was able to remove unnecessary extensions which simplified managing the products. YBP's Matthew Stotland is a code-savvy lad and appreciated the clean implementation. It's great to work on a project where the client appreciates the front-end as much as the code that drives it.

You can checkout the new design below, but better yet, visit the Yellow Bird Project and support a great cause.

Software Craftsmanship Goes Beyond Code

2011-11-17T22:08:00.001-05:00

Often the discussion of Software Craftsmanship is focused on code and tests. But don't forget about the other components that support your project:

Make sure your source control repository is organized. Don't leave dead branches lying around, left for another developer to work out if they have been merged or not; if they should be merged or not. Add a reference to your branch with the issue or story id from your tracker so a developer can read more about the intention of the branch.
And don't write commit messages that suck.
Keep your tracker up-to-date and lean. Don't mark stories as started when they haven't been. In reality, there should only be one story marked as started per developer on the project. Don't drag stories into the backlog just because you think they are a good idea. Keep the backlog lean, you only need a couple of weeks worth of stories to keep you going. Keep the rest in the icebox. Priorities are going to change.
Make sure it's easy for a developer to get started with your project. Have a README that guides a developer to get the dependencies and database setup, and remind them a test suite exists and how to run it. Obviously the more automated things are the better.

Caring needs to go beyond the code, it needs to include all the supporting components of your project. Of course there are other facets of professionalism we can list, but these are some practical details I have experienced recently. What components of a project, beyond code, that you wish developers would give more care to? Let me know in the comments.

Recent Launch: Mr. B's Gentlemen's Boutique for ALDO

2011-11-12T12:47:00.002-05:00

Back in September, I had the pleasure working with Alex Nemroff (Interactive Designer) and Daniel Wright (Front-end Developer) at Dynamo on Mr. B's Gentlemen's Boutique, a new product line for ALDO Shoes. A tribute to Aldo Bensadoun, this project is dear to everybody's hearts at ALDO and I think we have made them proud. I was responsible for the setup and customizations to Refinery CMS, including the development of an extension to manage the catalog.

I always have a great timing working on projects Alex leads. He always gets us involved in all aspects of the project and the end result really does feel like a team effort. My favourite times throughout the project is sitting down together at the end of an iteration, reviewing what we have done, and what we can do to improve it in the next iteration. And it doesn't hurt to have a power house like Daniel on the front-end. He really knows his stuff.

Below is a video of the post-mortem at Dynamo, where Alex and myself talk about lessons learned throughout project. Unfortunately, we didn't capture the screen when recording this session (whoops, working on that), but I think you will find the discussion insightful. Please checkout the screenshots below, better yet, visit the site and checkout some beautiful shoes.

Post-Mortem at Dynamo

Screenshots

Rails is Not Your Application

2011-10-22T16:59:00.001-04:00

Background: The Beginnings of My Obsession with Application Architecture and Domain Modelling

Last year I was involved in my most complex Ruby on Rails application to date that is now 23K lines of model code, 14K lines of controller code, and 4.5K lines of lib code. You get the point, let's now worry about the view code. It was during this project that I observed the pain of working within the bounds of how we typically build Rails applications. Did I mention it was slow to develop and test? During that contract and ever since, I have been obsessing about application architecture and domain modelling.

Establish an Application Interface with a Service Layer

During the time I was working on said application, I introduced the concept of Services (in the early stages I called them managers). Although a lot of domain logic was pushed into the models, there was too much application logic in the controllers. Services, co-ordinating domain models, allowed me to extract that application logic to really keep the controllers thin. I'm not sure exactly sure what prompted me to start using Service objects, but after the fact I found references to them in Martin Fowler's Patterns of Enterprise Application Architecture (P of EAA). Other frameworks such as Grails also use Services, it even has a generator for them. Services resolves the discussion (started here) on where to trigger email notifications. Add them to your Services.

In P of EAA, Randy Stafford defines the Service Layer as:

"Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation."

And in a way, this definition helped me recognize another frustration I was having with how I (and most of the Rails community) was developing with Rails. There was no explicit application. Or rather, it was hard to define what the application was and hard to know how to interact with it. The application had no interface. My application was a ball of ActiveRecord objects.

Lots of Activity in the Rails Community Regarding Domain Modelling

I haven't been the only one thinking about application architecture and domain modelling. I'm not a unique snowflake. Others in our community have too: Mike Dietz from ThoughtWorks introduce me to DCI at RailsConf 2011, Andrzej Krzywda has been blogging about it before that, and Jim Gay has recently been blogging about it on this side of the pond. On another tact, Corey Haines has been been selling fast tests over the last few months. Hidden in that sales pitch of course, is a way to extract domain logic. Talking of extracting domain logic, Steve Klabnick has illustrated some practical examples.

These guys have kept me busy! I've been quietly researching this topic for over a year now. You can check out some of my tags on Delicious:

Extracting the Application from the Framework

Ok, time to finish up this post. All of the efforts describe above have been with the purpose of managing the application and domain logic in the software we build. It benefits us with faster tests and code that clearly communicates it's intent. And although the Service Layer was helping me define an interface to my application, I was only using them when my controllers methods/actions were getting heavy with application logic. Then last night, I watched the latest release of Clean Code from Uncle Bob that highlights the need to extract your application from the framework you use (he's been teasing me for a while on this topic). With my previous experience with Services, and my interest in DCI, Uncle Bob's guidance was the piece I was missing.

After taking his example pseudo code, and turning it into some Ruby/Rails example (more like snippet) I gleefully tweeted:

"Rails is not your application. It might be your views and data source, but it's not your application. Put your app in a Gem or under lib/."

I really like this approach a lot, the ability to test your application outside of the Rails stack is huge, and viewing Rails as a method to deliver my application will change the way I write code. Anyway here is the code that triggered the Tweet (see below). It's not polished, it doesn't execute, it's not 100% right, but boy it's got me thinking. It uses Services to represent Use Cases of the application, and roles containing domain logic that is mixed in contextually, extracted into a Gem, delivered via Rails. If you not a fan of the Gem idea, keep it name spaced under your lib directory.

Update: A clarification on putting your application in lib. I certainly don't mean to put it directly in lib. Name space it, lib/your_application; e.g. lib/pay_roll.

Now that I have let the code out of the bag, expect some more posts on this topic in the future where I work through and describe this code (and related ideas) in more detail.

References and tools for Memory Consumption in Rails

2011-10-17T15:26:00.001-04:00

It's not often that I need these, but when there's a Memory Consumption issue in a Rails application, these references and tools definitely come in handy:

Rails 3 References and Tools

Ruby on Rails Guides: Performance Testing Rails Applications
Debugging Ruby (Aman Gupta presentation at Rails Conf 2011)
Rack-Perftools Profiler
Rack-Bug (Rails 3 branch)

Some Older References and Tools

That's not a Memory Leak, it's Bloat (Engine Yard Blog Post)
Bleak House
Episode #20 - On The Edge - Part 2\
MemoryLogic
Oink
Rack-Bug

Recent Launch: Media Experts on Refinery CMS

2011-10-15T12:06:00.001-04:00

Media Experts is a top Canadian media planning and buying agency. During the summer, I was tasked with the first iteration of their website, integrating it with Refinery CMS (thanks Dynamo!). One of the joys of using Refinery, is the ease of extending it with engines to support custom content types. For example the experts page seen below contained structured, repetitive data that was not suited for a page tree hierarchy:

By generating a custom engine, I was able to easily integrate this structured data into the website, without any impact on the original design or the website's navigation. You can view how the individual experts are edited in the screen shot below:

Please checkout the Media Experts' website and view additional screenshots below:

Home Page

Portfolio Index

Yellow Bird Project Spree Upgrade

2011-10-09T16:28:00.002-04:00

During the spring, Dynamo asked me to upgrade the Yellow Bird Project to the latest version of Spree (at the time this was v0.50.2). The challenge for this project was managing the upgrade from a forked version of Spree, pre v0.9.0 back in 2009. One tool that was really useful was using Max OS X's FileMerge to compare database schemas, allowing me to determine what the new schema would and determine any naming conflicts with custom tables added previously.

The upgrade resulted in an application that can now be easily upgraded to future version of Spree and runs on a more stable, scalable platform thanks to Heroku.

The Yellow Bird Project is pretty cool - they work with a range of indie rock musicians to create some neat t-shirts that then benefit a charity chosen by the musicians themselves. So put away that ugly university hoodie and go get yourself some cool threads.

Recent Launch: de Gaspé Beaubien Foundation

2011-10-01T12:01:00.002-04:00

OK, hardly a recent launch, de Gaspé Beaubien Foundation was actually launched in April, but I'm a wee bit behind in posting some of the neat projects I have worked on this year. I'm determine to get this resolved over the next couple of weeks.

de Gaspé Beaubien Foundation's website provides a platform to communicate the families contribution to their communities and the broader society. I worked with the great team at Dynamo on this one: Bob Beck, creative director was responsible for brand identity and video direction, Jenna Holcombe site design, and I was responsible for front-end development and CMS integration.

This is the first project I have used RefineryCMS, a Ruby on Rails-based Content Management System. While I have been a big fan of Radiant CMS, I like RefineryCMS for it's polish integrated interface. It worked great for this project, but I would use Radiant when a project has more complex requirements. The front-end was developed using HTML5 and CSS3. CSS was generated using Compass and Sass. Compass' CSS3 helpers are a real help abstracting away the mess of vendor extensions, and the CSS3 PIE integration giving older version of IE CSS3 capabilities is invaluable. All video is presented using HTML5, with a Flash fallback, all handled seamlessly by JW Player.

Check out the screenshots below and please visit the site to find out the great work de Gaspé Beaubien Foundation is doing.

My Ruby on Rails Development Environment

2011-08-06T16:32:00.007-04:00

Click image to enlarge

Gotcha with testing expected params with Bourne/Mocha in Rails Controller

2011-07-30T10:19:00.001-04:00

This is something that always trips me up using Bourne (a fork of Mocha, a Ruby mocking and stubbing library) to test expected params in a Rails Controller. Take this spec:

context "with filter" do
  before do
    get :index, :search => {:brand_id => '1'}
  end

  it 'should find latest search results' do
    SearchResult.should have_received(:latest).with('brand_id' => '1')
  end
end

This test fails, but what if I tried this:

context "with filter" do
  before do
    get :index, :search => {:brand_id => '1'}
  end

  it 'should find latest search results' do
    SearchResult.should have_received(:latest).with(:brand_id => '1')
  end
end

This will fail. Note I am now checking the parameters passed using symbols for the keys. I receive the following error:


Failure/Error: SearchResult.should have_received(:latest).with(has_entry(:brand_id => '1'))
     expected exactly once, not yet invoked: SearchResult(id: integer, search_id: integer, body: text, source: text, url: string, created_at: datetime, updated_at: datetime).latest(has_entry(:brand_id => '1'))

This is because the params that are passed to the controller have keys as strings rather than symbols:

{'brand_id' => '1'}

So what's the solution? I could actually use HashWithIndifferentAccess which gives access to a Hash using strings or symbols for keys. This is in fact the class that is used for the params hash in the controller:

it 'should find latest search results' do
    SearchResult.should have_received(:latest).with(HashWithIndifferentAccess.new(:brand_id => '1'))
  end

Or, as a standard practice, when dealing with parameters passed to a controller within a spec, always use strings:

context "with filter" do
  before do
    get :index, 'search' => {'brand_id' => '1'}
  end

  it 'should find latest search results' do
    SearchResult.should have_received(:latest).with('brand_id' => '1')
  end
end

I think this is a lot simpler, cleaner. Interestingly, I didn't pass the brand_id as a Fixnum:

before do
    get :index, 'search' => {'brand_id' => 1}
  end

I would have got the same error:

Failure/Error: SearchResult.should have_received(:latest).with('brand_id' => 1)
     expected exactly once, not yet invoked: SearchResult(id: integer, search_id: integer, body: text, source: text, url: string, created_at: datetime, updated_at: datetime).latest('brand_id' => 1)

As the brand_id is present in the hash as a String, not a Fixnum.

Upgrade RVM and Ruby 1.9.2p290

2011-07-30T09:22:00.002-04:00

I've been a little lazy and haven't updated my RVM installation (version 1.1.3, now 1.6.31) for a while and have been stuck on Ruby 1.9.2p0. This morning I upgraded, here's what I did:

$ rvm get head
$ rvm reload
$ rvm install 1.9.2-p290
$ rvm upgrade 1.9.2-p0 1.9.2-p290

Hmm… Got some errors, here's the output:

Are you sure you wish to upgrade from ruby-1.9.2-p0 to     ruby-1.9.2-p290? (Y/n): y
Migrating gems from ruby-1.9.2-p0 to ruby-1.9.2-p290
Are you sure you wish to MOVE gems from ruby-1.9.2-p0 to ruby-1.9.2-p290?
This will overwrite existing gems in ruby-1.9.2-p290 and remove them from ruby-1.9.2-p0 (Y/n): y
Moving gemsets...
Moving ruby-1.9.2-p0 to ruby-1.9.2-p290
Making gemset ruby-1.9.2-p290 pristine.
ERROR: Error running 'rvm gemset pristine' under ,
please read /Volumes/Data/Users/nicholas/.rvm/log//gemset.pristine.log
Moving ruby-1.9.2-p0@brandizzle to ruby-1.9.2-p290@brandizzle
Making gemset ruby-1.9.2-p290@brandizzle pristine.
ERROR: Error running 'rvm gemset pristine' under ,
please read /Volumes/Data/Users/nicholas/.rvm/log//gemset.pristine.log
Moving ruby-1.9.2-p0@default to ruby-1.9.2-p290@default
Making gemset ruby-1.9.2-p290@default pristine.
ERROR: Error running 'rvm gemset pristine' under ,
please read /Volumes/Data/Users/nicholas/.rvm/log//gemset.pristine.log
Moving ruby-1.9.2-p0@global to ruby-1.9.2-p290@global
Making gemset ruby-1.9.2-p290@global pristine.
ERROR: Error running 'rvm gemset pristine' under ,
please read /Volumes/Data/Users/nicholas/.rvm/log//gemset.pristine.log
Moving ruby-1.9.2-p0@peters-guide to ruby-1.9.2-p290@peters-guide
Making gemset ruby-1.9.2-p290@peters-guide pristine.
ERROR: Error running 'rvm gemset pristine' under ,
please read /Volumes/Data/Users/nicholas/.rvm/log//gemset.pristine.log
Moving ruby-1.9.2-p0@refinery to ruby-1.9.2-p290@refinery
Making gemset ruby-1.9.2-p290@refinery pristine.
ERROR: Error running 'rvm gemset pristine' under ,
please read /Volumes/Data/Users/nicholas/.rvm/log//gemset.pristine.log
Moving ruby-1.9.2-p0@shoedazzle to ruby-1.9.2-p290@shoedazzle
Making gemset ruby-1.9.2-p290@shoedazzle pristine.
ERROR: Error running 'rvm gemset pristine' under ,
please read /Volumes/Data/Users/nicholas/.rvm/log//gemset.pristine.log
Moving ruby-1.9.2-p0@spree to ruby-1.9.2-p290@spree
Making gemset ruby-1.9.2-p290@spree pristine.
ERROR: Error running 'rvm gemset pristine' under ,
please read /Volumes/Data/Users/nicholas/.rvm/log//gemset.pristine.log
Moving ruby-1.9.2-p0@sproutcore to ruby-1.9.2-p290@sproutcore
Making gemset ruby-1.9.2-p290@sproutcore pristine.
ERROR: Error running 'rvm gemset pristine' under ,
please read /Volumes/Data/Users/nicholas/.rvm/log//gemset.pristine.log
Moving ruby-1.9.2-p0@storeworks to ruby-1.9.2-p290@storeworks
Making gemset ruby-1.9.2-p290@storeworks pristine.
ERROR: Error running 'rvm gemset pristine' under ,
please read /Volumes/Data/Users/nicholas/.rvm/log//gemset.pristine.log
Do you wish to move over aliases? (Y/n): y
Updating alias default to point to ruby-1.9.2-p290@default
Do you wish to move over wrappers? (Y/n): Y
Do you also wish to completely remove ruby-1.9.2-p0 (inc. archive)? (Y/n): Y
ERROR: Error running 'rvm remove ruby-1.9.2-p0 --archive --gems' under ,
please read /Volumes/Data/Users/nicholas/.rvm/log//rvm.remove.log
Successfully migrated ruby-1.9.2-p0 to ruby-1.9.2-p290
Upgrade complete!

Note that I opted to move over aliases, wrappers and completely remove my old ruby-1.9.2-p0.

Looking at the gemset.pristine.log I had the following errors for each gemset:

[2011-07-30 09:08:04] rvm gemset pristine # under ruby-1.9.2-p290@brandizzle
/Volumes/Data/Users/nicholas/.rvm/scripts/functions/environment: line 235: rvm: command not found

So for each gemset I executed the following:

rvm gemset pristine

This seemed to work fine. Next, I checked out the errors in rvm.remove.log:

[2011-07-30 09:08:32] rvm remove ruby-1.9.2-p0 --archive --gems # under ruby-1.9.2-p0
/Volumes/Data/Users/nicholas/.rvm/scripts/functions/environment: line 235: rvm: command not found

Looks like the remove of my old 1.9.2 install failed, so I ran it manually:

rvm remove ruby-1.9.2-p0 --archive --gems

Boom! Everything is updated and working.

Basic Heroku addons I always use for production websites

2011-07-28T17:00:00.002-04:00


heroku addons

cron:daily
custom_domains:basic
logging:expanded
memcache:5mb
newrelic:standard
pgbackups:auto-month
sendgrid:basic
shared-database:5mb

Git: Push a local branch to a remote master

2011-07-26T15:05:00.001-04:00

git push heroku yourbranch:master

Credit Heroku