ActionScript & Android

In part 1 I described the rationale behind why I personally think unit tests can help save you money and time when building software for your clients. Part 2 is what started as a google search, turned into a dive into the deep-end of CI.

Continuous Integration (CI)
CI is a trick subject either you instantly get what it’s for or you don’t. I guess it’s a case of you’ll know when you need it.

So what is it? Well it’s a normally a server application that allows you to monitor your builds and allow you to track broken builds as well as the state of your unit tests that you’ve been writing. This becomes incredibly useful if you’re working with others (not limited too though, it’s also useful if you write alone). At any point in time you would be able to see what the main state of your software is at a very high level. A great side effect for me is that – I can point clients, developers and testers to one location and they can grab a build (known as an artifact in the CI world) for them to use. Everything is transparent, to you, your boss, your clients, everybody and this is the benefit. The more transparent you are the better expectations of the software people will have. It’s amazingly simple, hiding things away will come and bite you later on.

Which software? I spent a only a few hours trying to find a CI application, because the way I see it is, try something first and if it doesn’t fit the bill, just migrate to the next thing. I ended up with Cruise Control, it’s definitely not the prettiest application in the world and it feels very disjointed from a UX point of view, but does the job well. I did originally want to use Hudson, but it doesn’t support OS X.

Hardware? Ideally I would love to use ubuntu as the OS of choice, but could only get my hands on a old PowerPC G5 (with 6GB ram!!). This should be easily sufficient for running the builds.

Getting started.
Because Cruise Control is a java application, it default runs on the Jetty server. It’s a great server out of the box and needs almost no configuration to get the server running. The only one for me is hooking up to the log4j to something other than the console.

The next thing was setting up a project that was the “turnkey” example. This turned out to be a mixed experience… to set up a very basic example is extremely easy. The configuration file syntax is not to dissimilar to ant, which makes life extremely easy. I just pulled a branch (so I didn’t break anything from the master) from my git repository to the projects folder and hooked up my build file to the configuration file. I also utilised the clean to remove all the artifacts from the previous build so we always start with a clean build. That way if something goes wrong, it doesn’t affect the next build. I also used the configuration file to do a “git pull” at the bootstrap phase, so I didn’t have to do a pull manually.

That’s it, I had the simplest setup CI, the massive issue I had was getting logging to work for unit tests. There really needs to be more documentation about this as to me or new comers it feels like magic how it works.

So to all new people, you have to output all you’re log files to xml, it has to be in xml (you can do other file formats, but this is the easiest way) and it has to conform to junit xml format. I put my log files in the project and made a log folder where the logs could be dumped into when building. On clear command I would recreate the log folder. Then using the configuration tell CI where to look to find out if it was a successful build. This part took me half a day to figure out, it didn’t help when you have two programs called “cruisecontrol”, one being this and another being for ruby. I don’t know which came first, but one needs to change their name!

Web interface
I’m not going to talk too much about this, but to be honest it feels horrible to use from a UX and graphical point of view. It needs someone to go through the design and just tie it together. It’s a real pity as there is so much information in the interface, but you really have to go looking. There is a lot of information about types of builds, failures and configurations it’s just not presented well. It could easily become amazing as it has all the right features, but just doesn’t compete.

Conclusion
All in all, it wasn’t a bad experience, but it just feels like the whole thing is held together with magic – especially with the logging system for builds and unit tests. It’s hard to have 100% faith in something that you would like to do CI with. The great thing is that this could be easily sorted with some more documentation and some fixes to the configuration site.

Part 3 : ASUnit vs FlexUnit

I was reading a couple of blog posts about performance recently with trying to bring some speed to my personal project, more about that in up and coming posts. One interesting fact that keeps rearing it’s head is that we should never cast[wiki], when coding. I find this statement a little hard to stomach. I’ve been writing OOP for some years and find it hard to not cast! I try and reduce the amount of casting required by making sure I’m explicit as much as possible, but even so, you have to do it (unless some one can show me how to write a very complex project without it!).

So now we know we have to do it, what are the best ways to do it. I was running some tests last night and I was actually surprised that I didn’t know this, because it’s obvious.

I made a test which just loops through a for loop attempting to cast various items or the iterator. It’s fairly explanatory, just run the for loops multiple times until you get a big enough delta between beforeTime and the current time to make any sense.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

const NUM_ITERATIONS : int = 1000000;
var i : int = 0;
var beforeTime : int;
 
var element : IElement = ElementFactory.create();
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item0 : Element = Element(element);
}
trace("\tCast method (Class(instance)): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item1 : Element = element as Element;
}
trace("\tCast method (instance as Class): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item2 : int = int(i);
}
trace("\tCast method (int(instance)): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item3 : int = i as int;
}
trace("\tCast method (instance as int): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item4 : String = String(i);
}
trace("\tCast method (String(instance)): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item5 : String = i as String;
}
trace("\tCast method (instance as String): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item6 : String = i.toString();
}
trace("\tCast method (instance.toString()): " + (getTimer()-beforeTime));

So the results:

Cast method (Class(instance)): 6
Cast method (instance as Class): 75
Cast method (int(instance)): 3
Cast method (instance as int): 61
Cast method (String(instance)): 407
Cast method (instance as String): 67
Cast method (instance.toString()): 478

So what does this mean?

To keep it short. Don’t cast to another type, so don’t go from int to String, use ‘as’. Don’t use the toString() method for casting a int to a string, it’s very costly.

This is the important bit: Only if you know what the instance is it safe to do a cast and make sure you don’t use ‘as’. So if you know it’s an Element because of the IElement interface or because of a way to quickly test it (enum class which you define), then use type conversion.

Casting is expensive if you do it wrong, so make sure you do it correctly.

Note:
I tested this with the latest Flash Player 10.1 b3, so this could all change. I’ve not tested with old Flash Players because I’ve got better things to do! Also test with the normal release and not the debugger, I can not emphasis that enough!

Update:
This (i as String) would equal null, I should of checked this.