Eamonn Faherty

DJango is an open source MVC (or MTV) Web CMS written in Python, HTML, JS and CSS.

It uses a urls file to interpret the incoming request, separating out the params from the action, eg /customer/1/delete would be interpreted as delete customer 1.

The urls file links the request to a view function. This view function uses the model objects to modify the values in the database and then passes them onto a template. This template then displays them!

The model objects are stored in a database and are defined using python. There is not really any need to know sql. Although, I would always suggest knowing it!!!

That is it, really! There are loads of great features that I will cover soon!

I am doing my first commercial project in DJango and it is going well! I will post on it once it goes live!

I have been playing around with jiglibflash. It is a rigid body physics engine. I have been looking at example projects like this.

I am working on a secret project at work and I thought it would be good to share what I have learned. I want to point out that I had no 3d experience before I started this! So you should be able to do this too!

I have been using papervision to render a texture map. It takes a black and white jpeg which marks shallower and higher areas on a terrain. Papervision converts this into a 3d terrain, mountains and ditches. I also have a car which is loaded from a dae file. Papervision loads this file and renders it. I am then using Jiglibflash to create JBoxes, JSpheres and others. These ‘J’ shapes are used for the collision detection. You can even have a Papervision sphere inside a JBox and the physics engine will treat it as a box. It does all the collision detections for you. It takes care of friction and gravity. You can apply forces to the shapes. It is really straight forward handling simple shapes. The next stage of my project is to start describing complex shapes using these J shapes. It is going to be tough!!!

Using these libraries has been great! It has been a bit of a pain as Jiglibflash uses Papervision (you can also choose to use Away3D) and you need to ensure you use working sets of Jiglibflash and Papervision. A lot of the examples use strange combinations of versions so beware!

I will post the other stuff I discover as I discover it!

My blog is now on the Amazon cloud! I have signed up to AWS and am hosting my own sites on my own box (running Gentoo).

I have also enabled a social networking plugin for wordpress that allows you to login using your google account. I will adding support for twitter and facebook soon!

This is the last blog post I plan to make about the terminology around TDD. There will be real life examples from now on.
I have previously discussed the terms collaborators, subject under test (SUT) and test doubles. Here, I am going to describe the three types of test doubles you can use.

The Real Thing
If you have a simple collaborator which only really stores and retrieves values, like a model, then is it worth replacing it for testing purposes? I personally think as long as this collaborator is unit tested then it is okay. Once there is some logic in the collaborator, some mutator methods, then I think you must refactor your unit tests and use a proper test double.

Stubs
Stubs are replacements for collaborators with pre-programmed responses for requests and fields that store inputs:

public function get username():String {
    return "eamonn";
}
public function set username(username:String):void {
    _usernameSetDuringTest = username;
}

The first method does two important things. It makes your code deterministic. Your collaborator will always return “eamonn” as a username. It also means that the only complicated thing is your subject under test. Both of these things are very important for unit testing code.
The second method stores the input sent to the object. The field _usernameSetDuringTest can be queried later to find out if the test should pass or fail.

Mocks
Mocks are objects setup to expect interactions. When you use a mock you define which methods on it should be called and which parameters it expects. You run your test code and then you verify that the mock has been interacted with in the way you thought it should have been.

My Thoughts
From my experience I have found mocks to be very frustrating. Unit tests that use mocks are more tightly coupled to the production code and this makes refactoring harder.
If I rename the method in the example above I have the following changes:
If using a mock, I would change the name of the method in the real collaborator, the test double and in the unit test as it would be listed as a method that should be called.
or
If using a stub, I would change the name of the method in the real collaborator and in the test double
If I am using FDT and these two classes implement the same interface I can use the refactor -> rename method tool within FDT. This handles the rename when using a stub. It cannot currently handle the change if I had used a mock.
This might seem like a lazy reason to use a stub over a mock but you will have to consider when you will be making this change. It will probably be a very high priority bug fix needed a year after you wrote the code and you will probably want to get it resolved ASAP. There are many other reasons to use stubs over mocks but I think you should make that decision with your team or for yourself. Here is a really good article on the differences between mocks and stubs. It also spiders onto other good articles on other testing approaches. It is definitely worth checking out if you have the time.

I have been posting about design patterns recently and I am realizing that it would be useful to post about Test Driven Development too.

As a gentle introduction I am going to go through some of the vocabulary.

Test Driven Development is the process; Red, Green, Refactor. That is the easy way to remember it. Below is your workflow:

1) Write a unit test. A unit test is a method that tests another method. The test calls the method that you are testing and verifies that the response is as expected. Your unit test should always use the same inputs and should always expect the same response. The class containing the method you are testing is called your subject under test (SUT).

public function testAddingTwoNumbers():void {
    var result:int = sut.add(2,3);
    assertEquals(5, result);
}

2) Run your unit test. It should fail. This feels kind of silly but this is the best (easiest) way to check that the test is being run. This is the RED stage.

3) Write some source code that makes the test pass. This should simple literal values. Run your test and it should pass. This is the GREEN stage. This also feels silly but it proves your test passes before you add the complex logic in there.

public function add(valueOne:int, valueTwo:int):int {
    return 5;
}

4) This is now where you refactor. You take steps to make your design better. It is up to you how far to take the refactoring. In this example I would change the method to the following:

public function add(valueOne:int, valueTwo:int):int {
    return valueOne + valueTwo;
}

The example above was trivial. The add method does not use any other objects. If it did the correct name for those objects would be a collaborator. When you are TDD’ing you should replace collaborators with simple objects that return simple values. These are referred to as test doubles, after the term stunt double. You can use patterns such as the IOC pattern and Factory patterns to make it easier to replace collaborators with test doubles. That is coming in post 2!

Background Reading
The creation method pattern

The Problem?
You want to use objects that are created else where and are of a set type but the implementations may vary.

Examples?
SocketManager, or any thing that needs to be replace during unit testing.

How?
The constructor of my complex object:

public class CharacterFactory {

	public static var factory : NonPlayerCharacterFactory;

	public static function getAPlayer() : IPlayer {
		return factory.getAButton();
	}
}

The using of the creation method:

var player:IPlayer = CharacterFactory. getAPlayer();

Why is it good?
• It is easy to understand; it is a simple pattern that needs little extra code. It builds on the singleton pattern, which is well known.
• You can get objects without knowing how they are created or where they come from.
• You can share objects without the users of the factory knowing the objects are shared.

Why is it bad?
• It is confusing to read code where objects are not being created directly.
• Debugging is hard, as you have to know what was in the factory when you used it in order to know what object you have.

Further Reading
Read about the IOC pattern.

More
Factories are great! They allow you to define scope for your application. This means that you can set a testing scope when you are running unit tests. The involves setting the factories used in your factory to a test factory which provides test doubles. Changing the scope of the factories outside of your application means that you test your code without making any special changes.

Background Reading
The factory method pattern

The Problem?
You have a complex object, which has a lot of arguments in its constructor or you always want to construct the object using different sets of parameters.

Examples?
Socket Manager

How?
The constructor of my complex object:

public function ComplicatedButton(colour:uint, mouseOverColour:uint, mouseOutColour:uint) {
	_mouseOverColour = mouseOverColour;
	_mouseOutColour = mouseOutColour;
	setUpGraphics(colour);
addEventListeners();
}

The using of the creation method:

var redButton : ComplicatedButton = ComplicatedButton.getRedButton();
var blueButton : ComplicatedButton = ComplicatedButton.getBlueButton();

Why is it good?
• It is easy to understand; it is a simple pattern that needs little extra code. It builds on the singleton pattern, which is well known.
• Anyone using one of the creation methods to create the object is guaranteed to have an object in an identical state as the other users of the method.
• Objects that complicated or a lot of constructor parameters can be simplified.

Why is it bad?
• The class now has two responsibilities, the main purpose of the class plus the instantiation of its instances.
• The class can often grow in size as the creators in declared inside the class. This makes the class harder to read for a developer.

Further Reading
Read about the factory patterns.

More
Creation methods are a great first move towards using factories. Their concept is easy to grasp and doesn’t require much extra code. The class can grow quite big, quite quickly but it is up to you to spot when the acceptable size has been passed for you to put your refactoring hat on. I would use them when I have a graphical component that accepts integer colours as parameters or when I have components that need a lot of initial set up. In the example above I have colours specified as integers. To ensure that all of the buttons considered to be red or blue are the same shades of red or blue I protect users of my ComplicatedButton by adding creation methods with the colours hard coded. Once I have more than one group of setups I would refactor, replacing the creation method with a factory method.

Background Reading
Read about the singleton

The Problem?
You want to have multiple instances of a singleton and want global access to them all. This may be because the objects use groups of resources, such as different groups of sounds, or because the objects need a lot of configuration, such as currency converters, or need global access, an event dispatcher.

Examples?
Currency converter, sound controller, global event dispatcher

How?
The Multiton:

public class SocketManagerMultiton {
	private static var _instaces : Dictionary;
	public static const CHAT : String = "CHAT";
	public static const WEATHER : String = "WEATHER";

	public static function getInstace(instance:String) : SocketManagerMultiton {
	ensureInstanceExists(instance);
		return _instaces[instance];
	}

private static function ensureInstanceExists(instance:String) : void {
		if (_instaces == null) {
			_instaces = new Dictionary();
		}
		if (_instaces[instance] == null) {
			_instaces[instance] = new SocketManagerMultiton();
		}
	}

	public function send(message : String) : void {
	}
}

Example Use:

var chatSocket : SocketManagerMultiton = SocketManagerMultiton.getInstace(SocketManagerMultiton.CHAT);
chatSocket.send("hello world");

var weatherSocket : SocketManagerMultiton = SocketManagerMultiton.getInstace(SocketManagerMultiton.WEATHER);
weatherSocket.send("HOW_IS_THE_WEATHER");

Why is it good?
• It is easy to understand; it is a simple pattern that needs little extra code. It builds on the singleton pattern, which is well known.
• See singleton pattern for other good points.

Why is it bad?
• It tightly couples the classes that use the multiton to the fact that they are using a multiton.
• See singleton pattern for other bad points.

Further Reading
Read about the factory and inversion of control patterns.

More
Multitons are a way of grouping Singletons. They share the benefits and carry the problems that Singletons have. They are good for classes that use a lot of resources such as socket connections or classes that cache things. They do make code harder to refactor and very difficult to unit test but if follow the suggestions I made in the Singleton post then you can limit your pain, a bit anyway! If you are going to use a multiton make sure you use String constants as I did above. It is easy to make typing mistakes when using String literals. Also the constants can be meaningful, as they are in my example.

Background Reading
None

The Problem?
You want to ensure you have only a single instance of an object and want global access to it. This may be because the object uses a resource, such as sounds, or because the object needs a lot of configuration, such as a currency formatter, or needs global access, an event dispatcher.

Examples?
Currency formatter, sound controller, global event dispatcher

How?
The Singleton:

package singletonpattern {

	/**
	 * @author eamonn faherty
	 */
	public class SocketManagerSingleton {
		private static var _instace : SocketManagerSingleton;

		public static function getInstace() : SocketManagerSingleton {
			ensureInstanceExists();
			return _instace;
		}

		private static function ensureInstanceExists() : void {
			if (_instace == null) {
				_instace = new SocketManagerSingleton();
			}
		}

		public function send(message : String) : void {
		}
	}
}

Example Usage:

package singletonpattern {
	import common.Example;		

	/**
	 * @author eamonn faherty
	 */
	public class SingletonPatternExample extends Example {

		public function SingletonPatternExample() {
			var socket : SocketManagerSingleton = SocketManagerSingleton.getInstace();

			socket.send("Hello world");
		}
	}
}

Why is it good?
• It works well; if you use an instance protector then you can be sure that only a single instance will exist.
• It is well understood; it is widely used in the actionscript world.
• It is easy to understand; it is a simple pattern that needs little extra code.
• It is easy to implement; actionscript allows us to check the caller of a method and allows us to use private classes.

Why is it bad?
• It tightly couples the classes that use the singleton to the fact that they are using a singleton.
• It is not possible to extend the singleton class if you wanted to add functionality.
• You cannot use your singleton class again; you cannot extend it or reuse it with composition.
• If you are unit testing a class that uses a singleton you need to add some code to your singleton to make testing possible.

Further Reading
Read about the factory and inversion of control patterns.

I recently did my first public talk! It was at LFPUG (London Flash Platform UserGroup).

Here are the details

I think it went really well. I had some very kind feedback via email and twitter and also on the night in person!

A few people have requested that I upload the examples I used and the slides so here they are.

Over the next few weeks I am going to be posting example patterns with more information, in more depth than I did on the night.

If you want me to cover a pattern please post a comment with the pattern name and I will bump it up in the list.