A short point about quality of equipment.

February 20th, 2010

Last night and this morning I conducted 2 experiments.

The first experiment was last night before I went to bed, where I timed how long it took my work laptop, running windows XP to shut down. 4 minutes 20 seconds.

I think you can probably guess that the next experiment was to test the time it took to boot up. 3 minutes.

Now, I’ve read people make the same point that I’m about to make several times. The most famous being Joel Spolsky, in his blog and books. The point was really driven home when I attended the Cambridge dev days conference 2009 and was told that at the first conferences, during the breaks they had set up a stall offering to upgrade the ram in your laptop to it’s maximum, for FREE. This was how important Joel thinks it is for people to have the best equipment available to him.

laptopopencrop

For two years I have accepted the equipment I was given as one of life’s little endurance tests. Everybody got the same. Accept it and move on.

But last night, after writing my hat change blog post, I realised something really obvious. For two years, I have started and shut down that laptop on average once a day if not more. There are 365 days in one year. 4.2 + 3 = 7.2 minutes a day. Waiting. Waiting for my equipment to be usable. 365 times 2 years is 730 days * 7.2 = 5265 minutes. 5265 minutes can also be said as 3.65 days, or if we talking working days (8 hours) 10.96 days.

Over the last 2 years I have wasted 10.96 WORKING DAYS of my F*UCKING LIFE WAITING FOR A CRAPPY LAPTOP TO SHUT DOWN AND BOOT UP.

To put that in terms a businessman can understand, my daily charge out rate for the company is somewhere in the ball park of £1,000 per day. That means, someone has paid £11,000 over the last two years for me to stand around waiting for my laptop.

Now, I’m no financial genius, but it seems to me, for £11,000 I could buy some pretty shit hot equipment. I mean for 3k I could buy a pretty amazing laptop and still have 8k to play with. The scary thing is when you multiply this by the number of people working in the company it gets into the tens of millions per year wasted.

I guess my overall point is the people who you work for are your most important asset, you should be proactively giving them equipment to try to enable them to do their job as efficiently as possible and grow them as much as you can as they are what is making you money.

Update

I just finished watching Bill Gates’ latest TED talk on his new mission to solve the energy problem.

Thinking back to this blog entry I started to wonder how much of an impact the inefficient equipment we provide people wastes valuable human resources and adds to our carbon debt, and how efficiency is actually every bodies problem, not just the concern of the rich. Also it was annoying because my broadband connection sucks making the video take 45 mins to watch rather than 27 mins. I wondered how much extra carbon shoddy services from Giant companies like Virgin media and BT end up pumping into the environment.

When collection verges dangerously on obsession.

February 20th, 2010
SP_A0700

5 1950’s, 60’s & 70’s Samsonite attache cases.

Hat change!

February 19th, 2010

I’ve been fairly quiet recently in terms of posts, this is mainly because I’ve just resigned as Senior front-end developer at Sapient and accepted the post of “front-end specialist” at Nokia in Berlin.

hats

From April 1st 2010 I will be working on the Ovi maps project. Ovi maps interests me for several reasons, firstly it’s got a massive user base and so is a chance to really get stuck into a application that’s just getting into it’s stride. There’s a great opportunity to start making small engineering changes that really a big difference in terms of performance and usability. It’s served to such a wide variety of different devices/platforms that I will get to see the realities of large mobile app development as well as hopefully bringing in some learned best practices from the web app world regarding CI and Continuous testing. I would also like to do some developer relations promotion, as before interviewing for the job I had no idea what Ovi maps was. Obviously now Ovi’s had a bit more PR but the developers remain relatively anonymous. Something I’d like to change given the quality of people working there.

I will be sad to leave Sapient, although it has it’s problems there a few really spectacular people there, whom I wish all the success for in the future and hope that some things begin to change.

All I have to do now, is figure out how to move my entire flat and life to another city, ekkk.

Why I f*cking hate JSP.

February 8th, 2010

Enforcing Strict Model-View Separation in Template Engines by Terrance Parr

The short version is that JSP makes XHTML VIRTUALLY IMPOSSIBLE to validate in it’s fragmented form, which would be much, much, faster than compiling it and then running an html test on a server version to check it’s validity. “Fail fast” is the phrase du jour with CI/CD and JSP prevents this, as well as creating a HORRIBLE HORRIBLE mess of crappy crappy code.

So in short, never use JSP, or Faces, or any of those other ridiculous technologies. The only thing that prevents you using String template is unfounded fear. The pain you save your developers is worth it. Trust me.

Proffesional Self Assesment for 2009

January 11th, 2010

I am just filling in my companies annual self assessment form and thought I would share some of my thoughts regarding 2009.

Value and Quality

“Quality is doing things right when no-one is looking” this is a quote from John T Ford, mentioned in the infamous software book “The Mythical Man Month” by Fredrick Brookes. This year I have strived to fulfil this meme to it’s upmost. I believe the quality achieved by automating things that previously used unreliable human methods to achieve adds the same level of value to the client as the entire creative process. A relevant historical example of this can be found in the automotive industry and the subsequent collapse of poor quality American vehicle engineering as the Japanese and Asian markets obliterated them with durable, reliable, inexpensive import cars. The same is true of software and the beginning of this trend can be seen in companies like Goggle.

Productivity

This year, I have learned about the most important form of productivity as espoused by the agile and Lean principles. “Sustainable development” is a quality generally completely misunderstood in this certain circles, but is in fact the source of a large amount of client dissatisfaction. Selling projects in under budget and with the assumption that developers will work overtime to get them completed is a fallacy perpetuated by incompetence. Rushed, ill thought out work leads to unrealistic expectations for the client and ultimately disappointment in the output which is then reflected onto our company and the production staff. Even more harmful is the attrition it leads to as experienced developers leave unfulfilled and frustrated. In which case productivity should be measured by a lack of overtime and encouragement of advanced thinking.

Strategic Context

With a marketplace of vendors that are consolidating into large inefficient groups driven by bureaucracy and nepotism, trying to win the business of other larger inefficient monoliths, there are few things that will allow one to distinguish themselves from the crowd. Honesty, integrity and reliability are the three main things that will allow us to stand tall above the rest and are the most important things for our strategic context in terms of winning the business of the companies of tomorrow.

Quickstart tutorial to Mercurial and GoogleCode

January 3rd, 2010

I love using new technology. I really do. It’s great, basic things you knew how to do with an older system, get reinvented and become no longer trivial. They become a long drawn out, painful process, that involves your blood pressure raising to that perfect level where it reduces you lifespan by a twenty minutes. Each time.

mercurial-logoSo when I switched to command line Mercurial from Tortoise GUI SVN, you can imagine my delight.

To be fair, I actually had already got command line SVN experience, so thought the transition might be somewhat simpler. It wasn’t. The commands may be very similar but the process itself is not.

code_logoFrustratingly it is actually very simple once you know the command-set to get you up and running, unfortunately no has written a basic, 123 guide to setting up a googleCode mercurial instance on windows XP. So I thought I’d be the first.

  1. Download and install Mercurial command line. Make sure to check the last check box on the installation screen along with the readme, this allows you to access Mercurial from the command line.
  2. Create your Google code project. This part’s easy, follow the steps enter the words and navigate youself to the main project screen. It helps if you already have a Google account.
  3. Now we get to the fun part. Open your command line in windows, by going to Start->run->type cmd in the input box and click ok. Or if you have style double click the short-cut you’ve created for yourself on the desktop.
  4. You’ll want to navigate to a folder where you can store your project. For the sake of this example, lets say your project is named testproject and is in the root of c:\. first back out to the root with:
    cd \
    
  5. Then make a directory to store the project in:
     mkdir testproject
  6. enter the directory
     cd testproject 
  7. Now you want to take a clone of your googlecode repository, to do this type the following command:
    hg clone https://testproject.googlecode.com/hg/ testproject
    
  8. The last parameter is the directory to copy it into on the local file system. This should result in Mercurial spewing out some output identifying that it has correctly downloaded.
  9. To check, type:
    cd testproject
    dir
    
  10. If it was successful, you’ll see a directory called “.hg”
  11. If it’s there, now you want to make your first commit. Create a text file called readme and dump it in the directory with the .hg in. To add your new files type:
    hg add *
    
  12. Next you’ll want to commit them, type:

    hg commit -m "added first file to repository"
    
  13. So you have commited your first change to the repository, but this does not mean it’s gone up to the main node on Google, it is currently just committed to your local file server. To commit the changes back up to Google’s servers, you’ll need to run the following:
    hg push
    

    This will prompt you for a user name and password, the password IS NOT YOUR DEFAULT PASSWORD. Go to your accounts hosting page to find it.

  14. Now, if your like me, i.e. LAZY, you don’t want to have to enter your username and password each friggin’ time you want to push. You want an automated way to authenticate your https googlecode push actions. The way to get around this is to open the “.hg” directory and find the file “hgrc”. Edit this in your preferred text editor. Where you see the line
  15. default = https://testproject.googlecode.com/hg
  16. change it to
  17. https://(your username here):(your password here)@testproject.googlecode.com/hg
  18. And Voila! everytime you push, it automatically skips the login and password steps.

I hope this helps, I spent sometime this weekend trawling the internet for clues as to how to do this most basic of processes but could find no simple explanation, written in a language people could understand.

Great public interactive promotional game

December 17th, 2009

While I was in Boston for this year’s Ajaxian conference, I was wondering around the main shopping area on Sunday when all the shops were closed, when I came across this installation for EA games.

It immediately caught my attention and watching people play it reaffirmed in my mind, what an incredibly positive effect this had on their brand perception. Interactive freebies like this, cost little to install, have no maintenance overheads and have a massive pay back. It’s just a shame more companies aren’t willing to invest in them, and agencies aren’t pushing them more strongly.

Synthetic Biology: The convergence of modern software and DNA

November 29th, 2009

I’ve been ranting about this in drunken pub conversations for a few years now. But finally someone with an ounce of academic credibility to back me up.

My 2030 prediction for my company is:

  • Instead of creating iPhone Apps will be creating bespoke organisms for clients:
  • IA’s will be architecting their functionality
  • GD’s will be designing how they look
  • Tech arch’s will be designing how they are built
  • Developers will be using a synthetic Biology language to write/model/build/print them
  • Testers will be testing them to make sure they meet the requirements
  • Project managers will manage these new bio-tech projects
  • And Account directors will continue to mainly play golf ;-)

A further interesting discussion of this was posted up by a fellow member of the London Futurists group.

Cleaning up production code with JSLint. Once and for all.

November 24th, 2009

Sit back. Close your eyes. Imagine the scene.

Your client is sat round a big 3 inch thick mahogany table, in a tastefully decorated 1930’s art deco hotel conference room. They lean back in their reclining leather chairs whilst sipping chilled Harrods mineral water served in crystal wine glasses. The leather creaks. The sun pierces the cloud glinting through the gaps in the blinds filling the room with a coruscating light, a dazzlingly you are praying to match in the events that follow. Formalities are exchanged and weather is discussed. A thin veil of cultural formality gives you a brief respite from the reason you all know you are there.

You tap the mouse connected to the macbook. The projector flickers into life. The first page of your masterpiece is lit up. Each pixel a glorious testament to your craftsmanship and the pain, sweat and blood you’ve slaved over for the past iteration. Each click though the journey provides the perfect accompaniment to your commentary, going deep and deeper into your world, building a crescendo around it that signifies your masterful control of your media. Click follows click. Ouuu follows ahhh. And then…

Bang!

alert

Has this or something along similar lines ever happened to you before?

Your heart sinks. Your face burns as the blood rushes like a stampede of elephants into your cheeks. You blush. You stutter a laugh. Make a self deprecating witticism about the realities of live demos. You click ok. You proceed with the demo. Inside you are crying tears of shame and remorse. “Why didn’t I catch that before?” you think.

Which, by the way, is wrong.

If you had more time to think about the question you should have actually asked is “why did that happen at all?”. To which the answer would have been, it shouldn’t.

Debug code, should never make it into the production environment. It’s just bad practice. Plain and simple. So the question becomes, “how do we stop it?”.

On my latest project I’ve been working with CI or Continuous Integration. I won’t go into the details of how CI works, you can find that out yourself.

As part of this, I’ve been using 3 very important tools: Maven, JSLint4Java and JSLint itself.

Maven is a build tool that allows me to add the marvellous JSLint4Java ant plugin to it. This means when Maven is triggered by the CI system, JSLint gets run on all the Javascript and CSS files in my project. If they fail the validation: the build fails. Simple as that.

console

Now, this gives us a lot power, to help both enforce code consistency, valid code and good code.

But up until recently, JSLint has not had the functionality to check for the javascript global alerts, consoles, debug or opera statements. But as of 19th of November 2009, after suggesting a console check, on the JSLint working group forum. The ability to be able to check for the globals: console, alert, Opera, prompt and debug have been added to JSLint by programming/Javascript legend Douglas Crockford himself.

AWESOME.

The new functionality comes under the ASSUME keyword, that when you switch off using the following code:

/*devel : false, debug : false */

will fail the file if any of those statements are present in the code…

This brings us one step closer to the holy grail of front end code RELIABILITY and eradicates the scenario I wrote about at the beginning of the post. But still doesn’t completely protect you from looking like an idiot in front of the client, so take care!

Coders block

November 18th, 2009

Sometimes trying to code can be like standing on the edge of an abyss.

abyss_ver3

You desperately want to take that leap off the firm, solid edge of reason and safety into the infinitely consuming unknown world of possibility that awaits you. But for all your heart, passion and fire, your brain is resolutely locked, frozen in place, destined to stare longingly out of your cold dead eyes at the wonders that could have been.

Your fingers tense as you try to force line after painful line of code from them. With each line you see another 3 lines that you should delete from earlier in the forcing process.

Each decisions you make is an excruciating process of taking a thousand different possibilities whittling them down and then taking a random guess that it’s the correct course of action. With each character you type your struck by the heinous unreusability of what your creating and that your never going to be able to get back to the pure zen state of a blank page that your soiling at this very moment.

You close your eyes and everyone who has ever condemned you as a failure, mocked your ability, or questioned any sense of validity as a human being is stood in a large circle pointing and riotously laughing at you.

This, this my friends is the hell of coders block.

A crippling affliction akin to the crushing sensation you get as a man when you fail to perform sexually, or the soul crushing moment at school where you are picked last for a sports team due to uncoordinated inability. One of those moments in life where you literally question the entire worth of your existence and pose the question “should I go on?”.

Well, maybe not quite that bad. But pretty damn close.

Today, I have failed to be at all productive. Infected by this disease of the mind, I have sat trying to code for 8 hours but achieving nothing more than responding to emails, reading blogs, writing blogs feeding my lethargic, flu infested body, festering in the social underbelly of mankind.

I even googled, coders block to avoid actually having to write any code! This is not a good day. The sooner it ends, the better…