It doesn’t really matter how small your projects are, they are probably going to get bigger than you think, and soon enough, another project will come along and you’ll need to look after that one…

And then what happens? Maybe another project, and another… and pretty soon things get forgotten and then where are you? In trouble probably…

It’s a common topic, productivity boosting, you may have heard of Getting Things Done… you may have some sort of system that you can personally rely on to manage your time and make sure that you and perhaps your whole team, or maybe your organisation can co-operate efficiently and simply.

Or then again, maybe, like many people and organisations you and your colleagues are working on a patchwork of systems, some of which are… hmm… let’s say, not so much, no… not good.

I’ve encouraged development teams to use one sort of issue tracking package or another over the last few years, Bugzilla, Jira, Trac and more recently Redmine. Redmine is a fairly new kid on the block compared to the other products, but it’s looking very promising.

It doesn’t really matter what you use, because it’s really about how well you can engineer (socially and technically) the product you decide to use. If you have a strong Eclipse / Flex Builder presence in your team then Trac, Bugzilla and Jira are all very nice due to the Mylyn integration. Mylyn is a sweet Eclipse plugin which really helps to keep developers linked up to the project tracking system, updates and new issues assigned to a developer will pop up as small notifications, and updating an issue is linked directly from the Eclipse platform. Perhaps I’ll post some more info on mylyn another time.

Sadly, Redmine doesn’t have much in the way of external interfacing to assist in workflow, but because of it’s slick interface and very rich feature set, it’s a very compelling choice too. However if you really need integration through Email or Mylyn or another external tool then go with Trac, Jira or maybe Bugzilla - I suggest you keep your eyes on Redmine too, because there’s a lot of development happening.

If you have yet to get up and running with a project tracker, it’s worth your while getting a Redmine installation up and running and giving it a try. (I’d recommend the stable.0.7 branch) - but check the Redmine site for the latest development info.

I think it’s always good to cite a source who’s credibility far outreaches your own, I’ve seen many examples of test driven development, implored teams to adopt test driven development, and unit testing in general, and I appreciate how difficult it is for developers to make the change. Developers are after all creatures of habit.

Anyway, I just came across this note within the Subversion development site, dating back to 2001, this is as good a call-to-arms of TDD as I’ve seen, but I think it’s always a good idea to post as many of these as possible…

Many of us implementing the filesystem interface have now gotten into the habit of writing the test cases (see fs-test.c) before writing the actual code. It’s really helping us out a lot — for one thing, it forces one to define the task precisely in advance, and also it speedily reveals the bugs in one’s first try (and second, and third…).

I’d like to recommend this practice to everyone. If you’re implementing an interface, or adding an entirely new feature, or even just fixing a bug, a test for it is a good idea. And if you’re going to write the test anyway, you might as well write it first.

Yoshiki Hayashi’s been sending test cases with all his patches lately, which is what inspired me to write this mail to encourage everyone to do the same. Having those test cases makes patches easier to examine, because they show the patch’s purpose very clearly. It’s like having a second log message, one whose accuracy is verified at run-time.

That said, I don’t think we want a rigid policy about this, at least not yet. If you encounter a bug somewhere in the code, but you only have time to write a patch with no test case, that’s okay — having the patch is still useful; someone else can write the test case.

As Subversion gets more complex, though, the automated test suite gets more crucial, so let’s all get in the habit of using it early.

If you need to do any sort of parameter passing to your AS3 or Flex Swf’s you may be wondering how to do it. In the olden days when you had a _root context on your MovieClips, and thank you very much there were your variables ready and waiting when you loaded your SWF.

Flex / AS3 has a more semantic and structured approach to the problem, well, it puts the values somewhere more semantic and structured at least.

If your application entry point is a subclass of Application you can grab your parameters from MyAppSubclass.application.parameters or in mxml Application.application.parameters.

For example I have a product ID I want to pass to a small swf when I load it.

<mx:Application 
	xmlns:mx="http://www.adobe.com/2006/mxml" 

	creationComplete="initVars()"

	 height="65">
    <mx:Script><![CDATA[
    	
        [Bindable]
        public var productId:String;
        
        // Assign values parameters to properties.
        private function initVars():void {
            productId = Application.application.parameters.productId;
        }
        
    ]]></mx:Script>
    
    <mx:VBox fontSize="18" fontFamily="Arial">
    <mx:HBox>
        <mx:Label text="Product Id: "/>
        <mx:Label text="{productId}" fontWeight="bold"/>
    </mx:HBox>
    </mx:VBox>
</mx:Application>

All I have to do is load the swf with a query string tacked on the end of the swf’s url and supply the key, value pair for my variable.

key: productId
value: 2983127

(or any other product id I need, be careful of invalid strings!)

so the swf load url would look something like…

myflex.swf?productId=2983127

The mxml will run straight from Flex Builder 3 so try it out for yourself and try loading the swf you compile into a browser (without HTML) and put ?productId=THX1138 on the end of the url. The productId will be shown in the SWF.

For many years now the Java community have had a broad and clearly defined set of coding standards, for me this was solidified by the Eclipse project, and with the maturing of ActionScript development in the last couple of years, it’s really time the community started to make moves towards a similar standards set.

I propose that a broad based consortium of interested parties should convene on the Java standards and take steps to achieve the following goals.

• Refactor the coding standards applied to Java, for the ActionScript 3.0 language.
• Publish these standards as RFC’s at a prominent community node, ie. osflash.org, Adobe Labs.
• Build certification exams and study guides for the use of student programmers
• Work to build / refine tools to assist development using these standards.

This may seem slightly ambitious, but its important to get something happening here which is larger that any one individual or organisations recognised standard coding practice. Only then can we hope to rely on the coding of accredited developers, and maintain a high quality level industry wide.

I have been and will continue to do what I can to evangelise this standards building process. I would be keen to work with others who feel it’s time to get standards based ActionScript coding up and running.