jamesdeakin.com

http://news.bbc.co.uk/1/hi/technology/7918839.stm

 

 

 

http://labs.ideeinc.com/multicolr

I love this project. It searches the creative commons images on flikr by multiple colours really simple idea but results in something just brilliant.

The Tale of How from Shy the Sun on Vimeo.

Just watch.

I know this is an oldie but after listening to Jonathan Harris at Flash on the Beach I can’t help but post about it. This piece of software is based on a very simple idea. It grabs any sentence from the blogsphere which has the word “I” and the word “feel” in it. It then grabs that sentence and any image associated with it and represents it in the analysis interface. 

The graphic design is great. But that’s not important. Likewise the technology behind it which is also excellent is unimportant. What matters is that the result is compelling. Its human and it is truly engaging. We need more art of this sort. it has the capacity to tell us about the emotional life we live. I work in an industry which prides its self on creativity but compared to this most of the ideas are simply poor. We feel fine has been around since 2006. Its time someone came up with something to rival or beat it. Anyone feel up to the challenge? I feel fine how about you?.

Amit Pitaru makes amazing software and collaborates with James Patterson of presstube fame. You can try out his excellent sonicWireSculptor at the url below. 

http://www.pitaru.com/sonicWireSculptor/framed/

I was lucky enough to attend Flash on the Beach last week. Flash on the Beach is a conference all about the Flash platform and digital creativity. 

I was lucky enough to have the chance to present at LFPUG last Thursday (25th Sept 08). I talked about ActionScript in commercial environments. I had a great time and I was pleasantly surprised by the enthusiasm people had for my chosen subject. 

Here is a rough transcript of what I said. 

Who is this guy?

Hi, my name is James Deakin. I am associate technical director at Dare. Dare are a leading digital marketing agency. 

What have you done?

Dare produce digital marketing work for companies such as Sony, Sony Ericsson, ITV, Barclays, Woolworth’s and Vodafone. We produce lots of work on the Flash platform. Before working at Dare I worked for Razorfish and before that I owned and ran a digital Marketing agency. Prior to that I worked as a freelancer and contractor for most of the agencies in london including Glue, Beatwax, EHS BRANN, Greenroom digital. 

Why this subject?

This might be a sightly odd thing to to want to talk about. I could have talked about Flex or frameworks such as Gaia, Cairngorm or Pure MVC of something else. The reason I choose to talk about ActionScript in commercial environments is that that is what most of us do for a living and The most important thing I have had to learn about being an ActionScripter is how to work with the organizations which were paying me to write code. 

About 10 years ago I was an art school graduate. I had been playing around with the web and made lots of animations with a bit of software called FutureSplash Animator. I found that the only thing that I was interested in that I could make money out of was web development. I went out and got a job and found that the tough things were not what I expected at all. 

Your dream job

Close you eyes for a moment. Imagine that you have just landed the best job in the world. You get free beer on a Friday, free breakfast every day, you would go home on time every day. You do exciting and work all the time. Everyone respects you programming skills. The CEO or MD drops by to just to compliment you on your ANT scripts. You always finish project on or before the dealine. Your getting paid shed loads of money and every one wants you to work with you. 

Reality 

Ok open your eyes and wake up from your dream. What happens in reality is often very different. Lots of really capable talented programmers work late. Very often when things go wrong its the developers who end up working the weekend. They are often stressed and for some reason account people love shouting at them. 

Why is that?

1. ActionScript projects are rarely well planned. 

The IA’s, Designers, and creatives who dream up ideas for Flash sites and rich media advertising have no idea how complex those things are to realize. They often go for the hard route when there might have been a really easy solution right in front of them.

2. Its easy to underestimate the complexity of an RIA. They tend to Involve time based interactions. Project managers, IA’s and designers are still used to thinking in terms of flats pages. Thinking about multiple states and processes which happen over time and may happen asynchronously is just beyond most people. When you have transitions the fact that they might be interruptible makes the code that runs the application far more complicated. 

3. Project managers still don’t know enough about the technology in fact the amount they don’t know is increasing. Because ActionScript and coding is always moving forward and new ideas and approaches are being used means that non technical people actually know have more to learn. 

So that means there is more of the unknown all the time.

4. the impact of change is poorly understood. 

Imagine you have architected a beautiful application. The UML looks great and you are about half way through developing it. Then you find out that it has to be localized into 30 languages including Hebrew and Russian.  

What to do about it?

You are the best manager in the world

Absolutely without doubt you are the best person to manage your time. You know better than anyone what you are capable of. Also you are the person best able to organize your time effectively. You know what’s likely to be tricky. Its up to you to be a leader. Even though your not the boss. Assuming that the PM does not know 

Communicate

This may come as a shock but some project managers don’t know everything they need to know. Stereotypically, programmers are not good communicators. Some take a perverse pride in poor communication skills. Its tempting to think RTFM. We don’t have to be able to communicate because if you could just look at the code you’d be able to understand.

Project problems are your problems

We are at the end of the process if somebody made a mistake we have to fix it. If the wireframes and process flows etc don’t describe what the system has to do your in trouble. Its up to us to tell the Project managers that they have to sort it out.

Be honest with your self

It’s really easy to fall into the trap of thinking that you can do more than you can. If your estimations of how long its going to take you to build something are based on full days of undisturbed work then you are in trouble.  

Always have a plan B

When a project is in trouble its really tempting to just get your head down and keep coding. If the project manager is really on the case they will have planned for the situation and will know what to do. If they don’t don’t just keep coding knowing that you will miss the deadline. Can you deliver part of the job for the deadline and the rest later? Can you full fill the main KPI’s with a simpler implementation.

Flag dependencies 

A great developer looks at a project and sees dependencies. Sadly project managers don’t know what you know. You need to tell them when you will need the designs for a page, the images that go on it or the sounds and animations your going to need.

Think about the user

Its everyones job to think about the user. If you get designs and you can see that there is a great big video file on the loading page you need to tell people that thats a problem. Because if you don’t it will be you implementing the changes when the client complains.

Ask for help

A great developer takes pleasure in a challenge.  A great developer, then, enjoys banging up against a brick wall and slowly breaking through it.  Some walls are thicker than others, however, and sometimes the wall has a developer-size hole that the developer continually manages to miss.  A great developer realizes when it’s time to ask for help and does so.  A great developer knows who to ask for help.  A great developer knows there isn’t any shame in asking for help.

Plan before coding

If there is no time allowed in the project plan for technical design the project will be a disaster. A great developer takes the time to plan an approach before designing or coding.  A great developer knows that the time required to do so will be more than paid back by the time saved by getting it more right the first time.  A great developer plans all scales of work, from envisioning multiple versions of a product to writing or modifying a small method. 

Write situation-appropriate code

Any developer can write code.  A good developer writes solid code.  A very good developer writes elegant code.  A great developer writes code that is both solid (compact, well constructed) and elegant (precise, simple, graceful, polished).  More importantly, a great developer can tell when elegance is not worth the effort.

know the tools

A great developer knows what the available tools are and how to use each of them.  A great developer knows that not every tool is appropriate for any particular task.  A great developer knows how to abuse the tools to produce results hard or impossible to accomplish via “approved” uses.

Don’t make assumptions

A great developer actually does make assumptions, but a great developer doesn’t stop there.  A great developer inspects the assumption, then researches that assumption into knowledge.  A great developer does this not just for their own assumptions but for assumptions other people make as well.

Document stuff

A great developer documents everything.  A great developer strives for self-documenting code but knows that some amount of documentation is always required.  A great developer knows that documentation need satisfy only two goals:  educate the current audience, and preserve enough knowledge about the topic that the current audience can expand the documentation as necessary for any future audience.

Use version control

A great developer knows that version control is as important for personal projects as for enterprise projects.  A great developer version controls everything.

Make lots of small check ins

A great developer knows that version control is most useful when code is modified via small checkins that each contain a single logical change.  A great developer strives to check each change in independently from each other change.

Develop good judgement

A great developer understands the business case for the code he is writing.  A great developer uses this as a basis for judging what code to write and what code should not be written.  A great developer uses this as a basis for deciding when to write code and when writing code is not the right thing to do.  A great developer uses this to balance designing for the future against the need to get something done in a timely manner. 

Try to have no ego

A great developer values the praise of their customer over the praise of their peers.  A great developer wants to do the right thing but doesn’t much care about being right.  A great developer brings their reasoned opinion to design and coding discussions but listens carefully when alternatives are offered, searching out and examining the details of these other options.  A great developer appreciates suggestions for improving their code or design.  A great developer knows they will write bugs and appreciates it when bugs are brought to their attention.  A great developer follows a process because the process protects them from themselves.

I am currently associate technical director at Dare Digital.