if $0 == __FILE__
    # do something
end

If you execute the file, the 'do something' block will run, but if you require the file, it won't. That way you can use the file as both a library and a script.

Q: What do you think about Story A?
A: That's a priority one.

Q: Ok, what do you think about Story B?
A: That's a priority one as well.

At this point, the stories have not been prioritised. They have been classified into groups, where the group is named "Priority One". Whilst this may be a useful culling technique, do not fool yourself into thinking they are prioritised. What's worse for you is that, whether you like it or not, the stories will get done in some order. If the team is ready to start on a story and finds two of them that are both "Priority One", then they will pick one of them to do first. Sometimes, they will pick the wrong one.

Do your team a favour. Don't classify your stories. Prioritise them.

Rails::Initializer.run do |config|
  config.logger = Logger.new
  config.log_level = :debug
  config.log_path = "log/myfilename.log"
  config.whiny_nils = true
  config.active_record.logger = Logger.new
  config.active_record.colorize_logging = false
  config.action_controller.logger = Logger.new
  config.action_mailer.logger = Logger.new
end

The logger attributes allow you to create a global logger, or a specific logger for the active record, action controller and action mailer framweworks. The log_level controls how much logging gets printed out (we'll see an example a bit later). log_path defines the location of your log file. whiny_nils gives you some more verbose output if you call a method on a nil object, and colorize_logging gives you colored output in your logs, which is useful if you're viewing them in a *nix terminal window.

As an example, I can create a Rails controller like this.

class SampleController < ApplicationController
  def do_logging
    logger.debug("what?")
    logger.info("done")
    logger.warn("uh oh")
    logger.error("bang!")
    logger.fatal("KABOOM")
  end
end

When executing the do_logging method on this class in a newly created Rails application, the following output appears in the terminal window:

what?
done
uh oh
bang!
KABOOM

I don't find this very useful, so I try configuring my Rails applications wth log4r instead. Here's an example of my setup in the development.rb file.

config.log_level = :debug
Log4r::Logger.root.level = Log4r::DEBUG
formatter = Log4r::PatternFormatter.new(:pattern => "[%5l] %d %30C - %m")
Log4r::StderrOutputter.new('console', :formatter => formatter)
Log4r::Logger.new('App').add('console')
RAILS_DEFAULT_LOGGER = Log4r::Logger.new('App::Rails')

This has substituted the Rails logger with a Log4r logger instead. The pattern formatter has been configured to print out the log level, date, context (logger name) and a log message. I've created a top level logger call 'App', and another logger called 'Rails' which is a child of the 'App' logger. The call to Logger.new with the parameter 'App::Rails' hooked the two together by name. Log4r loggers write to their parents output as well as their own, so I don't need to create any more outputters. Finally, I set my newly created logger to be the default Rails logger. Running my controller again now produces this output:

[DEBUG] 2007-06-26 11:45:56              App::Rails - what?
[ INFO] 2007-06-26 11:45:56              App::Rails - done
[ WARN] 2007-06-26 11:45:56              App::Rails - uh oh
[ERROR] 2007-06-26 11:45:56              App::Rails - bang!
[FATAL] 2007-06-26 11:45:56              App::Rails - KABOOM

That's much more useful now, however, I don't have any meaningful way of distinguishing log messages coming from the Rails framework to log messages coming from my code. Framework log messages will all have the context of 'App::Rails' too. I'd like to have a different context. I can now change my controller to be like this though.

require "log4r"

class SampleController < ApplicationController
  def initialize
    @@log = Log4r::Logger.new('App::SampleController')
  end
  
  def do_logging
    @@log.debug("what?")
    @@log.info("done")
    @@log.warn("uh oh")
    @@log.error("bang!")
    @@log.fatal("KABOOM")
  end
end

Making this change gets me the following output:

[DEBUG] 2007-06-26 11:45:56   App::SampleController - what?
[ INFO] 2007-06-26 11:45:56   App::SampleController - done
[ WARN] 2007-06-26 11:45:56   App::SampleController - uh oh
[ERROR] 2007-06-26 11:45:56   App::SampleController - bang!
[FATAL] 2007-06-26 11:45:56   App::SampleController - KABOOM

Now I can easily tell apart my log messages from the Rails framework messages.

You may have noticed that the Log4r configuration I used in development mode only outputs to the console, and not to a file as happens by default. I find that much more useful, as I don't have to bother cleaning up development log files any more. One final Log4r trick that I use is in production mode is to use a different outputter that automatically creates a new log file every day and names the files according to date. My production.rb file looks like this:

config.log_level = :warn
Log4r::Logger.root.level = Log4r::WARN
formatter = Log4r::PatternFormatter.new(:pattern => "[%5l] %d %30C - %m")
Log4r::DateFileOutputter.new('logfile', :dirname => "log", :formatter => formatter)
Log4r::Logger.new('App').add('logfile')
RAILS_DEFAULT_LOGGER = Log4r::Logger.new('App::Rails')

Those settings makes it easy to manage log files in production mode. Some people have reported possible errors when multiple mongrel processes try to roll a log file at the same time, and I haven't tested it in anger. Be careful that you test if you get into that situation. Otherwise, this setup has worked quite well for me.

If Ruby on Rails is something you think you want to get into, we're running an introductory Ruby on Rails workshop on July 21. You can find out the details of our innovative pricing model and bid for a spot via our Easy Access Training page.

Using this model from day one has actually been quite liberating. Financial conversations that are commonly quite taboo in Australia are totally open amongst Cogent employees. When anyone joins Cogent now, this model is one of the key points that I make to them before they start. Any potential staff have to be completely comfortable with all other staff knowing their income details. If they're not, Cogent is probably not the place for them.

Having said all of this, current Cogent staff members are all employed on a contract basis. Their rates are determined by the clients they work for, not by Cogent itself. Steve and I have decided recently to hire a permanent staff member, and of course, the same rules must apply to them. We're trying to be creative about structuring a package that is appealing to the high quality people we want to attract, but also gets us some reward for the financial risk we're taking.

It remains to be seen whether this model will work or not, but its an experiment we absolutely want to partake in. Building a company some other way isn't acceptable to us.

About 45 minutes into lunch after we'd all been chatting about various topics, I turned to Steve and said "well - my dickhead-ometer hasn't gone off, so he's ok by me". And that was how our latest Cogent staff member joined us.

Check out http://blogs.cogentconsulting.com.au/.

When we did the design improvement workshop we discussed how static methods can be a code smell. I'm wondering if you think this holds true for static factories since I don't feel right about creating a new instance of a factory just to ask it for an object ?

For example, I would normally have a factory like this:

public class ThingFactory {
    public static Thing create() {
        // ...
    }
}

So the calling code would look like this:

public class ThingProcessor {
    public void process() {
        Thing myThing = ThingFactory.create();
        // ...
    }
}

I'm a little anxious about code that looks like this:

public class ThingProcessor {
    public void process() {
        Thing myThing = new ThingFactory().create();
        // ...
    }
}

Since we create two object's and only one is kept.

The problem with static methods is that they make unit testing harder. You can't override them in a subclass, and you can't mock them out. So the implementation you've got is the only one that can be called. Here's how I would implement the factory from the example above:

public interface ThingFactory {
    public Thing create();
}

public class DefaultThingFactory implements ThingFactory {
    public Thing create() {
        // ...
    }
}

Now that I have an interface, I've got a mechanism that allows me to mock a method call. A useful trick to use in conjunction with that is to allow the actual implementation to be used by default in production code. You can do that with a combination of constructors like this:

public class ThingProcessor {
    private final ThingFactory _factory;

    // This constructor lets you inject a mock for testing.
    public ThingProcessor(ThingFactory factory) {
        _factory = factory;
    }

    // This constructor can be used by production code that just wants the default factory.
    public ThingProcessor() {
        this(new DefaultThingFactory());
    }

    public void process() {
        Thing myThing = _factory.create();
        // ...
    }
}

The second design is much easier to test, yet the API for users of the ThingProcessor is exactly the same.

If you're interested in seeing it, it is now available for viewing on the Cogent Consulting web site.

When you go home tonight, grab yourself a phillips head screwdriver. Bring it in to work tomorrow and make some adjustments. If you have some draws on your desk, take them off. If you have a return, take that off too. Put the draws somewhere nearby so you can still use them, but not under your desk. Now, take your monitor out of the corner, and move it to the square part of your desk.

Those simple modifications should mean that you now have enough room at your desk for two people to sit side by side and work at the same machine. Try asking a colleague to come over and give you some feedback on a bit of work you've just done. If she makes a suggestion, slide the keyboard over and ask her to show you a quick example of what she means. Amazing isn't it! Who would've thought that for no cost at all, you could get such a quick and noticeable improvement in the way you collaborate with people at work.

It turns out there is a way to get this to work though. The Keynote preferences has an option under the Slideshow settings called "Allow Expose, Dashboard and others to use the screen". Ticking that box will solve the problem and let you record as per normal. It claims that performance may be affected as a result, but I didn't notice any difference on my MacBook Pro.

Technorati Profile

The Cyclomatic Complexity of a method is the number of linearly independent paths through a program's source code. This means that the Cyclomatic Complexity of a method is the minimum number of unit tests needed to test every path in a method.

Take this piece of code as an example:

public static String getFormattedName(String givenName, String middleName, String surname) {
    if (givenName != null) {
        givenName = givenName.trim();
    } else {
        givenName = "";
    }

    if (middleName != null) {
        middleName = middleName.trim();
    } else {
        middleName = "";
    }

    if (surname != null) {
        surname = surname.trim();
    } else {
        surname = "";
    }

    return givenName + " " + middleName + " " + surname;
}

Every method starts out with a default Cyclomatic Complexity of one. The complexity is then increased by one for every linearly independent path through that method. In this case, each if statement in the method represents an extra path. So the total Cyclomatic Complexity for the method is four.

In other words, if you were writing tests for this method, you should write at least four of them.

The NPath Complexity of a method is the number of acyclic execution paths through that method. This means that the NPath Complexity basically represents all of the combinations of paths possible through a method, and is an upper bound on the number of tests you need to write for a method.

Lets use the same example code again.

Every method starts out with a default NPath Complexity of one. The complexity is then increased by one for every nested conditional loop, and multiplied by two for every parallel conditional loop. In this case, the method starts out with a complexity of one. It is multiplied by two at the first if block, bringing it up to two. It is multiplied by two again at the second if block, bringing it up to four. It is multiplied by two yet again at the last if block, bringing it up to eight.

In other words, if you were writing tests for this method, you should write up to eight of them.

So the number of tests you need to write is:

Cyclomatic Complexity <= Number of Tests <= NPath Complexity

The hard part now is to try and calculate what your complexity is. Fortunately, Complexian can do that for you.