Hmm. BBQs are my forte. I’m really good at charing meat on a grill. Actually, and this is being a bit stuck up, but I am genuinely good at barbies, so when my best mate Seb came down to see us and wanted one then I was in my element. However Valentina is a veggie. So that’s why this started with a ‘Hmm’.

K, lets start with the meat eaters BBQ grub

My Mums Burgers

These bugers were taught to me by my Mum. She says that she got them from the Australian Woman’s Weekly, but what’s really nice is that you can much about with the recipe so much to your own favorite flavours. The key in these sausages is that there is no mucking about with egg or breadcrumbs, you use sausage meat to bind them together.

Recipe

For 4 burgers

• 300g Beef Mince
• 3 good sausages (pick a real sausage like Cumberland, Linconshire or something. You want a sausage with herbs and flavour in it.)
• 1 garlic clove (or a good teaspoon of the pre chopped stuff)
• 2 teaspoons of wholegrain mustard
• 1 Red Onion finely chopped

Chop the onion finely and then pop it in the microwave. Give it 3 minutes radar love. (That was with a 750w oven) The onions want to be soft but not falling apart – so if it needs a bit longer then give it another 30 secs. I find it easiest to nuke the onions in a bowl large enough to do the mixing too – in my case it’s a large mixing bowl.

Once the onions are sorted then put the mince, garlic ad mustard in. Take the skin off the sausages (just run a knife down then and chuck the skin away) and put the sausage meat into the bowl. Now for the fun bit – mix all of the ingredients together. That sounds quite gentle, don’t be. Beat the crap out of the mixture, you want to really mix this together.

Finally shape into 4 simialr sized balls and then flatten into a burger. They can be around 1-2 cm tall, so you are looking for flatened meatballs rather than perfect patties.

Cooking

OK I’m going to do a different post on getting a BBQ ready to cook, but I’m going to assume it’s at temperatue (red coals, no flame) basically really quite ‘king hot.

Pop the burgers on and then – DON’T YOU DARE TOUCH THEM UNTIL THEY HAVE SEALED. DON’T EVEN TRY. YOU PICK THEM UP AND THEY WILL FALL APART. Seriously. I normally leave them for around 5 – 10 mins and then I turn them over. You want them to be a bit charred before turning over. The point is with these burgers is flavour – you don’t want to have a rare burger with this recipe as it’s pork and beef mixed up.

Another 5 – 10 mins and you’re done.

So that’s the burgers – with them we cooked the sausages we didn’t use in the burgers and some fantastic ribs from the butchers pre marinated in BBQ sauce. Lovely.

But what does Valentina eat? Well fortunately she told me. And you know what – I thought she was either crazy or trying to be undificult house guest. We popped to the supermarket and she bought courgettes and aubergine and told me to just grill those

I felt awful – Valentina was only going to get charred vegatables. That was really not what I like to do when people come round, I want everyone to have a good time, good music and good food and Valentina was only getting a token meal.

Recipie

• Some sort of vegetable, sliced

Cooking

Pour olive oil on the vegetable. Grill it on a hot grill. (To add insult to injury the barbie wasn’t hot enough and I had to use a griddle pan).

How boring it that? We had aubergine and corgettes. Seriously dull. Sorry NO! Brilliant. Simply grill the veg, make sure it chars a bit and they are fantastic.

So from now on I’m going to definately still do my burgers (ok my Mum’s burgers) and I’m going to also grill some aubergine slices on the side!

I would like to propose a new law. If you are shopping in a supermarket you are allowed, with no consequence or dilema, to ignore people you know and get on with your business. No chit chat, no small talk, no conversation whatsoever.

I’m not being grumpy, well I am a bit, but my brain isn’t in conversation mode when I’m in Budgens, I am there for one reason and one reason only. I am buying stuff, and not particularly interesting stuff. Bog roll, Fairy liquid, mince, etc. I’m looking at a list, I’m trying to remember what goes in a mousaka, my brain is not in the right gear to switch into chatting.

Even worse if you bump into people just as you both arrive, after a quick disultory chat you then spend the next half hour bumping into each other as you go up and down the aisles doing the slightly embarressed nod and smile.

So – from now on – if I bump into you in Tescos I’ll say ‘Hi,’ and crack on. I’m not being rude, I’m not ignoring you I’m just trying to get my shopping done. If we see each other down the pub then of course I’ll talk to you and be friendly. Unless I’m trying to order a drink. Then you’ve got a better chance having a chat with Elivs.

I think that the time has come for me to compile my list of development nos. I’ve contracted for a while now and I see these things again and again. It could be read as a moan, but I hope not – these are my genuine thoughts on what not to do (unless you want to seriously jeopodise your application development). As with all lists like this it needs to be taken with a pinch of salt and also you need to recognise that there are situations where is is impossible to aviod doing them.

1 – Unrealistic time frames / deadlines

This is an easy excuse for a developer to use. Especially when the business owner has said it needs to be done in X amount of weeks without checking with the dev team if it is realistic, feasible or even possible.

Mind you – devs can be just as bad. I have myself gaily said “Should take a few days, a week max!” and then had to work late and still not make the deadline because I hadn’t thought the problem or application through properly.

SOLUTION

If you are a business owner talk to your dev team. Get them to think about it and give you timeframes.

If you are a dev DON’T give ballpark estimates. Think about it, look at the potential pitfalls, problems and also factor in some fuck up time. However don’t over estimate wildly or the business owner will start to get frustrated and will bipass you.

2 – Don’t work late

Beyond the obvious that people start to expect it, this is tied directly to point one. If you are consistantly working late, or even worse pulling all nighters, then it is an indicator that you have unrealistic time frames. At many agencies where I’ve contracted it is de regur to work till 8-9 in the evening (mind you sometimes people don’t get in till 10-11) or go all night in the run up to go live.

This is crazy. tired devs / designers / copywriters / project managers make cock ups and forget things. Whenever I’ve found myself in these situations at 9 at night I’m certainly not doing my best work. At worst I’m introducing new bugs into my code as I make mistakes. At 2 in the morning your “quick fix” could the next morning take 2 hours to rectify, and all of a sudden you are back where you were in the first place, just more tired. Things get forgotten, people get grumpy (in my case, really grumpy) and it turns into a “Lets just get this fucking thing done!” exercise, not “Let’s do it right so we don’t have to do it all over again.”

SOLUTION

First things first – see point one and don’t get into this situation if at all possible. However. We all know that there are situations where you need to do these sorts of hours. But plan for them. In the run up to a go live I tell my wife that for at least the last couple of days before I’m going to work late. She knows, I know and all is good. (Plus if it goes smoothly I can pop to the pub on the way home! Only joking Darling….. )

It’s when you don’t that you need to stay late and your loved one has organised a surprise special meal that you have problems. (For some reason – even though it’s a surprise it’s still your fault it screwed up!)

3 – No spec

“It’s really simple, it just does x,y and z.”

or

“It’s just like the other one you built, it just needs to do x extra.”

These, people, are NOT specs. It may be ball achingly clear to you what the application needs to do, but what I think is clear may be a million miles away from what you think is clear.

SOLUTION

Don’t risk it even for the simplest of build. Even half a page of bullet points is better than a quick chat.

4 – Boatloads of requirements

This sort of flies in the face of point three, but sometimes in order to make sure that the spec covers everything it covers EVERYTHING. Every conceivable, probably, possible or unlikely thing the app should, could or may do is piled into the spec.

To even start to try and build something based on a spec like this can be really intimidating and can be counter productive. You’ll spend the majority of your time building this massive app engine to cover everything on the spec and find that most of it isn’t used.

From extreme programing - 90% of this additional functionality will NEVER be used. So don’t bother building it.

(I shudder when people start talking about building generic applications to cover all sorts of situations)

SOLUTION

Pare the spec right back to the bare minimum to fulfil the brief and then iterate. Go for many little releases that one massive one.

5 – Forgetting that it needs to be tested (and that fixing bugs takes time)

So it’s all working on the laptop and (if you’ve got one) you’ve run through it on the dev server. All good to go then!

Well if you’re lucky all will be fine, but the law of Murphy will raise it’s ugly head.

Basically if you don’t test you are a muppet. And even though the dev that built it can do some of the testing the best is for someone else to do the testing. This tester should run some scenarios, hammer it (click on everything that can be clicked on – a lot) and try out unusual user journeys. If the dev does it they are so used to the system that they won’t do anything wierd, get lost, click on something stupid, refresh in the middle of a call to the server etc. And trust me doing stuff like the above will generate bugs.

Now for the important bit.

BUG FIXING TAKES TIME.

Sometime ages.

There is a perception that once we are in testing we are basically done. It’s a rubber stamp thing. There is also a perception – especially from the non coding side of the business – that once it goes into testing it should be finished, and if a bug shows up then the coders quite clearly don’t know what they are doing. I’m sorry but I’m sure that even Stephen Fry’s first draft of the QI script with have the odd spelling error or gramatical mistake.

SOLUTION

Appreciate that testing and fixing the bugs that come up are a part of the process, as important as building the app. Make sure there is a reasonable amount of time for this and push back at people trying to rush this vital part of the build through. A really good application can be ruined at this point where it is released early with bugs so it sinks without trace.

---

I hope this doesn’t come across as a moan and I also know that nothing I’m saying here is rocket science. What I do hope I’ve done is justify and explain why these are development no nos.

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.