I’ve been a contactor for quite a few years now – with a break in the middle where I ran an agency with a friend for a couple of years (Nothing bad happened, we’re still friends and the agency is going great guns, it just wasn’t right for me at the time).  So I’ve got a lot of experience working in quite a number of companies and teams but I’m still not convinced I’ve got contracting, or at least my attitude towards it quite right.

Basically I am still a bit confused about what the role of a contractor is, and I also think that some of the clients I’ve worked for are also not clear.

Code Monkeys – Is this what we are?  Just guys brought in to fill a few holes and plug the resourcing gaps. Sometimes I suppose this is exactly what we are. The core team of developers have chosen the way they are going to build the application, the code framework we are going to use and have already picked up the cool bits of code to do.  As a contractor you step in to do the boring bit (because they are dull) or difficult, high risk or application vital bits (because no one wants to be left holding the baby when everything turns into a shit storm). I can understand this way of doing things, but it is expensive.  You don’t need an extra Flex developer sitting on your team on the off chance that a requirement comes in which needs another pair of hands, so when it does you get in a contractor. I’m also not really bothered about doing the bits no one else wants to either – it goes with the territory – if I wanted to try and make myself into a rock star (and I don’t honestly think I’m good enough to be one) I’d find the coolest agency in London and do everything to get a job.

If you are using contractors in this way then really you need to have an experienced in house architect, or at least an extremely experienced lead developer. Otherwise you end up with a team of contractors sitting around waiting to find out what they are supposed to do, or worse getting the wrong end of the stick and getting stuck in with gusto only to find out that they’ve done it all wrong.

The reason that you can do this with contractors is that we are pretty experienced ourselves, we’ve generally been coding to a high standard for a while and can hit the ground running regardless of the code or problem we are given. If you want it written in a certain way then as contractors we can do it that way. But should we?

Maybe as contractors our role should be more pro-active. Rather than sitting down and getting on with the job we are given we should take more of an active role in actually telling the rest of the team what we think and the way that we would do the job. Granted you can’t really do this when you are well into the project, or towards the end (which can be when agencies realise that they need another pair of hands) but when you are near the beginning of the project surely this is a good idea? As contractors we have worked in loads of different places, used tons of different development methodologies and seen many near misses and cock-ups and will have an opinion on how to avoid these problems in the future.

I tend to go down the middle of these routes. Make my opinion known and then get my head down and do what I’m asked too, but sometimes I wonder if being a slightly more opinionated developer at the outset would make the project, and my time at the client’s office, go a bit smoother.

This really is just me musing aloud (or blogging aloud – whatever…..;) ) I’m interested in what other contractors and also agency full timers think.

Tor has an addiction to buying books about how to bring up Charlie.  We’ve gone through Gina Ford, who should be shot, Sleep without Crying, Bringing up boys and a pile of others.  They are all bollocks. They all have this nuts assumption that all kids are the same and you can program them to do what you want.

Basically having a child will let you know one thing completely, that you never thought of before too much.  We are ALL different.  Each and every one of us is an individual that reacts and responds to things completely differently.  Charlie is utterly different to all the kids his age as much as I am different from all the people I work with.  And that is fantastic – that is what life is all about!  Some people are a pain in the arse, some people are hugely entertaining and some people are really clever.  As an immodest parent I believe that Charlie fits all of the above.

As an example of the bilge that these books talk about there’s a toddler book that Tor has by the loo – I optimistically think it’s just in case we run out of paper.  This book says -and I paraphrase because I can’t be arsed to write it out properly – that the author doesn’t believe in letting children discover that they can hurt themselves.  Again to paraphrase the book says that they don’t believe “in the old ways where children were allowed to put there hand or foot in a fire to discover that it hurts.” Well I can tell you that that is exactly what we ended up having to do.  After a few months of grabbing Charlie back from the fire and telling him off eventually I had to say to Tor, he’s going to have to do it.  Fortunately when he got close enough to feel the real heat of the fire he turned to me and said “It’s hot Daddy,” to which I graciously replied “I know that’s what I told you!” so he didn’t hurt himself.

The next thing the book went on to say was that during a hot summer they needed to get a fan out.  In order to show their child that this was dangerous by putting a pencil into the fan and demonstrating the danger of putting your finger into in.  They then went on to tell a story about how they accidentally dropped a glass and broke it.  To show how dangerous this was to their kid they took a shard of the glass and demonstrated how it could slice into a tomato.

If I did this with Charlie I can guarantee you that there wouldn’t be a pencil or glass left in the house as he had a go at mincing pencils in fans and destroying glasses to dice some salad.

I appeal to all of you – don’t bother with these ridiculous books.  Until I write one.  That’ll be really good, 306 pages all with one line on it saying, “Don’t worry, you are doing your best -and by the way as long as you love and support them they’ll be fine.”  It’ll be 4-ply too so if you do run out of paper in the loo you’ll be fine too.

I generally work in largish teams of people when I’m out on contract and I’ve noticied that even if you are sitting opposite someone you tend to use IM to communicate.  This could be Windows Messenger, Skype or one of the many many other IM clients.

Yesterday I found myself doing it again and I suddenly thought about how wierd this is.  You could reach over and physically touch someone and yet you are writing messages rather than talking.  Sometimes if it is important you’ll suddenly break out of the text chat and straight into a real voice conversation.  If you are overhearing this sort of communication it’s the most bizare thing.  All of a sudden someone deep in thought typing and staring at their screen will turn to the person next to them and say angrily “Yes – but I’ve appended the variables to the query string!” and the person they apparantly just started shouting at out of the blue calmly replies to them and then both parties go back to the squabble over IM.

Some people could argue that this method of communication is going to ruin social interaction (they’ll also probably read the Daily Mail) but I think that this can be a very important and valid ways to get things done.  But as with everything there is also a downside.

IM Pros

1 – How many times have I been deep in code, trying to think my way through or around a complicated problem and the someone has tapped me on the shoulder for a chat.  It completely breaks my flow and now I’m not really concentrating on either the conversation my colleague wants to have as I’m still half thinking about the code – but even worse I know it’s going to take at least 15 mins to get back into it.  If that person had quickly fired over a message on IM without breaking step I could zap back something along the lines of “Not now, give me x mins and we can talk.”  That way I’m not interupted and can get my job done faster and the person who wanted a chat will get my undivided attention when I’ve finished whatever I’m up to.

2 – You can have discussions over IM that you wouldn’t have out loud.  These could be along the lines of technical conversations where you need web addresses or lines of code zapped backwards and forwards.  You could be trying something out but you don’t want to broadcast to everyone in the immediate area that you don’t know if it’s going to work and you just want to work directly with someone else.

3 – You can speak your mind.  If you are worried about offending someone it is easier to have a text conversation as you can consider what it is you want to say before saying it.  This isn’t always possible in a face to face chat as you may forget an important point.  In a text chat you can take a bit of time to think rather than having to go straight back.

4 – You can ignore them.  You can’t ignore someone standing at your desk – it would be rude, but no one is going to get upset if you ignore a IM for a few minutes.

IM Cons

1 – It can be very secretive.  It is very easy to have a conversation behind someone’s back in plain sight.  Normally this may be the odd bitchy comment or exasperated “You’ll never guess what suchandsuch has done now!” that you’d probably have with people on your lunch break, but it can become quite insidious and undermining.  For example I was working with a weak Project Manager who was perfectly nice, but not really that effective.  This combined with everyone jumping on IM as soon as they’d just had a meeting with them to moan to the rest of the team pretty much wiped out any respect the team had for the PM and made a difficult project neigh on impossible.

2 – Its FUN!  Swapping jokes, firing over funny links or merely whittering to each other over IM is fantastic fun.  And possibly a major time waster.  This is probably the biggest worry for employers over using IM.  They want everyone to focus on their jobs and not thinking up witty retorts to their mate in Accounts.  However if your team does have loads of time to waste sending silly IMs or even worse are happy to ignore their work whilst sending messages then the problem is going to be something other then their IM habbit.

3 – Text communication removes all other human communication channels.  You cannot see someone’s face or read their body language.  It is really easy to write something (normally in jest) that is taken in the best case out of context or the worst case is taken really badly.  A quick example was someone asked me to change something over IM.  I sent back “Whatever” and didn’t add a smily at the end.  The next thing I knew the phone went and I had a really angry PM to deal with.  Even after I calmed them down I still am not convinced that I was just mucking around and of course I was happy to make the change.

So to sum up, and don’t forget this is only my opinion, I couldn’t work as effectivly without IM.  Even with the aparant stupidity of sending the guy sitting next to me IMs – I think as a method of unobtrusive communication about stuff that can wait it is vital.  Missusing IM I believe shows that there is a problem with something in the company, if someone is being undermined in IM chats then more than likely they would be undermined by people anyway.  If people are just using it to gossip then there is a problem with the respect of employees for the company.

Hello to the five or so people who accidentally find my blog.

If you’ve been here before you may notice that I’ve switched the design back to the standard theme and also changed the name of the blog.  Basically I’ve realised that although I am a web developer I can’t always post about developer stuff.  Writing tutorials for example, if you want to attempt to do them well anyway, takes bloody ages and I don’t have time to do that regularly.  Also although I may find a cool bit of code or nice way of doing something 9 times out of 10 I think about popping it up here and then realise that it’s probably going to be of interest to a very small number of people who have probably either discovered it themselves or come up with their own fix.

While I love my job as a developer I also started this blog because I’m interested in writing.  I used to write plays, sketches and I’ve got a couple of unfinished film scripts and novels knocking around that will probably never see the light of day.  But to be honest if they turn into anything that would be a bonus as the real purpose of them is for my own personal enjoyment of writing.

So I’ve decided that while I’m still going to have techy stuff on here, which would be impossible to avoid with the job I do, I’m not going to limit myself to just writing about code.

I’m also going to *gasp* do a bit of work on the site by actually doing a design and implementing it to fit in with my new content.

Right now I should probably apologise to the many readers of this blog which would be disappointed by this approach, but I see the stats – adding blowing tumbleweed would be an improvement.

Hopefully this new approach will get me writing more, and hopefully there’s someone out there who may be interested in what’s here, but realistically guys – I’m doing it for myself.   Sorry.

OK – this isn’t a biggie but maybe it’ll help some other poor soul.  Basically I’m loading XML into my swf.  It’s in ActionScript 2………… lots of reasons why, but no matter.  I’ve shaken the dust off my OOP AS2 muscles and got started.

I was happily loading and parseing the XML when suddenly I was told that we wouldn’t neccessarily be getting the XML from a flat file but also from a webservice.  No probs, thought I gaily, all I need to do is point at the webservice and call the XML.  It’s formatted exactly the same – should be fine.

Nope.  Basically when I’d been loading the static XML I was casting the type to XML like this

var loadedXML:XML = XML(loadedFile);

This works fine for a flat file.  However if you are loading from a webservice it ignores the xml structure of the recieved data and treats it as a single string.  To fix this all you need is to amend the above to : -

var loadedXML:XML = new XML(loadedFile);

Here’s an interesting widget from www.nseries.com/vine.

OK, so here’s the situation, you’ve got a swf that is using the ExternalInterface class for communicating with Javascript.  You’ve got it running on ASP.net.  You’re using SWFObject to embed the flash.  It all works hunky dory in Firefox, Safari and in IE it’s OK when you call the function from the flash.  However when you try to get the Javascript to call a function on the swf nothing works.

The problem is that ASP.net renders the page in a form, so using something like window["movieName"] to get the movie it isn’t looking in the right place.  Change the call for IE to return document.forms[0][movieName]; and Roberts your mothers brother.  And you can stop swearing and threatening to kill your Project Manager when they ask time and time again if it’s done yet.

Right – I’m pretty grumpy! Very grumpy in fact.  I’ve been working on a project and needed to use tweening.  So I thought no bother, quick job I’ll just use the standard Adobe AS3 tween classes.  Nice.  However all of a sudden I noticed that some of them started to hang.  Not all the time, I couldn’t replicate it consistently and also as the app relied on using the animations finishing to trigger the next event it was breaking the app.

If you’re having this problem check out this blog post and there is a fix in the comments.

Now we’ve got the data back we need somewhere to store it.  This is where the model comes in.  Let’s create a ModelLocator called MemoryModelLocator.  It implements IModelLocator.  The interface doesn’t actually require any functions, it is just there to type the class.  Here’s the class

package com.worthyashes.simpleCairngorm.model
{
	import com.adobe.cairngorm.model.IModelLocator;
	[Bindable]
	public class MemoryModelLocator implements IModelLocator
	{
		//Singleton code
		private static var _instance:MemoryModelLocator;

		public function MemoryModelLocator(enforcer:SingletonEnforcer)
		{
			if (enforcer == null)
			{
				throw new Error("Like at the end of Highlander, before the crap sequal, there can be only one");
			}
		}

		public static function getInstance():MemoryModelLocator
		{
			if (_instance == null)
			{
				_instance = new MemoryModelLocator(new SingletonEnforcer());
			}
			return _instance;
		}
		//End of singleton code

		//Pop your vars into the model from here on
		public var loadedData:XMLList = new XMLList();
	}
}
class SingletonEnforcer{}

This is pretty much what we did in part two, the only addition being the variable loadedData which is of type XMLList.  Remember the most important thing is that this whole class is bindable.  This allows us to access the variables in this class using dynamic data binding.

Lets get the data in.  Back to our LoadXMLResponder class, remember Models in Cairngorm should ONLY be modified by a Command or a Responder.

package com.worthyashes.simpleCairngorm.responder
{
	import com.worthyashes.simpleCairngorm.model.MemoryModelLocator;

	import mx.rpc.IResponder;
	import mx.rpc.events.FaultEvent;
	import mx.rpc.events.ResultEvent;

	public class LoadXMLResponder implements IResponder
	{
		public function LoadXMLResponder()
		{
		}

		public function result(data:Object):void
		{
			var resultEvent:ResultEvent = data as ResultEvent;
			trace("XML loaded");

			var memoryModel:MemoryModelLocator = MemoryModelLocator.getInstance();
			memoryModel.loadedData = resultEvent.result.block as XMLList;
		}

		public function fault(info:Object):void
		{
			var faultEvent:FaultEvent = info as FaultEvent;

			trace("Fault at [LoadXMLResponder] " + faultEvent.message);
		}

	}
}

Obviously we populate the data in the result function.  We create a local variable of the memoryModel, don’t forget that as a Singleton we can’t access it directly, we need to call the static getInstance() function on the class.  This ensures that we always get the same singleton back regardless of where we are in the application.  As we are using the e4x result format we can use dot notation to drill down the XML to return the XML <block> nodes as an XMLList.

So – great we’ve populated the Model.  Whoopy do.  Well whoopy do indeed, because we’ve got the data in a class that is the same at every point in the application and it’s bindable.

Look back at the main application file, currently we have a Tree component and a TextArea component.  Lets ignore the TextArea component for a mo and we’ll focus on the Tree.  I’m going to take the Tree and it’s holding Box out of this file and create it as a custom component in the view folder.

<?xml version="1.0" encoding="utf-8"?>
<mx:Box  xmlns:mx="http://www.adobe.com/2006/mxml">
	<mx:Script>
		<![CDATA[
			import com.worthyashes.simpleCairngorm.model.MemoryModelLocator;
			[Bindable]
			private var memoryModel:MemoryModelLocator = MemoryModelLocator.getInstance();

			private function renderLabel(item:Object):String
			{
				var node:XML = item as XML;

				if (node.localName() == "block")
				{
					return node.@title;
				}
				else if (node.localName() == "item")
				{
					return node.@name;
				}
				return "Something went wrong!!";
			}
		]]>
	</mx:Script>

	<mx:Tree dataProvider="{memoryModel.loadedData}"
			 width="100%"
			 height="100%"
			 labelFunction="renderLabel"/>
</mx:Box>

So what’s happening here?  What we are doing is creating an instance of the MemoryModelLocator class, and binding it to the tree as it’s data provider.  This means that when the LoadXMLResponder loads the XML and changes the property loadedData it updates the Tree component.  This is what we mean when we say the model updates the view.  The model doesn’t ‘know’ it has a view watching it, but when it changes regardless it updates the data being used by the views bound to it.  Pretty cool.  All we need to do now is render the label for the Tree and we are done!

Pop this into the main application file

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
				xmlns:view="com.worthyashes.simpleCairngorm.view.*"
				xmlns:control="com.worthyashes.simpleCairngorm.control.*"
				xmlns:business="com.worthyashes.simpleCairngorm.business.*"
				creationComplete="creationCompleteHandler();"
				layout="vertical">

	<mx:Script>
		<![CDATA[

			private function creationCompleteHandler():void
			{
				var loadXMLEvent:LoadXMLEvent = new LoadXMLEvent();
				loadXMLEvent.dispatch();
			}

		]]>
	</mx:Script>

	<control:SimpleFrontController id="frontController"/>

	<business:Services id="services"/>

	<mx:Panel title="XML Display" width="600" height="500">
		<mx:ViewStack width="100%" height="100%">
			<view:XMLTree id="xmlTree"/>
			<mx:Box>
            	<mx:TextArea/>
            </mx:Box>
		</mx:ViewStack>
		<mx:ControlBar>
			<mx:Button id="btn_tree" label="Display as Tree"/>
			<mx:Button id="btn_datagrid" label="Display as Datagrid"/>
		</mx:ControlBar>
	</mx:Panel>

</mx:Application>

We’ve again created an xmlns with the name of view to allow us to access the com.worthyashes.simpleCairngorm.view package.  So now when we run this we will display the XML in the tree.

Next let’s have a look at using a ModelLocator to manage state.

We’ve created our LoadXMLEvent, created our FrontController and that has linked the event with the command to get the XML. Now we need to create our next set of classes. The Delegate class deals with retriving the data, it does this by using another Cairngorm class called the ServiceLocator. As the Delegate is getting some data we need to create a Responder to recieve and deal with the data. As this is a simple application we could make the Command the Responder too, but as I want this to be a pucker representation of how Cairngorm works I’m going to go ahead and create the Responder.

So – lets create the ServiceLocator. The ServiceLocator is a ModelLocator really, and is where you keep all of the data calls for the application. This is a great thing to do as the service locator is where you call the server side code, or as in this case load the XML. This means that if you’d developed an application with a ColdFusion backend and needed to port it over to AMFPHP then you should only need to swap out this class and it should all function as expected. (Note the use of the word ‘should’)

Anyway lets have a look at it.

<?xml version="1.0" encoding="utf-8"?>
<cairngorm:ServiceLocator xmlns:mx="http://www.adobe.com/2006/mxml"
		          xmlns:cairngorm="com.adobe.cairngorm.business.*">

	<mx:HTTPService id="xmlService"
			resultFormat="e4x"
			showBusyCursor="true"/>

</cairngorm:ServiceLocator>

So to create this right click on the business folder and select new -> MXML component. It doesn’t matter what you choose as the component as you can see from above we are going to use our own tag to identify it. Add the xmlns declaration so we can reference the com.adobe.cairngorm.business package. Once you’ve done that pop the HTTPService tag in. This is what will load the XML and we’ve set the result format to e4x so we can use the e4x syntax to work with the XML returned.

Right one down. Now we’ll create the responder. Right click on the responder folder…..actually, by now I think you’ve got the hang of creating classes. I’ll just describe them. The responder classes live in the responder folder need to implement the IResponder interface.

package com.worthyashes.simpleCairngorm.responder
{
	import com.worthyashes.simpleCairngorm.model.MemoryModelLocator;

	import mx.rpc.IResponder;
	import mx.rpc.events.FaultEvent;
	import mx.rpc.events.ResultEvent;

	public class LoadXMLResponder implements IResponder
	{
		public function LoadXMLResponder()
		{
		}

		public function result(data:Object):void
		{
			var resultEvent:ResultEvent = data as ResultEvent;
			trace("XML loaded");
		}

		public function fault(info:Object):void
		{
			var faultEvent:FaultEvent = info as FaultEvent;

			trace("Fault at [LoadXMLResponder] " + faultEvent.message);
		}

	}
}

The result and fault events are called by either a -er- result or fault. To implement the interface correctly they have Objects passed in as parameters, but they are actually ResultEvents and FaultEvents respectively. This is why I’ve immediately created a local variable of type either ResultEvent or FaultEvent and cast the objects into it. If you’ve been hunting for tutorials on Cairngorm you’ll probably have seen something similar to “Fault at [LoadXMLResponder] “. I can’t remember which tutorial uses this, I’ll pop a link in when I find it, but this has been a lifesaver a number of times for debugging.

OK now we create the Delegate class that sticks this all together. The delegate also lives in the business folder, but doesn’t extend or implement anything.

package com.worthyashes.simpleCairngorm.business
{
	import com.adobe.cairngorm.business.ServiceLocator;

	import mx.rpc.AsyncToken;
	import mx.rpc.IResponder;
	import mx.rpc.http.mxml.HTTPService;

	public class LoadXMLDelegate
	{
		private var responder:IResponder;
		private var service:HTTPService;

		public function LoadXMLDelegate(responder:IResponder)
		{
			this.responder = responder;
			this.service = ServiceLocator.getInstance().getHTTPService("xmlService") as HTTPService;
			this.service.url = "xml/example.xml";
		}

		public function loadXML():void
		{
			var token:AsyncToken = service.send();
			token.addResponder(responder);
		}

	}
}

There we go. The delegate holds a referenced to the responder and the service to call. Then when called to load the XML it triggers the load on the service and adds the responder to the service. This is why the Responder needs to implement IResponder and have the result and fault events. Now we get the Command to create the Delegate and trigger it.

package com.worthyashes.simpleCairngorm.commands
{
	import com.adobe.cairngorm.commands.ICommand;
	import com.adobe.cairngorm.control.CairngormEvent;
	import com.worthyashes.simpleCairngorm.business.LoadXMLDelegate;
	import com.worthyashes.simpleCairngorm.events.LoadXMLEvent;
	import com.worthyashes.simpleCairngorm.responder.LoadXMLResponder;

	public class LoadXMLCommand implements ICommand
	{
		public function LoadXMLCommand()
		{
		}

		public function execute(event:CairngormEvent):void
		{
			var e:LoadXMLEvent = event as LoadXMLEvent;

			var delegate:LoadXMLDelegate = new LoadXMLDelegate(new LoadXMLResponder());
			delegate.loadXML();
			trace("Getting the XML");
		}

	}
}

All we’ve added is

var delegate:LoadXMLDelegate = new LoadXMLDelegate(new LoadXMLResponder());
delegate.loadXML();

Finally we need to instantiate the ServiceLocator, otherwise we won’t be able to use it.  Back in the main application file add the xml name space in the opening tag of

xmlns:business=”com.worthyashes.simpleCairngorm.business.*”

and add this MXML tag

<business:Services id=”services”/>

That’s it.  If you run the code now all being well you’ll get a trace to tell you the XML is loaded.

So now we’ve got the data loaded we need somewhere to put it, which takes us all the way back to the discussion of singletons. Next we are going to create a ModelLocator to hold the data.