No One Is Reading

The truth is that no one is reading this. Maybe they will one day, but not right now. Why don’t I think about this more when I write? I love the romantic idea of Marcus Aurelius writing a journal for himself, never suspecting anyone to read it let alone build up a philosophy around it. Did I just compare myself to Marcus Aurelius… no I didn’t. Well maybe in that I don’t expect anyone to read this.

So often I get in my own way thinking that my legions of Twitter fans (1,203) of them, and that my friends at work (they don’t know this exists) will follow this and make me reflect on everything that I write. The truth is no one is reading.

This is liberating and not sad at all, in fact, when people start to read everything will change.

Last Home

It all started in Posterous. Blogging was easy. Then things got complicated. Along the way it became and harder for me to decide where to blog. A brief history looks like:

  • Wordpress
  • Blogger
  • Posterous
  • Wordpress
  • Zeus
  • Custom Rails app
  • Custom Merb app
  • Custom Sinatra app
  • Django
  • Custom Rails app
  • Jekyll
  • Octopress
  • Jekyll
  • Custom Rails app
  • Wordpress
  • HTML + Forge
  • Medium
  • Wordpress
  • Custom Rails app
  • Hugo

The biggest debate I’ve had is Medium vs. self-hosted. I’ve realized that these are just pencil problems. Problems that don’t really mean anything, just an advanced form of procrastination.

So here we go. The last home for me, at least for now.


Colour: a Fun Way to Enhance User Experience

Bruce Mau’s Optimism Palette

Recently I was hired to do some contracting work with Bruce Mau Design and learned a valuable lesson about colors and websites.

One of BMD’s designers Jim Shedden asked me to update their site so that when the user navigated to a new page the colour of certain elements would change. At first I wasn’t totally sold on the idea but gladly accepted the task.

It was a pretty cut and dry type of task that required some javascript. Since their site does not use any dynamic page generation and does not have any server side scripting this was the best option. Let it be known though that everything you do with CSS in a dynamic server context should be done on the server so that there is no latency when the page refreshes.

On the top right hand side of this post you can see the source image that Jim sent me. These were the colours that he wanted to use whenever the page would refresh.

First thing to point out is the beauty of the colours. They are very well chosen and complement each other very well. This is why you hire designers and pay them very well, there is an art and science that go into choosing good colours and creating a good design, luckily, many great designers have an eye or intuition for what works so don’t need to be taught the science.

Now onto the javascript. Even though this task really didn’t require a library, I still opted to use jQuery since… well… it’s awesome. The basic idea was to create a an array of colours and pick one randomly each time a page was loaded. The colour would then be applied to an array of jQuery CSS selectors and the desired effect would be a complete colour change each time. Here is an idea of what the javascript code looks like in production.

// jQuery Colourizer
// Kent Fenwick 2009
// Use it when you want to add a splash of random colour to your page

// Create the colour array
var color_array = ["#ce521d","#ca4b89","#006b89","#3e2d7e","#61902c", "#faa31a", "#6e002a", "#4981b3",
                   "#980069", "#2dacbf", "#ee1d25", "#9cb46f", "#9a869e", "#ee008c", "#00a895",
                   "#7b181a", "#ffd63c", "#b46638", "#bcd634", "#f4ea00", "#32b6c0", "#e8ac1c",
                   "#ea2d50", "#3c7022", "#0085cc", "#97C83B"];
// Pick a random colour of the array
var random_color = color_array[Math.floor(Math.random()*color_array.length)];
// Choose some jQuery CSS selectors of elements whose colour you want to change
var colour_selectors = [".manifesto li", "", "#books h2", " a", ".news-item h4 a"];
// Choose some jQuery CSS selectors of elements whose background colour you want to change
var bg_colour_selectors = ["#navigation_bar", "#navigation li"];
// loop over the Colour Selectors and apply the new random color
jQuery.each(colour_selectors, function(i,val){
	// use each val and apply the colour css property

// loop over the Background Colour Selectors and apply the new random color
jQuery.each(bg_colour_selectors, function(i,val){
	// use each val and apply the background colour css property

You start by declaring some colours, pick your CSS selectors and then use jQuery’s iterator function to apply the desired CSS property to the specified page elements. Easy right!

There are some gotchas, you want to make sure you optimize which CSS selectors you use so that you don’t end up having CSS conflicts. In my case there were quite a few properties in the CSS files that had to be cleaned up before this script would work as it was supposed to. Also, if your page is really big or your connection is really slow there is a chance that the script will take a second to run. This is why you should do it dynamically on the server if you can. However, there is something to be said for using fun little scripts like this to add personality to your web page. It also degrades nicely so if the user has JS disabled, they will see the default colours from the CSS files which isn’t bad at all.

The final effect can be viewed by going to and exploring the site to see the colours change.

This was a very simple idea with a relatively simple implementation that goes a long way to providing character and personality to a website. I think this is one of the easiest ways to have fun on the page and keep your users in anticipation as they wonder what colour they are going to experience next. Thanks Jim and Bruce Mau for asking me to do it for you. It was great fun.

PS: I will be releasing this as a jQuery plugin in a little bit with some improvements and other configurations options so if you have any ideas or are a jQuery plugin enthusiast I would love to hear from you.

Thanks very much,

Take care,


EC2 Oh EC2 How I Wish I Knew More About You

I have spent the better part of Sunday afternoon trying to decide what the future of hosting holds for me.

I haven’t made any decisions yet, but I am leaning towards EC2 over just about anything else. My problem is that I often find myself hosting a bunch of small scale static sites as well as high performance Rails applications. This means that Engine Yard Solo really isn’t for me unless I want to drop down into Rack which is a big possibility. I need the ability to roll out an apache host for a little site. Maybe even something with php… am I trying to do too much? Also, how many sites can fit on an instance? I know that a high performance application will need it’s own instance or more, but can I host multiple sites on a single instance?

My only beef is that I feel like I shouldn’t go with Solo. As much as I love Engine Yard and what they have built, I feel like I can figure EC2 out myself with Chef and roll my own custom solution that will suit my needs and in the end be much cheaper. My problem isn’t that I don’t like paying for quality services because I do, my problem is that I feel like I am coping out by not trying it myself.

However, I have a little problem… I seem to do this a lot. A few months ago I was pretty close to writing my own blogging engine since I wasn’t happy with everything out there, my buddy Nick talked some sense into me, but at the end of the day I was really considering it. Now I am stuck wondering if I am doing the same thing again with hosting. Am I making this more complicated than it should or has to be? Maybe it’s worth spending more money per month if it means never having to dive into EC2 logs etc… But there is some part of me that always wants to have control of what I am paying for / deploying. I feel like I should learn EC2 because it will only get more popular as time goes on and I don’t want to regret not putting the time in now to learn it.

Does anyone have any opinions on this? Has anyone been in the same situation?

I am planning on calling Engine Yard tomorrow or Tuesday and talk with them about some of my options and how flexible their Solo packages are. It’s all really up in the air right now. I feel like I must sleep on it.

Thanks for listening, I will make sure to post again after I talk to Engine Yard and take a look at ec2onrails, chef/ec2 etc. For the moment, I am at Linode, Slicehost, University of Toronto etc… my hosting is all over the place. I am really looking to consolidate.

Thanks again,


Testing Is a Journey Not a Destination

The RSpec Book

A while back… back in November I wrote a post about using Cucumber, RSpec and Behavior Driven Development (BDD) in a Rails project. To sum it up, I was one of the fortunate people who got to see Aslak unveil cucumber for the first time at Agile 2008 in Toronto. It was very well received but I don’t think people really got it. I sure didn’t. I met up with him the following day to go into it in a little more depth. He was nice enough to show me the more Rails centric stuff, but there were some broken features etc, since he had literally just finished writing it. Anyway, I came home feeling pumped from that conference. I felt special since I had been privy to some information that not many people knew about and I was eager to master it. This is not what happened.

In November, I went to Denver for the Pragmatic Studio’s Advanced Rails Studio and learned a lot. I learned a lot more about testing and I also learned about Shoulda. I got the impression from the Pragmatic guys that they weren’t using RSpec and Cucumber so the sheep in me felt like maybe I shouldn’t either. I started playing around with Shoulda and adopted it for my new projects. I loved it. I forgot about Cucumber for a while, stopping every once and I while to watch a screencast or a presentation, but for the most part I stopped using it.

That was until last week.

I am currently re-writing Prospectlinker and have decided that no matter how tempting it is to deploy without some tests, it’s not what I am going to do. I have been bitten too many times passing off tests that don’t seem to matter until you do something like update Rails and spend 2 days finding all of the broken links… anyway, I don’t think I need to convince anyone that testing is good. Joel Spolsky and Jeff Atwood might be the only two developers I have heard talk about why not to test, but they are very smart guys so I am sure they have their reasons. Regardless, I resonate with testing.

I test therefore I code.

Or is it, “I code therefore I test”… anyway, the point of this post is this.: Go back and look at Cucumber and RSpec right now! Seriously, you will be blown away by how much has changed and how much hasn’t, both of which a sign of good software. Also, get your team involved. I recently scared my team to death with a HUGE email explaining Cucumber and how I want them to help me make the code better by writing scenarios and features. I know that they might not get into it right away, but slowly and surely as they get more comfortable with it, they will be writing the features for me and I will be making sure they all pass.

However, I know that it can be daunting. Testing, especially in Rails is like a cult. It can feel like if you didn’t start a while ago you have missed the boat. This is not the case, in fact, there is a boat waiting just for you, and the journey it will take you on is both fun and rewarding, here are some pointers for navigating the course.

  1. Start small

Testing is a whole side of programming that some never look at. Many talk about it, but very few actually do it and even fewer do it well and regularly. Don’t go and re-test your entire application, start small. Start with a few methods. Using TDD / BDD is a great development tool but you don’t have to do it at the beginning if it seems to intimidating. Do the opposite. Write a method, then write a test to make sure it does what you want it to. Do this for a while and you will see why Kent Beck invented TDD, it’s how you naturally want to write code as you get better and more comfortable with testing. TDD becomes very natural with time and patience.

  1. Make it your discipline

The word discipline seems to have different meanings depending on who you talk to but for me, it’s all about doing something even if you are less than thrilled about doing it. For example, I meditate twice a day for 20 minutes. At first, this was hard since sometimes I was tired and didn’t always have the energy to do it. However, by applying a simple discipline, it became natural and now flows as part of my day. You can do the same thing for testing. In fact this is exactly what I did. I made a point to start testing each new application or new line of code I wrote. At the beginning it was hard since the payoff wasn’t always visible, however, the payoff is great so stick with it.

  1. Testing is a journey, not a destination

Testing is not a drop in solution. I have talked to some people who claim that they learned how to test in a weekend, I don’t really believe them when they tell me this. That’s like saying that you read Agile Development with Rails and built the depot application so now you know Rails. You might know about Rails, but you don’t know Rails yet. Software like testing is about the experience of doing rather than of watching or copying. Think of testing as a journey not a destination.

Understand that by practicing testing you are making your software a little better. Even if you write the worst tests imaginable, you are still thinking about your code in a different way. This in itself is very profound and will have a trans-formative effect on how you write code and even how you think about writing code in the future. Try to remove your ego and that annoying voice in your head telling you that you should have learned this stuff months ago, that you are a sub prime programmer since you don’t know all there is to know about testing. That voice is just trying to protect you but don’t listen to it. Let it go and embrace the experience of making your code better. When you don’t resist not only will love it more, but you write better code naturally without thinking.4. Have fun with it

Make testing a game. This what I used to do at the beginning when I was first learning how to test. Find a friend who is willing to review your code and give you a grade, or write some code with a test and then write some without a test. Get someone to grade which one is better, or if you can’t find someone, send it to me and I will grade it. Chances are the one that was done with TDD/BDD will be better or cleaner than the latter.

  1. Ask for help

Go and download your favorite IRC client (looks like Colloquy is winning for the Mac) and connect to and join the #cucumber #rails and #rspec rooms. I have learned so much about testing from dchelimsky (David Chelimsky) in those rooms that it makes me smile :) The whole team behind these tools are great people and just like you, are learning all the time.

For those that want to help themselves, you really should buy the RSpec book too (see top image). The Pragmatic Programmers have a way of finding the most amazing talents and produce the highest quality software books. If you are going to buy it, buy directly from them instead of through Amazon, that way they get to keep all of the profits and use them to make more amazing books.

Well, I think that about does it.

I am certainly not the expert on testing, but I have been doing it enough to know my way around. Also, having been recently recharged into Cucumber, I am looking forward to learning more and more until it becomes as natural as writing Rails.

Feel free to ask questions in the comments, or contact me directly if you have any questions, comments or concerns. If I can’t answer it, I am sure that I will find someone who can.

A big thank you to everyone who has worked on these tools and continues to make them better, we are very lucky to have you and your software.