Blog

Thursday, December 30, 2010

Specifying Behaviour vs Specifying Implementation

At the JRubyConf in Columbus, Ohio last October, Jim Weirich presented "Testing – Why Don't We Do It Like This?". At the end of the presentation he suggested asking two questions to ensure our tests are specifying behaviour rather than implementation:

  1. If I wanted to use this software in my project, what behaviours are important to me?
  2. Could I write this software from scratch using only the tests/specs as guidance?

These are definitely useful questions to ask, rather than blindly writing specs to simply get 100% test coverage. Check the entire presentation below:

Testing – Why Don't We Do It Like This? – Jim Weirich from Engine Yard on Vimeo.

Wednesday, December 29, 2010

Recent Project: Wayne Gretzky Estates

Not all projects need to be complicated! This was one of the simpler, low stress projects (yes they do exist!) of the year, working with creative director Bob Beck at Dynamo. I'm not a huge hockey fan, but who wouldn't want to work on a project with The Great One's name on it. For the tech geeks, Wayne Gretzky Estates is an online store developed using Spree, a Ruby on Rails e-commerce platform. Screen shots below.

Catalog

04-catalog.jpg

Gallery

Gallery

News Index

News Index

News Article

News Article

Monday, December 13, 2010

ShoeDazzle featured on TechCrunch

I had the pleasure working with ShoeDazzle in Los Angeles this summer when they re-developed their shopping platform. ShoeDazzle offers a personalized style service with a celebrity flair. For a monthly subscription fee, you have a choice of a pair of shoes, handbag or jewelry from you own, personalized catalog, handpicked by celebrity stylists. Fun!

This month ShoeDazzle is featured on TechCrunch and described by Jeremy Liew "the most underrated [company] in his portfolio". Checkout the interview below with Brian Lee.

Monday, December 6, 2010

Truncate HTML in Rails

After a bit of searching for a truncation helper for HTML, I found this great gem: truncate_html. It maintains the HTML tags (i.e doesn't strip them out) and supports word boundaries. Nice! Oh, and supports Rails 2.x and 3.x.

Sunday, December 5, 2010

The Mocking Debate Continues

Nick Gauthier recently blogged about "Everything that is wrong with mocking, bdd, and rspec". Nicks' a smart guy, you just need to check out his presentations to understand that. In his post he attempts to demonstrate the brittleness of mocking. While his arguments appear sound at first glance, Pat Maddox presents a well articulated argument. Reading his points on collaborators and protocols gave me a clearer understanding of BDD. I repeat here, but encourage you to check out the comments check out the comments. It's a great debate.

The mock-based example specifies the interaction with the collaborator. It demonstrates that you can pass in any object that responds to #puts(str) and expect it to work.

Your refactoring is valid -- when the output object responds to #puts, #write, #print, and #<<, and implements them all in basically the same way.

You are free to change the internals of a method however you want, but remember that certain changes will have broader-reaching effects than others. Changing how you build up the string to, say, an array of strings that then get joined, should certainly be encapsulated. Changing how you call collaborators is a totally different thing -- you're changing the contract, potentially in a way that's incompatible with existing clients.

Focused examples (or unit tests, or microtests, or whatever) help answer the question, "what do I need to know to use this code?" When there is a collaborator involved, one of the key things to know is the protocol that the collaborator must adhere to. An interaction-based example makes that protocol explicit. Moreover, it establishes a checkpoint. Should you decide to call #write instead of #puts, you have to consider the possible implications to existing code.

I understand where you're coming from. When you run the program, there is no externally visible difference in behavior. That is why we tend to separate the duties of checking program behavior into acceptance tests. Your unit tests then become a place for you to check an object's correctness, which includes its own logic and its interactions with other objects. Don't assume that because the external behavior of the program stays the same, that the behavior internal to objects has stayed the same as well.

Friday, December 3, 2010

Avoid a bloated slug on Heroku by configuring Bundler

This tip was outlined in Heroku's December email newsletter, and wanted to repeat here. It's a must know. You don't need your development and test gems in production, so configure your Heroku application accordingly:


Smaller slug, faster installation and compile times, nice.

Please note this blog is no longer maintained. Please visit CivilCode Inc - Custom Software Development.