Eyefodder -

Code Coverage — a simple Rails example

By Paul Barnes-Hoggett | Published: September 18, 2014

My tests are my safety net. With them I can refactor with confidence, knowing that I’m keeping the functionality I intended. With them, I can grow my codebase, knowing that I’m not introducing regression errors. How do I have confidence that my safety net is good enough? One metric I can use to help with this is code coverage. It answers the question “When I run my tests, how much of my application code executed?”. It’s a somewhat crude metric—telling me how broad the net is not how strong—but it’s a good place to start. Fortunately, setting it up on a rails project is pretty simple.

See how happy people are when they have a safety net?

Posted in Agile Software Development, Continuous Integration, Engineering, Quality Software, Rails, Ruby, Software Craftsmanship, Test Driven Development | Leave a comment

Getting Growl notifications from your Virtual Machine

By Paul Barnes-Hoggett | Published: September 7, 2014

As I develop I have Guard running in the background, executing my tests when things change. But I often don’t have the Terminal window front and centre, so I like to have Growl notifications for my test results. Setting up Growl to push notifications from the Virtual Machine to the host is a little tricky, so here’s a simple example to show how to do it.

Growl isn’t as hairy as ‘old Ephraim’ but is probably more useful

Posted in Agile Software Development, Engineering, Quality Software, Rails, Ruby, Software Craftsmanship, Test Driven Development | 1 Response

Using Spring with RSpec and Guard to speed up testing

By Paul Barnes-Hoggett | Published: September 4, 2014

In my last post I showed you how to setup Guard and RSpec so you can automatically run tests when things change. Now lets get things cooking on gas by using the Spring application preloader. This will mean that your app framework will only have to load once, and tests will be super zippy. Setting up Spring with RSpec is simple and has a huge effect on test running speeds.

Things are zippier on Spring(s)

Posted in Agile Software Development, Engineering, Rails, Ruby, Software Craftsmanship, Test Driven Development | Leave a comment

Getting Started with Guard and RSpec

By Paul Barnes-Hoggett | Published: September 4, 2014

As I build out an application I want to ensure it’s behaving as I intend it. RSpec is a great framework for testing Ruby code, and is the tool I use most for my testing. But tests are pretty useless if you don’t run them, and rather than manually run tests when I change things, I use Guard and RSpec together. Here’s the simplest possible example for setting it up.

"Detroit Publishing Co. - A Yeoman of the Guard (N.B. actually a Yeoman Warder), full restoration" by Adam Cuerden, Detroit Publishing Company - http://www.loc.gov/pictures/item/2002696943/. Licensed under Public domain via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Detroit_Publishing_Co._-_A_Yeoman_of_the_Guard_(N.B._actually_a_Yeoman_Warder),_full_restoration.jpg#mediaviewer/File:Detroit_Publishing_Co._-_A_Yeoman_of_the_Guard_(N.B._actually_a_Yeoman_Warder),_full_restoration.jpg

Guard and RSpec : rather fancy

Posted in Agile Software Development, Engineering, Quality Software, Rails, Ruby, Software Craftsmanship, Test Driven Development | 3 Responses

Compiling Ruby from source for your development environment

By Paul Barnes-Hoggett | Published: August 31, 2014

For most of us, downloading the development package of Ruby for your platform will suffice. For the curious, or those needing a Ruby version that doesn’t have a pre-built package available you have to resort to compiling ruby from source code. Fortunately, as we have built ourselves a clean development environment using Vagrant, this is actually a pretty simple task!

Whilst most of us are fine with buying an existing home, some of us want to build our own; and so it is with Ruby

Posted in Engineering, Rails, Ruby, Software Craftsmanship | Leave a comment

Building A Pristine Rails Virtual Machine

By Paul Barnes-Hoggett | Published: August 28, 2014

A (thankfully) long time ago in a galaxy far far away I developed web apps in Flash. And when I had to target different versions I had to go through a whole rigamarole of uninstalling and reinstalling plugins. Fast forward to now and I’m often working on projects in Ruby. I’ve found RVM and gemsets to be a lifesaver for managing multiple environments on different projects. But as the environment gets more complicated I’ve started to want to have each project live in splendid isolation, in their own Virtual Machine. My last post described getting a bare-bones Ruby development environment up and running. This post details taking that a little further, and getting a Rails Virtual Machine up and running.

These are some Vagrants on the Rails. Read on for Rails on Vagrants…

Posted in Agile Software Development, Engineering, Rails, Ruby, Software Craftsmanship | Leave a comment

Using Puppet and Vagrant to make a one-click development environment

By Paul Barnes-Hoggett | Published: August 26, 2014

Keeping a development environment clean and tidy can be a bitch. When you are working on multiple projects across different platforms it can get messy really fast. And if you’re managing a team of people and need them all to run your app locally things can get tricky too. Recently I’ve setup a process so that a pristine development environment can be spun up for a project in glorious isolation. And the best thing is, once you have it set-up, you can spin up new environments in just one command!

Write once, deploy many times has been a goal for rather a long time

Posted in Agile Software Development, Engineering, Rails, Ruby, Software Craftsmanship | Leave a comment

An external keyboard for the iPad; making the right choice

By Paul Barnes-Hoggett | Published: February 13, 2012

As I mentioned in my previous post, I’m traveling for the next few weeks on a sabbatical to Europe and Asia. I’m keeping a journal of my travels on my tumblog, and from time to time figure I’ll be writing longer text posts here. Because of this, I figured that I should bring an external keyboard with me and I’ve already found it to be a tremendous help. Even writing short emails is so much easier on a real keyboard. When I was researching, I quickly narrowed it down to two choicee: The Apple wireless keyboard (with the Incase origami case) and the Zagg Zaggfolio case and keyboard.

Posted in Tablets, Travelling Light | Leave a comment

Tablet only living—A geek travelling light

By Paul Barnes-Hoggett | Published: January 31, 2012

In about a week’s time I’m taking off on a sabbatical. I’m fortunate enough to have employers who have agreed to let me off the leash for a few weeks, so I’m making the most of it.

On the road again, and learning to be more like a car than a truck

I’m using the opportunity to take myself off on a journey that will take me from Berlin to Bangkok, from Paris to Paro. But this isn’t just a grand tour where I’m off to ‘find myself’ (although I will be travelling to PBH)—I’m also using this as an experiment in tablet-only living.

Posted in Tablets, Travelling Light | 4 Responses

Performance – spend it wisely and never raise the debt ceiling

By Paul Barnes-Hoggett | Published: August 6, 2011

The US had it’s credit rating downgraded yesterday. For many people, it seems at first a little abstract and vaguely ominous—a chance for China to get it’s own back after being harangued by the US on its undervaluation of the Yuen. Maybe the outcome will be catastrophic, maybe not so much. Only time will tell. What Standard and Poor’s have basically said is that there is more chance than before that America will fail to pay its bills on time. But what does this have to do with quality software and how it gets built? Well here’s the thing—the way the US government are managing the economy and the debt ceiling are very similar to the way many software projects go slowly south; everyone recognizes that something needs to be done, but none can agree on what the right course of action actually is.

Stock market crash "100 dollars will buy this car, lost all on stock market"

Don't overpromise and foreclose on your project

Posted in Engineering, Quality Software, Software Estimation | Leave a comment