Kirk Bushell - Home

PHLite - A Light-Weight PHP Templating Engine!

2009-09-30T12:03:00Z

After playing around with frameworks such as Ruby on Rails, CakePHP, CodeIgniter, and many others - I came to like the templating systems they used. They were quite fast, efficient, and importantly - very easy to use. However, with a current task I've been given, I've realised that there are some of us out there who aren't using these frameworks, dislike templating engines like Smarty, but need a good, robust templating system. Enter PHLite (pronounced flight).

Would love to hear people's comments about this!

Custom database.yml files for development environments

2009-07-14T05:46:00Z

Working as part of a large team can mean one of two things: either you all have the exact same development environment, or you all have different setups with your own settings. Which one is most likely? In this article I'll highlight how to customize your rails application so that it will load your database configuration file rather than depending on the same one for everyone.

In a previous development role we used to have everyone with their own database.yml file, based on the hostname. However, this was also loaded within the database.yml file itself. It would look for a custom database configuration file then load that in to itself, overloading any previously-defined configuration settings for dev/test. This was great, but was a little messy. An easier way to do this, is to define the configuration file that gets loaded within your environment.rb file:

// this goes within the Rails::Initializer block
require 'socket'
database_file = ['config/', Socket.gethostname, '-database.yml'].join
config.database_configuration_file = database_file if File.exists? database_file

Effectively what we're doing here is looking for a file within the config directory that matches something like: my-hostname-database.yml, and if it finds it - it will load this, otherwise it will retain the default config/database.yml.

ATI Catalyst on Ubuntu Jaunty

2009-07-10T11:03:00Z

A lesson in patience, time, and lots and lots of reading. I finally stumbled across a wiki tutorial for an old version of the ATI Catalyst drivers for Ubuntu 7, which worked great for Jaunty as well! It's a long tutorial but well worth it if you're having problems. So if you are, check out the Catalyst for Jaunty tutorial.

Rails 2.3.2 on Ubuntu Jaunty - net/https error

2009-05-28T00:51:00Z

While working with the new version of Rails, I got an error that looked like the following:

/home/.../.gem/ruby/1.8/gems/rails-2.3.2/lib/initializer.rb:269:in `require_frameworks': no such file to load -- net/https (RuntimeError)

This can be remedied by installing the libopenssl library: sudo aptitude install libopenssl-ruby

New Site Design!

2009-05-13T00:23:00Z

Thanks to Mephisto, this has been an incredibly painless process. I've introduced features and categorised some of the content here much more easily than I would have thought. And so now I introduce to you - kirkbushell.com v2.0!

Well it hasn't taken very long, thankfully. The longest process was the design aspect and getting it to a point that I wanted to keep it (I think I went through 4 or 5 iterations of the new design). Getting it into Mephisto was ridiculously easy, and I was even able to organise some of the posts and articles without having to touch the rails core, which I was very happy about.

I initially wanted to do the site in HTML5, but figured I can slowly change the site over as I get time. It's certainly on my priority list as I'd like to come to grips with the new features of HTML5, but all in time. I still have various other projects that need completion before I can do that.

Hope you all like the new design, and look forward to your comments and feedback!

Retrieve the First Element of an Array

2009-05-10T07:05:00Z

It's fairly general knowledge in PHP that if you want the first item of an array, you can use array_shift. However, this also removes the element from the array and this may not be the intended functionality of the developer. Introducing: array_first. It's fairly general knowledge in PHP that if you want the first item of an array, you can use array_shift. However, this also removes the element from the array and this may not be the intended functionality of the developer. Introducing: array_first. array_first allows you to see the first element of an array, simply by passing the array. It can be a numerical or associative array, it just has to be an array.

function array_first($array)
{
  if (!is_array($array)) {
    throw new Exception('Argument is not an array.');
    return false;
  }
  $slice = array_slice($array, 0, 1);
  return $slice[0];
}

Updated the function to use array_slice() rather than finding the array keys, thanks Joe!

directorize() function

2009-04-14T05:28:00Z

After having dealt with some directory-creation lately based on user input, I decided to safe-guard the creation of directories with the following function: directorize().

function directorize($dir) {
  return strtolower(preg_replace('/[^a-z0-9\-]/i', '', str_replace(' ', '-', $dir)));
}

What this function does is replaces all instances of any character that is not a letter, number, or dash (we replace spaces with dashes for directory creation), with nothing, so an example such as:

The Lazy Fox is Just plain lazy!

Would return: the-lazy-fox-is-just-plain-lazy.

Enjoy!

Using the right tool for the job

2009-04-08T01:12:00Z

Having now had some experience with a multitude of programming frameworks, including CakePHP, Codeigniter, Ruby on Rails, amongst various others, I'm beginning to see a pattern develop within the development community. This pattern involves the seductive nature of well-written frameworks pulling the developer in to it's curvaceous body, so much so that the developer becomes blinded by the possibilities before it.

The main problem I see, is that with (especially good ones) frameworks, developers are moving towards these solutions for just about anything and everything, and for most parts of the web, this is fine. However, when developers become so clung to a framework whereby they think it is the solution for everything, stumbling blocks begin to materialise and the solutions become ugly.

For the most part, frameworks provide developers with an easy interface to generate websites at breakneck speed, thereby allowing the development community to industrialize the development process (cheers Khaless for the term). What this means is that we're able to pump out solutions at speeds never thought possible, especially with frameworks such as Django, RoR, CakePHP and others. However, what does this mean for development in general?

Using heavy-handed frameworks means that one thing is generally left behind - performance. The difference in performance between a site using a framework specifically tailored for it's product, and one that uses a generic framework which is built to cater for an endless number of options for websites, can be staggering. Of course, there is a tradeoff to this performance hit - development time. Development time is generally much more expensive than hardware (unless you're serving millions of page view per day), and so therefore (depending on the project) a sound and educated decision should be made, rather than simply jumping into your favourite development framework.

One of my close colleagues uses a particular framework for just about everything, and although this framework in it's own right is a great product which allows people like myself to develop applications very quickly - it's also one of the heaviest frameworks available, meaning it's one of the slowest to serve pages. For example, even though development of a mainly static website could be easier to develop using it, what we're doing is using a full-stack solution to serve basically static pages. What does this mean? We're effectively cutting down the performance from 1000s of pages/second to approximately 50 or under.

This brings me to my original point - use the right tool for the job! Big frameworks are great for spiking out and even developing the initial stages of products, so as to get it to the public in a quick and orderly fashion. However, as the needs for the product changes and popularity grows, the framework of choice can (but not always) become a real hurdle that could have been overcome earlier in the development process if the project was given it's due respect and investigated in depth for the right technologies and solutions to be used.

Working on a new project

2009-03-12T12:16:00Z

Always something new to do. This is something I've been wanting to do for quite some time, I'm just finally getting around to doing it as I seem to have a little bit of free time at the moment, which is always good for getting personal projects done. This is something that's been in the pipeline since at least 2002 (When I built droidsrpg.com, now down). Ever since those early days of browser-based game development, I had a vision - I knew I could create something quite cool, the idea was sitting in my head, festering away.

Well, I've finally got off my butt and started making some real progress on this project. The game is still very early in the process, still mapping out features will work, where the game mechanics will take the player and so on, as well as a business model. This is my most ambitious project to date, but also the only one I've been interested in doing for over five years. I will be posting regular updates here as to my progress, as well as the lessons learned along the way. Adios!

Theme_support plugin - not that evil

2009-03-03T23:15:00Z

I had a bit of a stint recently developing some pseudo-theme functionality for a project here at Westfield. During that time, I've discovered a few "gotchas" relating to the view_paths variable within the controller. One of the most recent tasks I've had to complete at the office was to provide some sort of templating/theming system for one of our products. After a very small search, I stumbled upon the view_paths array and started fiddling, only to find I couldn't get layouts to work. I then moved onto a plugin called theme_support and had exactly the same problem. This caused days of grief (4, to be exact) without it ever occurring to me that maybe I'd have to set the layout. Well this morning I went about trying just that and lo and behold - IT WORKS! This is an incredibly frustrating lesson, as a simple one-line piece of documentation within the plugin would state that a layout has to be specified in order for this to work. Now, I could be wrong, but I'm fairly certain rails by default looks for a layout file of the same name as the controller aka: layouts/controller.html.erb. Considering that it's not able to do this unless a layout is specified, leads me to believe that there may be a bug within the layout.rb file that prevents this search from working if no layout is specified, but the view_paths are changed. In any case, I will be adding some comments to the theme_support plugin, as I think this is fairly fundamental and has been overlooked. Now that I have got it to work, theme_support is working as intended and I can get on with my life. Thanks to everyone on the rails-oceania Google Group for helping me out, especially Terry Heath. Moral of the story - test every single part of code given in examples when working with a new plugin.

array_collect, mapping required fields to a PHP array

2008-12-08T23:30:00Z

After delving around in ruby for a little and finding the magic that is the Array.collect method, I decided to write one for PHP, considering how much I use it in Ruby. Hopefully others will find some use in this function.

<?php
function array_collect($array, $params)
{
	$return = array();
	if (!is_array($params)) {
		$params = array($params);
	}
	
	foreach ($array as $record) {
		$rec_ret = array();
		foreach ($params as $search_term) {
			if (array_key_exists($search_term, $record)) {
				$rec_ret[$search_term] = $record[$search_term];
			}
		}
		
		if (count($rec_ret) > 0) {
			$return[] = $rec_ret;
		}
	}
	
	return $return;
}
?>

Basically, what this allows us to do is extract information from an array and have it stored in another array. For example, we may only want a few select fields as a subset of data, we could do this by doing:


$records = array(array('a' => 'y', 'b' => 'z', 'c' => 'e'), array('a' => 'x', 'b' => 'w', 'c' => 'f'));
$subset1 = array_collect($records, 'a'); // $subset1 will be: array(array('a' => 'y'), array('a' => 'x'));
$subset2 = array_collect($records, array('a', 'c')); // $subset2 will be: array(array('a' => 'y', 'c' => 'e'), array('a' => 'x', 'c' => 'f'));

An Rspec Model Example

2008-11-12T05:12:00Z

Both in part due to the traffic coming to my blog via the subject line, and also my want to learn a bit more about RSpec model tests, I thought maybe it would be a good idea to throw together a more complicated model test, using RSpec. In this article, we'll look at the various methods you might have as part of... let's say... a vehicle model.

Before we get started, I'd just like to put a little disclaimer - this test will be done with database connectivity, meaning we will be hitting the database for any of the methods that will require it. This will ensure not only that our model works completely, but will also highlight any database issues we might have. Let's begin.

For argument's sake, let's just say that our Vehicle table will contain a unique identifier, the name of the vehicle, a manufacturer's id, and a license plate. (id, name, manufacturer_id, license). This is what we'll use as the base fields for our tests.

As stated previously, we're going to setup a model that will highlight the data one might find attributed to a vehicle. To ensure this article encapsulates a lot of what you would usually test in a model, we're also going to convolute it a little with silly extensions like a Doors association, just to stress a few points. Let's look at our base model.

class Vehicle < ActiveRecord::Base
  belongs_to :manufacturer
  has_many :doors, :wheels
  
  def self.vehicles_without_manufacturer
    Vehicle.find(:all, :conditions => {:manufacturer_id => nil} )
  end
end

Here we can see that we have Vehicle model, some basic associations and a custom method, which will retrieve all vehicles that do not have a set manufacturer. In the real world, obviously this wouldn't be the case, but we'll use this as a way of retrieving certain records. Let's look at the beginning RSpec tests.


describe Vehicle do
  
  describe :vehicles_without_manufacturer
    fixtures :all

    before :each do
      @vehicle1 = Vehicle.create!( {:name => 'test vehicle 1', :license => 'abcdef'} )
      @vehicle2 = Vehicle.create!( {:name => 'test vehicle 2', :license => 'ghijkl'} )
      @vehicle3 = Vehicle.create!( {:name => 'test vehicle 2', :license => 'ghijkl', :manufacturer_id => 1} )

      @vehicles = Vehicle.vehicles_without_manufacturer
    end

    it "should have only 2 vehicles that match the requirement" do
      vehicles.length.should == 2
    end
    
    it "should only contain the vehicles that have no manufacturer_id" do
      vehicles.should == [@vehicle1, @vehicle2]
    end

  end

end

Let's go over exactly what is going on here. First and foremost, we're grabbing all our fixtures for our project (these are generally located in test/fixtures, or spec/fixtures for rspec), and usually consists of an empty yml file, with the naming convention of [table].yml (where [table] is the name of the model representing your data). This ensures that each test we run, all data is cleared for that particular model, meaning we're starting from a clean slate each and every time.

Next, we're setting up a way for us to pre-populate the database before each test. More than anything, this makes our tests easier to read, with each individual assert done as a separate test (in this example, ensuring our vehicle length is what it should be and that we're only fetching the matching vehicles).

Now at this point you're probably wondering "well, you're not really testing application-specific stuff, these are things already tested by ActiveRecord's own tests", and you'd be right. What we're really testing here, is to ensure that our database and associated data is setup correctly. Let's move onto something a little more application-specific.

Let's add to our model the method below, which will give us the ability to assign the vehicle to a specified manufacturer, if it's not already assigned.

def add_to_manufacturer(manufacturer)
  if self.manufacturer_id.nil?
    self.manufacturer = manufacturer
  end
end

As you can see, we're only going to set the manufacturer if this particular vehicle record doesn't already have one assigned to it. Pretty straight-forward, right? Let's look at the test. What we're really looking to do, is mimic both conditions - one where a manufacturer_id is already set, and another where the condition is passed and we set the manufacturer, thereby covering all bases.

describe :add_to_manufacturer
  fixtures :all
  
  before :each do
    @vehicle1 = Vehicle.create!( {:name => 'test vehicle 1', :license => 'abcdef'} )
    @vehicle2 = Vehicle.create!( {:name => 'test vehicle 2', :license => 'ghijkl', :manufacturer_id => 2} )
  end
  
  it "should add the manufacturer if it doesn't already exist" do
    @vehicle1.add_to_manufacturer(Manufacturer.create!({field data}))
    @vehicle1.manufacturer.should_not be_nil
  end

  it "should add the manufacturer if it doesn't already exist" do
    @vehicle2.add_to_manufacturer(Manufacturer.create!({field data}))
    updated_vehicle = Vehicle.find_by_id(@vehicle2.id)
    updated_vehicle.manufacturer.should == @vehicle2.manufacturer
  end
end

The main aspect to point out here in our test addition, is the second "should". Notably, we're ensuring that no changes are made to @vehicle2, because if it has changed - then we know that our code check has failed, and we need to have another look at our code.

I hope this helps those of you looking for model examples - let me know if this was of any help, and if not - send me an e-slap and I'll write up another!

Testing using RSpec, Part 2 - the Controller

2008-11-04T04:17:00Z

When first learning how to write tests for rails applications (or anything for that matter), using RSpec, probably my biggest stumbling block, was mocking and testing my controllers. There was just so much to take in it was hard to make sense of it all. But, little by little I made progress. In this article I'll go over writing some basic tests for your controller and offer some of the methods you can use to write your tests. In order to make much sense of this, I'm going to do this article over three stages. The first stage will go over the controller and some simple methods one might find in a controller. The second stage will highlight some of the key aspects of testing our controllers and finally, the third stage - will see the article come together in a blur of RSpec, Controller and passing tests. To start with, let's create a controller that will handle the various actions a user might do when handling their own account. I'm going to keep this controller fairly simple, as I want to focus on the testing, not the code itself, so please bear in mind that when writing your own controllers to ensure you follow the appropriate procedures to make your application secure and stable.

class UsersController < ApplicationController
  def login( username, password )
    user = User.login( username, password )
    unless user.blank?
      session[:user] = user.id
    end
  end
end

When writing tests for our controllers, we want to ensure that our tests are as isolated as possible. Why? We only want to test the code we're working with and if we can, leave any dependencies of our controller outside in the cold. Reason for this is so that should we encounter any problems, either with our code or our tests - we know exactly where the problem is and how to fix it. As soon as you start introducing tests for code from outside the controller, you then begin to see an example of ambiguity as you now have to debug the code further to find the exact problem - and this should have been picked up in other tests, either in your models, or 3rd party libraries.etc. Add to this the fact that your tests get messy, and it's easy to see why this sort of "behaviour" is shunned against. Let's begin with some tests for the login method.

describe UsersController do
  describe :login do
    before :each do
      @params = {:username => 'username', :password => 'password'}
    end
    
    it "should not log the user in if no user was found" do
      User.should_receive(:login).with(params[:username], params[:password]).and_return(false)
      post :login, params
      session[:user].should be_nil
    end
  end
end

What we're doing is is firstly, stubbing out the login method on the user model (this could be anything you like, just make sure you stub out the correct method), but ensuring it receives the correct parameters and forcing it to return false. This in turn will unless user.blank? check fail, thereby not setting any session variable, which we check for with session[:user].should be_nil. Now, if we're going to look at our coverage, you'll note that we've got some code that never gets executed with this test, so we'll have to write another. Let's extend this test with another one and make sure that code gets executed:

it "should log the user in if the details are correct" do
  User.should_receive(:login).with(params[:username], params[:password]).and_return(1)
  post :login, params
  session[:user].should eql(1)
end

As you can see here, we've changed the stub of the login method a little differently, ensuring that it responds with a numeric value, the user id. We then assert that the user key for the session array is equal to 1, and our test passes! Yay! This is a fairly basic login method, so let's update this a little further with something a little more complex. First, let's update our test for the successful login:

it "should log the user in if the details are correct" do
  User.should_receive(:login).with(params[:username], params[:password]).and_return(1)
  post :login, params
  session[:user].should eql(1)
  response.should redirect_to(:controller => 'home', :action => 'index')
end

You can see here that we're now checking for some redirect functionality, which doesn't exist in our code - meaning our test will fail! So now we can go and update our code to ensure that the intended functionality is in place, and watch our test pass:

class UsersController < ApplicationController
  def login( username, password )
    user = User.login( username, password )
    unless user.blank?
      session[:user] = user.id
      redirect_to( { :controller => 'home', :action => 'index' } )
    end
  end
end

And there you have it! Test-driven development at it's very primitive finest! We've written some basic login code, and written tests to ensure that all cases against that method are working as intended, whilst isolating our tests to just that method. In the next article, we're going to look at how we can test our views to ensure the expected content is being rendered to the browser.

Teachmate.org, Now OpenSource

2008-10-28T23:20:00Z

Teachmate.org has open up it's doors and made the website's code opensource. Teachmate is about offering your knowledge to become and online teacher and/or to find people who would be willing to train you in a particular field, check it out: Teachmate. As far as I'm aware, this is one of the few actual websites where they have made their code opensource - this can only be a good thing for the web community! I found this through the ruby on rails google group.

Testing using RSpec, Part 1 - Models

2008-10-27T23:33:00Z

This is part of a 4-part series which will go over the various tests you can write for your models, controllers, views and acceptance using RSpec. My first article will begin with our application models and testing with and without database connectivity. Models for me have always been a bit of an iffy area of testing. Why? I've had many discussions, both online and with my fellow colleagues about whether or not models should be mocked out. I've heard good points in both directions, but I think it's better to test the models against the database (if required), to pick up early mistakes in your code. Leaving testing the models against the database in acceptance can take longer, and also means possible bugs may not be picked up until you write your acceptance tests. In some development environments, this simply isn't possible. However, for this article we're going to cover a single model with two different forms of testing: with and without database connectivity. Consider the model below:


class User < ActiveRecord::Base
  def self.get_users_with_no_referrals
    User.find(:all, :conditions => {:referral_count => 0})
  end
end

Let's now test this, with database connectivity.


describe User do
  before :each do
    @user1 = User.create!( { :username => 'test', :referrals_count => 0 } )
    @user2 = User.create!( { :username => 'another test', :referrals_count => 1 } )
  end
  
  it "should return all users with no referrals" do
    users = User.get_users_with_no_referrals
    users.length.should == 1
  end
end

Let's look at this same example, but we'll mock out the database calls so as to avoid any talking to our database.


require 'ostruct'

describe User do
  before :each do
    @returned_users = [ OpenStruct.new( { :username => 'test', :referrals_count => 1 } ) ]
    User.stub!(:get_users_with_no_referrals).and_return( @returned_users )
  end
  
  it "should return all users with no referrals" do
    users = User.get_users_with_no_referrals
    users.length.should == 1
  end
end

Have a look closely here - I've purposely made a code mistake in order to demonstrate why I think it's better to test against the database with our models. Have a look at the @returned_users line - you'll notice that the referrals_count is set to 1. Now, due to the fact that we're actually mocking this out, our test will pass - and we'll be none the wiser. Had we checked this against the database, our test would fail - as no data would be in the database that would match our request.

There are advantages and disadvantages to doing both ways and I think more than anything it comes to developer discretion as to which method should best be used - some developers (like myself) simply prefer one way or the other - neither is particularly right or wrong, but one way does enforce "proper" unit testing, whereas the other enforces (in my opinion) a better test.

Update: Thanks to Alexandre for spotting this. Be sure to require 'ostruct' when using OpenStruct. I tend to use this heavily in all my projects, so forgot to include it in the article.

In my next article, I look at using RSpec for testing our controllers. Testing using RSpec, Part 2 - the Controller