I don't understand the Australian IT business

Here in Australia employers are screaming out that they can't get skilled IT employees.

The situation is so bad, apparently, that we need the visa rules changed to allow IT specialists into the country (this link is one example of the articles that flood our papers).

But at the same time, IT companies in Australia will hire only 1 in a 100 applicants!

If you have a shortage of skilled people, then you don't turn your nose up at applicants at this rate. Sorry. You are obviously spoiled for choice and being super, super selective in who you hire. So much so that you are wasting more time in filtering and selecting people than you should be.

This, by the way, is in a country that has as almost standard, a probation period. If the employer doesn't like you in the first few months of your employ then you are toast. No recriminations, no blame. It would be surely be more cost effective to hire people and then shed them if they don't work out?

Do employers really want to open the gates to allow in people who they then aren't going to hire? It makes no sense to me.

I'm guessing that the real reason that we want the visa restrictions relaxed is to drop salaries, in some warped supply/demand way... If true, what does that tell us?

Footnote, 29^th August: Of the 1 in a 100 applicants hired, almost 50% aren't up to the job...

Another month, another speech..

Be Prepared

It has been a long day. The seats on the train are all taken. So you stand, hanging on to a strap as the train hustles you home.

A girl near the end of the carriage unexpectedly jumps up, sobbing, and steps through the inter-leading door between the carriages.

You see her framed by the door window, standing on the exposed, shaking, platform that bridges the two carriages.

Suddenly she picks her leg up, swings herself up and over the guard rails, and falls from sight.

You, and the the people in the carriage that saw this are shocked. What has just happened? Did she really just jump – why was there no sound – are trains really that brutally massive?

All these thoughts race through your mind. But before you can work out what to do you see her head bobbing at the bottom of one of the inter-leading carriage windows.

Relief fills you, and everyone else who saw her vanish. She's alright: she's clinging to the carriage! But she is in a very dangerous spot.

You realise to your horror that all the other people on your carriage who saw this drama play out are now starting to look at their newspapers, to look out the side windows – doing anything they can to exit the stage on which they unintentionally find themselves.

What would you do if that were you in the carriage?

I believe that we must consciously choose to act in the day to day drama's that intersect our lives.

I also know that we choose how we are to act in the drama. Our chosen role can range from deliberate inaction to full participation.

On that train rattling through the night, with the girl clinging to its side, I felt powerless.

She was behaving irrationally: if I went near her what might the result might be? Would she jump – or would she pull me out into the void to be with her?

I couldn't leave her, and I feared getting too close to her? What could I do?

There was another path I could follow. I could contact the driver. Every door on the train has an emergency intercom that allows you to talk directly to the driver.

But the more people there are around an unfolding drama, the harder it is for us to take an action that is different from theirs.

We look to the others around us for leadership – and when none comes we use their lack of action to abrogate our responsibilities.

I ran from door to door on that carriage, desperately looking for an intercom. And found none!

The people on the train were now starting to look at me – I was becoming the focus of their attention – not the girl desperately clinging to the side of the train.

It was just surreally wrong - if that had been your daughter, wife, or best friend of clinging to the side of the train, would you have ignored her to instead watch the strange man who was now running from door to door? I think not.

Yet on that carriage everyone did nothing, complicit in a unison of inaction. And now by focusing on me, made me feel as though I was the one who was strange and different – and that I was in the wrong.

Just then the train slowed and stopped at a station. I escaped their attention by leaping out the train.

I ran up the platform, to the drivers window, knocked on it, and told him of the girl.

Baden Powell, founder of the scout movement, said: “Be prepared”.

By that he meant that you must prepare yourself "by previously thinking out and practicing how to act on any accident or emergency so that you are never taken by surprise".

Later, when I got back on my carriage, after the driver had navigated the girl to the safety of the station platform, I saw that there were indeed intercoms on the carriage: others, standing, had simply been leaning against them, hiding them with their bodies.

Now when I get onto a train I check for the intercoms, making sure I know exactly where to go if something happens.

That preparation has already paid off: just last week another girl collapsed on the train. Whilst an elderly women aided her, I, nervously, because no one else was doing anything, called the driver.

No less than 8 officials met us at Flinders Station and and tended to the girl.

That brave elderly women and I were not punished for stalling that train in rush hour – none of the officials even bothered with the two of us once they were attending to the girl.

We just slipped away with the crowd when we saw the girl responding to their ministrations.

Ratko Mladic has just been extradited to the Hague, to stand trial for the Srebrenica massacre.

A massacre in which over 8000 men died. It is the largest mass murder in Europe since the end of the world war two.

What could tie the terrible deeds of Ratko Mladic to us, who were in that carriage with a girl clinging to its side?

400 heavily armed and highly trained Dutch soldiers were stationed in Srebrenica when the massacre took place. Unbelievably, they turned their backs.

The two events are related by the people who stood by and did nothing.

Evil blossoms when watered by the apathy of those around it.

If we can learn act in the day to day drama's that intersect our lives, we will be more able to act when evil starts to take root.

So be prepared – roll play scenarios in your head, learn from how others have behaved in emergencies.

And remember to choose your role – and act, when you find yourself inadvertently thrust into a drama.

JavaScript, Functional Programming & UML?

I come from a Java background. As I have been learning JavaScript through my naked server experiment I find myself wondering more and more if "traditional" Object Orientation is the right approach to JavaScript. I now agree: JavaScript is the most widely deployed functional language.

When doing Java development we often share our thoughts via simple UML diagrams. They offer a nice visual way to share concepts and discuss ideas. They allow us to abstract the underlying complexity of implementation away. In short, to a Java developer, UML can be jolly useful.

But now I find myself wondering how I can use UML to describe any functional JavaScript that I might write. As a set of utility classes, perhaps? Regardless, it would seem that I am not alone.

In fact the kingdom of nouns extends far further than the shores of Java. It would seem that at some stage the software industry did truly believe the religious  decree that procedural programming was bad...

Mac sales: my curious lack of surprise

I've just seen that at this moment in time Macs are doing rather well: roaring ahead whilst PC sales are declining.

I normally build my own PC's, but recently decided that I want to change this pattern and actually buy one off the shelf.

My principle stumbling block is that I don't see why PC's have to come in big boxes: the last one I built runs dual monitors and fits in a shoe box.

However trying to buy a powerful compact PC seems to be inordinately difficult: the best that I have been able to come up with is either another Shuttle, pre-assembled, or the NRG Frost. Which now sadly seems to have been discontinued. Not helping in my quest is that I want to run some variant of Unix/Linux (Ubuntu preferably) on it, not Windows.

In short, here in Melbourne, Australia, I haven't found anything. Other than perhaps a new iMac. It's compact (beautiful), runs a Unix flavor, and comes with a "free" monitor: all for $1949, about the same as I was quoted for a headless NRG Frost.

The PC world seems to think that bigger = better, and that we all want to run Windows. With this broad stereotyping in play my next PC is most likely to be a Mac. So reports of Apples success don't surprise me in the slightest.

JavaScript notes: AJAX and redirects

More fun and games in my ongoing exploration of the world of JavaScript.

At the moment I am playing with AJAX, and found myself wondering how one would deal with calls from clients whose users were not logged in.

After a bit of experimenting I have found that if you do a plain redirect from the server, the browser happily follows it, but stuffs the result into the response passed to your beautiful AJAX code. So the user is left on the page that ran your AJAX, blissfully unaware of what is going on under the hood. This seems fair: the browser is leaving the decision making up to your AJAX code.

The problem being that if you write a nice filter to redirect all attempts to access protected content to a log in page, and your AJAX code is expecting a nice piece of JSON, there will be tears.

For my naked servlet experiment I have been forced to a slightly hacky solution: I have a created a servlet filter for JSON requests. If it finds that you are not logged in then it wraps the URL of the log in page in a piece of JSON and returns that. If the AJAX handler in the browser finds the redirectTo key in the returned object it promptly redirects the browser to the associated URL and does nothing more.

It would have been nice to handle the whole thing by popping up a log in dialogue (via an iFrame?) and not redirect the user to another page: but I am using Google App Engine as my servlet provider, and it would seem that the terms of service require me not to do this.

This doesn't seem very elegant. I am scratching my head to see if I can come up with a better way, but for the life of me, I can't see it. All hints and tips gratefully accepted!

How to learn a speech?

As a new Toastmaster member I have been troubled by the question of how to learn a speech. All of the other members I have seen talk seem blessed with wonderful memories, able to deliver impressive speeches flawlessly, without recourse to notes, powerpoint bullets, or any other apparent memory aid. 

I last gave memorised speeches at school – and I don't remember being particularly good at them, so I was worried about how I would manage.

But then a slow logical optimism through induction bit. The key word in that last paragraph was “all”. If every speaker was able to memorise their speech so effectively, then surely I should be able to as well? All that I needed to know was their techniques. Simple!

So I asked several of the speakers how they managed to learn their speeches. Dishearteningly, each person I asked gave a slightly different reply. “Repetition”, though, seemed to feature in every reply. They had practised those speeches a lot before actually giving them.

Seeking greater enlightenment, I turned to the Internet. It would seem that people deploy a wide number of techniques to learn speeches. There do seem to be some tried and true methods that shine through, though.

Joshua Foer, in his book, Moonwalking with Einstein, The Art and Science of Remembering Everything, describes one process, called “elaborative encoding”. Using this technique you would convert the paragraphs of your speech into a set of bizarre and engrossing visual images. Then you would order the images in a route through a familiar place, such as your house.

The images and the journey are far easier for you to remember. To you, your speech has just become a journey through Lewis Carroll's looking glass, rather than a pile of hard to remember words. This technique has been tried and tested through time. The Romans knew it as “The Method of Loci”.

Researchers have known since the late 1800's that spaced repetition leads to memorisation. They have shown that when we first learn something it is placed in the brains short term memory store. With time it either forgotten or moved to the brains long term memory store. The key to moving the material to the long term memory store, and to retrieving it from the long term memory store is repetition. Exactly what shone through from my earlier queries!

Distressingly, the timing of the repetition is important. For best effect you have to repeat the learning just as you about to forget it! The time between each “about to forget” moment grows with repetition. This is termed the “spacing effect”. What makes this distressing is that we each appear to have our own optimal intervals of learning. So we have to somehow work out what our own optimal intervals of learning are!

Research also shows that cramming does appear to increase our understanding of a topic – but it really doesn't help us remember what we understood.

All this repetition seems like hard work. But then, know that the harder you work to remember something, the more it will be sealed in your memory. Also note that you can't take current performance as an indicator of your future performance – you might have left that future repetition too late!

One suggestion for easing the hard work is to record back to back copies of your speech. Then simply play them as you fall asleep. On awaking replay the recordings of the speech. And there, voilà! The speech, she is memorised.

For my icebreaker speech I used simple repetition to learn the speech. It worked well for me. In hindsight I need to work on determining my optimal spacing. For my next speech I am going start with the method of loci, and then switch to hard repetition. I might even try using headphones!

My unexpected takeaway from researching how to memorise a speech is that if we manage to become an expert at something, it's not because we remember our lessons or readings on the subject: it's because intense practice in that something keeps our memories fresh.

My sunny optimism...

A speech I recently gave:

I can do anything.

I honestly believe that with a little education, a little time and quite some practice, I can do just about anything a human is capable of.

I am no super man. This is simply an attitude. An attitude that I have eventually realised to be both a blessing and a curse.

A blessing because I have never had to rely on anyone one else when I need to get something done. I research, learn and just do it.

A curse, because I have never had to rely on anyone else when I need to get things done. So I have never had to learn the skill of motivating others – of getting them to help me achieve my goals.

I also have a deep desire to question and understand anything I use and play with.

For example, I can't just get into a car and drive it. I have to know that the wheels are connected to a drive shaft, that that's connected to a gear box, connected to a crank, moved by pistons. Powered by small explosions, created by a spark applied to a petrol and air mix, adjusted by pressure applied to the accelerator.

This need to question and understand is also both a blessing and a curse.

A blessing because if anything goes wrong with the things I use and play with I can fix them.

A curse, because I find it hard to let others fix my broken toys.
“You want to charge how much to repair this? Never mind, I'll do it myself!”

I also spend an inordinate amount of time trying to understand how things work.

These are my dominant characteristics. Oh – I also talk to myself more than I should.

How did I grow to be this person?

I believe that, like an insect trapped in slowly hardening resin, we are largely defined by the family and culture that we grew up in.

Let me describe my formative years and you can get a better understanding of the forces that have shaped me.

I was born in colonial Africa. My father, a structural engineer, was building bridges for the empire!

When I was very young, worried about the changing world around him, my father moved the family to the apparent security of South Africa. In hindsight, I wish he had just kept right on moving!

As I grew my father used me as his cheap labour. Under his direction, I restored cupboards, built sheds. I mixed cement, I laid bricks. I painted, I cleared drains. When I was a teenager I helped to renovate the family home, from the bottom of the foundations to the top of the roof.

My father was a practising Hindu, my mother, a Scottish Presbyterian. They elected to bring me up as a Roman Catholic in a country ruled by Dutch Calvinists.

Once week my father would gather the family in the lounge, and we would discuss religion and philosophy. From this religious cacophony I learned that there was no one truth. That we should question everything. That nothing is as it might seem.

My mother made sure that I had a constant supply of wonderful magazines. "Eagle" - who could forget Dan Dare? “The World of Wonder” “Tell Me Why”, “Look and Learn”, “Speed and Power” - They served as an antidote to the philosophy, bringing certainty to my world, explaining, sometimes in great detail, how things were made, and how they worked. I read my way through all of them, greedily.

It was only natural that at University I received a degree in Physics and Computer Science. In physics we continually strive to understand by building models of the universe, and then try to destroy the models, to prove them wrong. I loved Physics, but wasn't very good at it, so I became a software developer on graduating.

The apartheid regime that I grew up under forced compulsory national service on all young “white” men and so I served two years in the army.
When I idly mentioned this to someone in New Zealand they looked at me, gasped and backed away with "You're a trained killing machine!”

“NO!”I started to tell him. “ That's not me...” when I realised that I may just have missed the point of national service.

During that national service I spent a year patrolling the Namibian bush, keeping it safe. During the day I walked. At night I slept under the stars. With no mattress. No laundry. Carrying all I needed on my back. Occasionally meeting at pre-arraigned points to pick up food and ammunition.

That's were I first started to talk to myself. To give myself company out in that vast, lonely, veldt.

So like this insect trapped, my formative resin has now turned to amber.

I have to question and understand the tools and toys that I use.

With that understanding, given enough time and practice, I believe that I can do almost anything a human is capable of.

And I know that this, my sunny optimism, is both a blessing and a curse.

Scenario Planning and me. A short personal history.

I have been fascinated by scenario planning for quite a few years – actually for most of my adult life. This is because I grew up in apartheid South Africa: and so was briefly exposed to the power of scenario planning. As were most South Africans of my age.

A bit of history might be in order: trying to peer into the future has always been a human fascination. Way back when we used extispicy. We also tried using the position of the stars at birth, the length of creases in a hand, and more recently, how tea leaves fall in the bottom of a tea cup. The list of things humans have done to divine the future is very, very, long.

In the 50's various people tried to put the art of forecasting the future onto a more scientific footing. In the 70's Shell managed to profit handsomely in the oil crunch – and ascribed their success to their scenario planning, built on these initial attempts to forecast the future.

Other companies were dazzled by this, and soon a lot of them were running their own scenario planning groups. Anglo American Corporation, a huge South African mining conglomerate, bought into the whole process in a major way.

Amongst the many scenario's they produced, was a set that predicted two possible futures for South Africa: a “high road” resulting in peace, prosperity and stability, or a “low road”, where the country descended slowly into a spiral of ever increasing conflict and brutality.

So alarmed were they by the prospect of the “low road” that they created a travelling road show, that went from town to town, fronted by the head of their scenario planning division, a Mr. Clem Sunter. Those who attended were given an overview of scenario planning, it's many successes till that point in time, and then walked through each of the two possible futures for South Africa. In excruciating detail.

The torch of newsprint was shone on the road show. It was newsworthy, after all. Editors editorialised, columnists columnised, and opinion pieces were opined. Letters were written, politicians gave speeches. For quite a few months fierce debate raged.

I lived in a small town, and so by the time the road show hit our city the controversy was at its height. The town hall was packed. Mr Sunter didn't disappoint: the show was put together very well, and by the time he was finished I think that most of of the audience felt that the “low road” was a very bad future to look forward to.

As did the apartheid regime – they asked for a private viewing and asked many questions. A few months later they started to unwind the whole apartheid edifice.

Where the two related? I can't say. But from my point of view it would seem that scenario planning had certainly played a key role in shaping the future of South Africa.

So it came as quite some surprise to me when I left South Africa that no one else in the world seemed to know very much about the power of scenario planning. Actually, most people knew nothing of scenario planning!

Every now and then I would turn to the web to see if I could find out more. But what I got was a confusing mass of information that obscured rather than revealed. Being a very busy software developer with a family I never had the time to pull at the end of the information and to find out any more about scenario planning, fascinated though I was.

Till now. I have got my hands on a copy of “Games Foxes Play: Planning for Extraordinary Times” by Chantell Ilbury and one Clem Sunter. A book that claims to transform scenario planning from “an esoteric discipline” to a “practical model” that allows “intense strategic conversation”.

It's been a fun read. I think I'd like to try to work through a very high level scenario planning exercise to get a feel for it. Now I just have to find my conversational partners...

CSS heuristics

As a developer I believe that styling web sites should be done by practiced design guru's. But that us developers should have at the very least a basic understanding of what those design guru's are up to.

Thus I have spent this last week wading through (and playing with) simple CSS experiments. It seems to my uninitiated eyes that the world of CSS is one of craftsmanship - knowledge gathered by bitter experience when bumping into the foibles of the various browsers.

So at the end of the week I have put what I have learned together and come up with the following list of heuristics for me to reach for and to try and follow whenever I have to touch CSS in future. Of course the trick is to keep this initial list up to date as I learn more...

CSS

• Use external style sheets
• Use a reset style sheet
• Combine elements (don't repeat yourself, if at all possible)
• Group your rules by location, ordering your style sheet from generic to specific. E.g.: Put generic classes first, then header, then navigation, etc...
• Try to use composite (shorthand) properties and values where possible.
• Alphabetise properties for easier reading.
• Consider putting the colour scheme used, a version number and your name in a comment at the top of the style sheet.
• Avoid browser specific hacks if at all possible. And if you have them in your CSS files, comment them so people understand why they are there!
• Avoid unneeded selectors – but do consider sand boxing the affect of a selector by making sure it is bounded (i.e.: make sure that the application of a selector is restricted to only a specific area)
• Specify units for non-zero values – don't specify units for zero values
• Minimise the use of HTML element id's
• Refactor often, removing unused rules and properties, and fusing rules where possible
• Try to follow object oriented CSS principles (separate structure and skin, separate container and content).
• For complex CSS consider using XCSS or Sass
• Have (and follow) a naming and coding convention which avoids underscores (for reasons of browser incompatibility). For an example of one see: http://na.isobar.com/standards/#_css
• Keep CSS files under version control (a no brainer for a software developer)
• Consider sizing your text in ems and using Javascript to find the correct starting pixel size. Then your base text should be 1.0 em ( * { font-size: 1.0em })
• Validate your and prettify your CSS.
• Consider using CSS sprites
• Code link pseudo-classes in this order: Link, Visited, Focus, Hover, Active (Leave Visitors Focused on Hoovering Activities)
• During development use separate style sheets with lots of comments. For production, compress, minify and consolidate into one file!
• Avoid using important! (treat its use as in indicator of something being wrong in your styling)
• If designing for both mobile and large screen, consider starting with the mobile design. That way you will be aware of the assets the mobile shouldn't have to load.
• Know that CSS3 "pays off when it comes to production, maintenance and load times"

HTML

• If possible, give every page's body a unique descriptive class: this makes it easy to add page specific styling
• Try not to make class names represent design i.e.: prefer “comment” over “right” - otherwise you are baking design decisions into the HTML
• Try to avoid div and span soup in favour of meaningful HTML elements
• Avoid style attributes in HTML tags
• Use HTML 5's doctype: as it switches all modern browsers into standards mode – even if you aren't using HTML 5
• Validate your HTML!

The naked server

Twitter have abandoned Rails for some parts of their application. I didn't find their description of the move to be fully informative.  E.g.: just what do they mean when they say "we launched a replacement for our Ruby-on-Rails front-end"? Predictably the move got a few comments on the Ruby/Rails newsgroup that I subscribe to. The general consensus seemed to be "so what"? I think we might all be missing the bigger picture. Perhaps this is just a logical step in the progression of web applications? If so, what does it mean for their future? To explain my thoughts, some history:

• Way back when, pages viewed in a browser were fairly simple, being mostly static files that were dished up from directories by a dedicated server application.
• Then we needed to make those static pages more dynamic, and to reflect knowledge related to the identity of the person who was viewing those pages. However, browsers were geared to rendering static pages, so we controlled what we could and put the smarts on the server, building frameworks that allowed us to customize each individual page for the viewer. Our first efforts at these frameworks were quite awful, IMHO, but as time went by we got better at it.
• Now web browsers have an common embedded scripting language (ECMAScript): and can create and change whole pages, dynamically, on the fly.

See the flow here? The complexity started on the server, and then tunneled down those tubes to the browser. Currently it is spread across the browser and the server, with JavaScript frameworks, and server side frameworks being combined to produce an application. Do we still need those server side frameworks to compose and build web pages? Surely we can now start to strip the server side of the equation back? In this vision of the future we would create the bones of the site using HTML and CSS, mix in JavaScript, and serve these as static files to the browser, that then makes the magic happen. The browser fetches any data required from the server in an easy to digest format, such as JSON.  The server loses the complexity that it gained to build dynamic web pages. I'm going to call this vision of the future the naked server.  If correct, I predict two things:

• JavaScript/HTML/CSS is going to grow dramatically in importance (and that seems to be happening).
• node.js is going to become popular. Because if you know JavaScript, and you simply want to fetch some data from the server, or write some back, why not use the same language and, possibly, files, on both sides of the tubes?

Over the next few weeks I am going to see if I can write a simple naked server application. Not being a JavaScript guru yet, I think I might stick to my knitting, and use naked servlets for the server side of the equation. Then I plan to add to my knowledge and to build a node.js cloud based application. This should be fun!

Software craftmanship

Gojko Adzic has taken the bother to go through the Hudson/Jenkins code base and critique it. He doesn't find the code to be pretty, and wonders what impact this might have on software craftsmanship.

I found the comments quite good. I wrote my own lengthy response, which I am going now going to quote, as I want to add a footnote.

"Any long lived piece of code is going to have many people working on it, each with their own unique style and understanding of the code base. 

Every piece of functionality added is going to have it’s own motivating circumstance, so, for example, there might be time or financial limitations driving it that we, the code readers, are not aware of.

It is almost always easy to criticize others code, but without insight as to how that code was created and added to, the criticism is, to me, shallow. It perhaps gives us insight into the critics preferred coding style, and also maybe teaches us a little.

But beyond that, Hudson/Jenkins code works. The Hudson/Jenkins is released often. The Hudson/Jenkins is very popular. I think that is the true test of software. Regardless of our personal feelings on reading the code. 

You ask where does this code leave software craftsmanship? Hudson/Jenkins is the rock on which many continuous integration projects are based, so I guess it seems to show that software craftsmanship is really not as important as releasing early, releasing often, and getting immediate feedback from a wide community of users. That seems to trump code ‘quality’.

But you know what? It does look as though they could do with a little help cleaning that code base up. We should start by contributing some tests…"

The footnote:

I'm with Dan North. "No-one wants your steenking software – they want the capabilities it gives them."

The only craftsmanship the user of an application will experience is via their interface to the software. It is one of the oddities of the software world that we can write a perfectly literate, indeed beautiful, program that is totally unusable.  And as Hudson/Jenkins seems to show, we can write an abomination that is extremely popular, well liked, and very, very important.

At this moment I believe that the software craftsmanship manifesto is by developers, for developers. If it were any other way it would have usability and interaction at its heart, not code.

What software craftsmanship seems to offer is code that more reliable, cheaper to build, and if it passes the first hurdle of customer acceptance, easier to maintain. That's not bad: but I find myself wondering how many of its practices are well founded.

Take the 100 line constructor that Gojko complains about: in Code Complete, Steve McConnel writes "Decades of evidence say that routines of such length (>100 lines) are no more error prone than shorter routines. Let issues such as the routine's cohesion, number of decision points, number of comments needed to explain the routine, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se. That said, if you want to write routines longer than about 200 lines, be careful."

Surely we should forgo our beliefs in favor of research results?

During my career as a software developer I have seen fads come and go. Many seemed to have very little scientific underpinnings, being based more on belief than on reality. I worry that, seductive and appealing though it sounds, software craftsmanship might be in the same boat.

JavaScript notes: an Applet puzzle

This one has driven me a little crazy over the last few hours.

As part of my learning about JavaScript and HTML5 I thought I would try embedding an applet in an HTML5 page. Which I could easily do. Then I made the applet record a sound and then replay it. To do this the applet needs to be signed. So no problem, I used a self signed certificate, loaded my applet and everything just worked. Sweet.

The next thing I then tried to do was to get the JavaScript on the web page to call into the applet.

<form>
 <input type="button" value="record" onClick="document.getElementById('recorderApplet').doRecord();">
</form>

Hacky - In my defense, I was just trying to see if I could get the call to work...

When I pressed the HTML button in my browser:
POW!: java.security.AccessControlException: access denied (javax.sound.sampled.AudioPermission record)

This was a little unexpected - if the applet button was pressed, I recorded. If the HTML button was pressed, then I got a security error.

I Googled the world and found Bug 4406607 and Mozilla bug 60120
But somehow the answers within didn't seem satisfactory.
Then my searches hit gold: Java Access Control Mechanisms (pdf)

A very nice explanation of what was happening, with a simple answer: change my Java method that was being called by the JavaScript to the following:

public String doRecord() {
        return AccessController.doPrivileged(new PrivilegedAction<String>() {
            public String run() {
                replayRecorder.startRecording();
                return "recording started";
            }
        });
    }

Now my applet records when I hit the HTML button. Sweet.

JavaScript notes: a Firebug puzzle

There it stood, written before me on the page "Globals created with var (those created in the program outside of any function) cannot be deleted."¹

Yet in Firebug

var a = 10;
delete a;
console.log("this is a: " + a);

consistently returned:

ReferenceError: a is not defined (Fool!)²

How could this be happening? 

If I reworked the code and ran it as a script in a web page, it gave me "this is a: 10", as expected.

After a bit of research (thank you, Google),  I found the answer. Ironically in a blog entry about another book by the same author that was puzzling me now...

The solution is well worth reading, but I'll see if I can summarize it:

• Variables are in fact properties with a "don't delete" flag set.
• Variables declared in JavaScript code that would otherwise be global, when executed by an eval call are in fact deletable (the flag isn't set)!
• Those deletable variables are added to the calling object's variable object, for want of a better place to put them.

Firebug appears to be executing code entered into the console via an eval call, hence my strange power to be able to delete global variables. No black magic here!

 Of course this answer poses another question: why are global variables that are in code executed in an eval context deletable?

I think that the following code might propose an answer:

(function test() {
   eval('var wtf = "wtf";');
   console.log(wtf);
   console.log(delete wtf);    // true
})();

When you evaluate code you will possibly have variables added to your calling context that you might not want there. By marking them as deletable, you have a chance to clean them up. Now to work out how you can do this automatically...

Footnotes
1 Page 12, JavaScript Patterns by Stoyan Stefanov, September 2010: First Edition.
2 Fool! wasn't really part of the message: that is just how I felt when I saw the error.

What am I doing?

Good question! This entry is not going to be the answer to a deeply philosophical question. It's just a simple description of what's happening my life at the moment.

My current journey was started last year when my wife, Terry, saw an interesting advertisement in her physiotherapy journal. Due to very sad personal circumstances someone was being forced to sell a web site that they owned. We made enquiries and found that not only was the asking price too much for Terry and I to pay, it also seemed, for various reasons, that the data that underpinned the site was not as complete as we would have liked.

As Terry and I explored the opportunity, we talked about what we thought would make a profitable web site. In the midst of our conversations, Terry came up with a what seemed to be a great idea for a web site.

As the year ran out we found that we spent more and more of our time talking about her idea – and so started doing some basic research into the idea. The more research we did, the sounder the idea looked.

So at the end of the year I resigned and came home to work for my wife. On a very unsalaried basis, I must admit. Terry and I calculated that we had enough savings in reserve to keep me at home for just under a year, all going well.

Shortly before I finished up with my work Terry had received some quotes from landscapers to do some cleaning up and rearranging of the garden. The quotes ranged from between 30 to 70 thousand dollars!

We were so confident of Terry's site idea that we decided the first few weeks of my new work would be dedicated to cleaning up the garden.

So first came down the horrible old grey shed in the back garden.

Our grey monster!

There were several trips to the tip!

Was made of more 'stuff' than we thought...

Then in went some retaining walls and a lot of back fill. 

Any wonder I am loosing weight?

Then the builders came and put a new pair of windows into our house.

Our work is just about to start.

We lined and painted the room ourselves. 

Need some lining done?

To me the painting was truly horrible work. It just seemed to mindlessly go on and on without end. I have decided that painting is a special form of torture. But after what seemed like ages the room was finished.

At last!

We were now into the start of March. And although we were far from achieving all we aimed to do in the garden, I really wanted to return to programming. 

Yes. Typical software developer. Underestimated the time it would take.

So we agreed that we would work in the garden and on the house over weekends, as most people do, and I would start to construct Terry's site.

I created some rough paper prototypes, discussed them with my client (Terry), and then based on our discussions built some quick and dirty html mock-ups. We took the mock-ups, played with them, discarded one approach and then settled on a path forward.

I am now working on the technology stack to be used whilst Terry works on creating and building the content.

In creating the content, it would appear that Terry has found the first major wrinkle in our plans. That is that under Australian legislation it would appear we might well have to register the site as a medical device! If true this will throw a whole heap of unexpected expense and overhead our way, which may well render the original idea unviable.

It might well be time for our first course correction!

One that will possibly affect the technology stack I had chosen.

As it looked as though we were going to be creating a web application, I had settled on JavaScript/jQuery and HTML 5 (that degrades gracefully) on the client and Rails as the quick (and dirty) back end. Now if we are going to deliver a site full of content I think we might better be served with Drupal on the server.

As Terry is producing the content, and as we are trying to work out how best to navigate Australian legislation, I am bringing myself up to speed on JavaScript, jQuery and HTML 5. For sadly, as a regular employee working in the Java environment, I had never had the time to truly master JavaScript. I can now see that there is a huge amount that I had missed in the osmotic learning of a salaried environment!

Paulo's Postulate

What happens when computers stop shrinking? - Salon.com

 

Who cares? At this rate by 2020 the IP lawyers will have strangled the whole software scene. Any slow down on the hardware will struggle to match the slow down that the patent lawyers and music/movie industries will have brought to the table :-(

Our Xmas holiday...

Terry and I have just returned from a step back in time – we went to the golden beaches, idyllic lakes and extensive wild forests of our youth. We spent our holiday in a place named Wallaga Lake. A lagoon on the southern New South Wales coast.

Trying to see the most of this large country, we chose to travel inland on the way there, and to return along the coast.
The first leg of our journey was on the inland freeway connecting Melbourne to Sydney. One freeway is pretty similar to another – long, straitish and grey. Kylara started to get a little bored, and used her phone to send a message to her Facebook friends.
Kylara Paulo: I swear we already drove past here..
The striking part of this leg was journeying through the remnants of the Black Saturday fires. Like a charcoal scar, they slashed a broad black path across the freeway. There are splashes of green in the blackness as new plants take root and grow, but to still be this damaged two years on from the event shows just what an inferno the fires must have been.
As we drove we wondered why so many cars seemed to have gauze stretched tight over their front bonnets. Could it be an Australian fashion for cars? A legal requirement? Was there something that we were missing? The answer was revealed as we started to travel through locust clouds wheeling across the freeway. As we started to travel through more and more such clouds we started to wish for our own piece of gauze across our radiator.
Kylara Paulo: There are quite a lot of locusts.
We stopped at Wangaratta to experience one such cloud close up. The locusts were a lot smaller than the ones that Terry and I remember from our childhood in South Africa. Perhaps they are still in their juvenile state?
We turned off at Wodonga, drove along the edge of Lake Tallangatta, admiring its potential for water play, and then through to our overnight destination, Corryong.
I must point out at this juncture that I have a problem with Australian names. Where I grew up places had sensible names – for example, Grahamstown, Port Alfred and East London. We occasionally wondered where West London might be, or if there should be an apostrophe in Graham'stown, but the names were easy to remember. If anyone asks me where we went on our great Australian holiday, the first place I have to head to is a map book to try and find the names of the places we travelled through and to.
We found that Corryong had dealt with the great post Christmas sale problem by simply closing down. We walked up and down the main street looking for somewhere to eat, but found that only the pub was open. We retired to our motel unit and attacked our camping food. Unable to sleep I crept out of the unit and was absolutely struck by the beauty of the star filled sky above. The stars swept in dizzying arcs, showing me what must have surely inspired Van Gough in some of his paintings. We ordinarily totally lose this view in the light polluted city nights.
Our chosen inland route led through the Australian "Alps", the highest mountains in Australia. At their highest point, Mt. Kosciuszko, they reach just over 2200 m. Yep, just over twice the height of Table Mountain, or just a few hundred metres higher than Johannesburg.
In the New Zealand terms that we are used to, we have mentally classified the Australian Alps as somewhat larger than average set of hills. Mt. Kosciuszko was named by a Polish explorer, who thought that its resemblance to the Kosciuszko Mound in Krakow was quite striking.
Corryong was in the foothills of the alps, and Terry, fearing car sickness, elected to drive when we set out. We meandered up past the great Snowy river power generating scheme, past the winter skiing wonderland of Thredbo, now exposed in its summer greenery. We detoured in to see what skiing Australian style might be like when it was covered with snow.
Kylara Paulo: Lost in thredbo...
After making our way through the alps we had lunch at Jindabyne, and then travelled through the rolling foothills towards the coast.
Kylara Paulo: We're so far into the middle of nowhere that even the sheep look surprised to see us. And mum is hitting all the potholes. On purpose.
And finally we arrived at Wallaga Lake. We were staying in a good old fashioned caravan camp on the shores of the lake. It was absolutely packed, so densely so that from some vantages it looked a little like a refugee camp. As it was getting dark we rushed to pitch our tent amongst our fellow refugees.
We had chosen to go to Wallaga Lake because friend from Melbourne, Anne and Andy, had invited us to join them and some of their other friends. Andy helped us pitch the tent and then introduced to the rest of the crew around a late night camp fire on the shores of the lake.
From then on it was simple fun in the sun. Andy owns a motor boat, and so took everyone out for regular tube rides, skiing and other aquatic games.
Another member of the party had a Hobiecat Mirage tandem trimaran. This is a rather bizarre cross between a trimaran and a canoe, with peddles that paddle thrown in to the mix. It is probably not the world's greatest canoe, nor the worlds greatest sailing boat, but it is a huge amount of fun!
Kylara Paulo: I quite like it here.
Imagining that children growing up in the vicinity of the lake probably lead a very "Swallows and Amazon's" type of childhood, whilst on the water I kept an eye open for a house boat and Jolly Rogers flying, but sadly didn't see any. I blame the Internet.
When we weren't in the water we were out exploring the area. Bermagui was a small fishing town on the coast, famous (apparently) for having been used as the location for the film "The Man Who Sued God". It had a beautiful beach and a fantastic sea pool.
Kylara Paulo: hates sunburn.
Near the camp site was Camel Rock, and a rather beautiful stretch of sandy beach. We spent a morning here body surfing and exploring the rock pools. Whilst in the water with Tessa and Kylara a pod of dolphins swam within metres of us. Not having my glasses on meant I missed the excitement – distant grey blobs in the water just aren't that fun if you know that they aren't going to eat you!
Every night we all gathered around the a camp fire. On new years eve we were joined by Mike and Maria, friends from New Zealand. Their daughter Genevieve is still one of Tessa's closest friends.
In honour of new years eve, the camp owners threw a free sausage sizzle. Our group determined that we should have a themed 60's party. I threw an old yellow kikoy around myself and got Terry to dab a dot of red lipstick to my forehead and went as an Indian mystic. I am afraid that I probably broke a lot of taboos! Better prepared than I, Terry dressed in a old caftan made from flour bags.
The camp owners had invited some musicians, a mother and son, to perform live music at the sausage sizzle. I turned my back and when I looked again found that they had been joined by a backing duo: Tessa and Terry, singing delightful accompaniment.
Kylara Paulo: Harry new year! I'm a bit early.
At 10 pm we did the mandatory count down and greeted the new year with whoops and hollers. We are, after all, New Zealanders. And this was the time when our countrymen would be celebrating. The rest of the people in the camp looked at us oddly. At midnight we got to celebrate again!
Kylara Paulo: I haven't showered since last year! :)
It all came to an end far to quickly. We packed and returned to Melbourne. As we drove down the coastal route we found that we really were in a land that reminded us very much of the Sedgefield region of South Africa. Lots lakes, lagoons and waterways. State forests, and miles of golden beaches.
We decided detour down a side road to explore the irresistibly named Wonboyn. Only 11 km's off of the main road, it seemed like a good idea at the time. We found ourselves meandering along a road in a state park that only four wheel drive vehicles could love. I was extremely happy, as it meant that we finally had a good excuse to switch to four wheel drive mode on our car. Again, with Terry at the wheel (I really don't know why my driving makes her throw up), we drove through the Ben Boyd national park. It appeared really remote and lonely - I was starting to wonder what would happen if we were to break down - when suddenly we emerged at a beach front car park absolutely packed with four wheel drive vehicles!
Kylara Paulo: back in vic :-(
Terry and I had a wonderful time on our holiday, made better because we were able to share it with Tessa and Kylara. Now the stories that Terry and I sometimes tell of our childhood holidays will have more meaning to them.
The holiday has lead to some soul searching. Until now both Terry and I have been working reasonably full time. Terry is a professional, and I a near professional, earning above the average salaries. Why have we only been able to take them on such a holiday now?
Is it because New Zealand and Australia are that different to the South Africa that we grew up in? Did apartheid truly give a sector of society such a huge advantage? I would argue not. Our friends who have grown up in Australia and New Zealand manage to take regular breaks with their families.
Is it because we return to South Africa every few years to visit our families? Again, I would argue not. Our friends who have grown up in Australia and New Zealand also manage to fit occasional trips to exotic overseas locations.
Could it be because the our parents were better off than we are? I am told that the per capita income of the average person on the planet has trebled since I was born, so I don't think this would be the reason.
At the moment we have it pinned down to two causes: Terry and I got started slightly later in this family and savings business, and we have persisted in moving to new countries just as we are starting to get a foothold.
Perhaps it is time for us to stop moving - to put down roots. And to go on holiday a little more!

Bunnings - a tiny problem?

On Thursday evening, steam pouring out of my ears, I sent the following to Bunnings via their web site:

I have just returned from wasting an hour and a half of my life at the Northlands Bunning store: I wanted to buy the timber to build a retaining wall and have it delivered to my house.

The person manning the timber yard avoided me as though I had the plague. When I eventually managed to corner him and explain what I want he told me that I had to go to the special orders desk. Which I did. They told me that they had just closed and I had to go to the customer service desk. Which I did. They then paged "Knave", who duly arrived after a wait of about 10 minutes. He told me that the timber yard were giving me the run around and that I should go back to them. Which I did. Only to find that there was no one there. After wondering around for what seemed like an eternity, I saw the original person - and I managed to corner him. But he explained that he couldn't help me as he now had an urgent staff meeting to attend. And he left.

There was no one else in the timber yard so I went back to the area in which "Knave" worked, and told him that I was rather upset. He replied that there had been a lot of staff meetings this week, some with up to thirty people in them, and that as a result there was nothing he could do to further help me.

I replied that I wouldn't be buying my timber from Bunnings and left. As far as I am concerned Woolworths can't get into this market fast enough. We have been staunch Bunnings supporters, but will now start to look elsewhere first for our hardware needs.

On Friday I received a call from a manager at Bunnings Northland to apologize. Apparently, recognizing that they have a customer service problem, the staff meetings in fact had been training meetings - teaching the values of customer service!

We had fairly pleasant chat - I told him how wonderful Bunnings New Zealand operations had been when we lived in New Zealand, and how disappointed we had been by the service from the local Northland branch after we moved to Australia. This experience was just the latest in a long line of less than stellar ones. He was sympathetic and claimed that by the time they had finished the customer service training I would find Northland Bunnings a very different place.

But here's the odd thing: he never tried to find out what I was buying, and to close the sale in a way that made me feel good about the Bunnings story. For example, he could have offered to take the order via credit card payment on the phone and to have it delivered. But no, I just got a basic apology, an explanation, and some interesting chat. So I wasted a further ten minutes of my life talking about my experience with Bunnings, and yet still am no closer to buying the stuff that I need!

Will Bunnings will ever be able to ever improve their customer service if the management don't seem to know the basic goal of customer service? I have my doubts.

Apple, Java and me. Proprietary bites, again

As a software developer who currently makes a living from Java development, I follow Java related news quite keenly. The last few months have been quite interesting, in the old curse kind of way.

Apples decision to "deprecate" their Java implementation is the one news item that will have the most impact on my future directions. It is one of those defining decisions that will be looked back on as either another of Steve Job's great decisions, or the misstep that started a decline in Apple's fortunes.

Why a misstep? Well, I currently develop and learn my craft on a Mac. It appears that I will no longer be able to do that.

Just as it was coming up time for me to replace my primary development computer at home. I was going to buy one of those very nice shiny big iMac computers. But now I can't. Given that I want to run a Unix style development environment, I will probably build a machine from scratch and install Ubuntu. Most developers won't bother - they will simply buy a Windows machine. So in the short term Microsoft and Ubuntu win from this decision, Apple lose.

Companies and government departments that bet on the cross platform nature of Java for applications find themselves in an odd position. They are either going to have to abandon the Mac, or rewrite their cross platform software. This takes time and budget: so until decisions have been made and choices reached, the most likely result is a freeze in further Mac upgrades. So in the medium term, again, Apple lose.

And in the long term? Java applications will not be deployable onto the Mac. As the second largest PC platform out there, this effectively kills Java's cross platform promise. And removes Mac OSX as a deployment option for server side applications. So finally Java looses, and again, so does Apple.

I am not optimistic about other parties picking up the pieces and running with them successfully. I don't believe Apple will donate it's current code – it's just not in their DNA, as far as I can figure. I also don't see an economic imperative for anyone else to take over the work. So this leaves open source volunteers to pick up the slack – and after the Apache Harmony/TCK and Android debacles, why would anyone want to risk getting involved?

This is not like Apple's Flash decision: in that case they were keeping Flash off of new platforms. In this case, Java developers are being excluded from an existing platform going forward.

Some people have rationalizes this along the lines of, “well, Apple can use their Java maintainers more productively elsewhere”, but here's a thought: What percentage of Apples advertising revenue would their support of Java be? Because this support is effectively another form of advertising: one that brings developers such as myself to their platform. It's not exactly as though the Java platform is a rapidly changing one. Most of their development costs have already been spent.

Also note that it is a lot easier to get into iPad/iPhone development if you already own a Mac. Just as it is now going to be a lot easier for the Java developers who return to Windows to develop for Windows Mobile 7.

As most people seem to dislike developing multiple copies of the same application, what will they turn to in place of Java? On the presentation side there are several options: flash, Silverlight and HTML 5/ CSS. I would argue that only the latter is unencumbered by FUD. The browser is the new VM.

On the server, pure Python, Ruby and PHP developers will happily be able to continue developing on and deploying to Mac's. However we are moving to a polyglot programming model where people mix and match libraries and languages. Those who stick with the Mac will find that the large Java ecosystem closed to them.

So given the large size of the Java ecosystem and the performance benefits, I do feel that going forward Apple have just ceded the server market.

So if not on servers, and not being used by developers, Apple will become more and more a creator of devices to consume content. They will become the television manufacturer for the Internet generation.

Again, no matter how I look at it, the decision to deprecate Java has no upside for Apple.

And Java – well, it's the new Cobol. There's probably enough of it out there to keep me busy until I retire. So I'm not sweating yet. But I am going to sharpen my Css/Javascript/HTML skills to prepare for the coming of the new VM.

To finish, I find some deep ironies in this unexpected turn of events.

• The Visual Basic programming model (a scripting language manipulating objects created in another more able language) wins through.
• The Swing model (no native operating system widgets, rather a rendered canvas) thus trumps the Eclipse model of delegating to the underlying os.
• But Eclipse will be the one IDE that will possibly carry on working on Apple computers, thanks to SoyaLatte and Eclipse's decision not to use Swing.
• Those people who bet on Flash as a cross platform deployment model are laughing.
• Apples decision shows that those freedom loving open source advocates have a very good point. Had Apples JVM been an open source one, we would not be in the quandary we now find ourselves. Proprietary bites, again.

A Kinfull question

By now it is common knowledge that Microsoft have killed their Kin mobile phone. The information that emerged in dribs and drabs made fascinating reading. We learned of a company not only riven by internal rivalries, but also that doesn't seem to know how to develop software. Which is odd, as by most measures I reckon they are the most successful software company in the world to date.

I attended a recent Enterprise Java presentation on Android. A graph shown during the talk sheeted home to me just how much  Microsoft have been humbled in this space:

% Share of Mobile Web Traffic, 2007
Windows > 20%
Sidekick  +- 20%
Blackberry < 20 %
Playstation > 20%

% Share of Mobile Web Traffic, 2009
iPhone > 60%
Android > 10%

So the space of two years Microsoft has managed to take their share of mobile web traffic from 40% down to a scant blip on a graph.

Consider the following:
From 2007 till now, iOS has moved from version 1.0 to version 4
From 2009 till now, Android has moved from version 1.0 to version 2.2
Windows Mobile 6 was released in February, 2007. We are still waiting for the next version release.

It seems to me that the software development practice roundly ignored by Microsoft is that of performance, feedback, revision. I.e.: release regularly, measure the result, and then adapt the next release of the software accordingly. I am not surprised that some see the next release of Windows mobile as a slow train wreck unfolding. Short, sharp and focused cycles are important. Any agilista knows this. Why not Microsoft?

Apple's new iPhone terms...

As someone who has had to live with Adobe's poor support of OS2 way back when, and subsequently on Linux & Macs, I am somewhat sympathetic to the point of view that Adobe made a tactical error way back when.