Skip to content

Live Blogging at WDCNZ


Welcome to the Xero Live Blog for WDCNZ: tech talks for web devs! It’s all happening in Wellington today. This is the premier conference in New Zealand targeting solely the developers who deliver software on the World Wide Web. It’s in-depth and technical and full of tips and techniques from leading experts.

Four of us from the Xero dev team will keep you up with the action – that’s Tokes, Liam, Ronan and Matt! We Do Photography’s Jason Naylor will be supplying the pics.

Follow the conf also on Twitter with hashtag #WDCNZ – programme details on the WDCNZ website .

Click here for latest content.

9.05am – 10.40am with Tokes

OK – all set up ready to go. Room is filling up with web devs – my kind of crowd…

Going to be starting about 10 minutes late because of the crash on the motorway this morning – a tanker crashed into a vegetable truck and then they closed the rail line to avoid sparks!

Owen is hovering off-stage – things could be about to kick off…

All sessions are being recorded – videos will be put here along with last year’s ones too.

We’re off!

Owen takes stage – cheers go up for the second @wdcnz conference

Now up: Divya Manian, Adobe

Divya Manian

Divya takes the stage and will be talking about “Pushing the Cutting Edge Forward with Web Standards”

Brave, very brave – Divya shows screen shot of her first ever website.

Browsers hall of shame – Quirks mode!

Writing web specifications is a mission and includes representative from lots of interested parties – Oracle, Microsoft, Google… and also “Invited Experts” – if you thought it was hard to read them, try getting consensus when writing them (my thought, not Divya’s)

First Working Draft -> Candidate Recommendation -> Proposed Recommendation -> Recommendation !

Average time to approve a specification is 11.5 years – oh dear.

Rather than waiting for HTML specifications to become official you could check out and decide whether a feature is stable enough.

Don’t be afraid to tell specification groups about bugs or features you find hard/confusing/annoying to use – but back it up with specific issues. Don’t just say “this API sucks”.

Or even Join a community group, anyone can join

Thanks Divya – stretch your legs folks

Now up:  Malcolm Sheridan, Microsoft MVP ASP.NET/IIS, ASP insider and Telerik insider

Malcolm will be talking about “Less Coffeescript in”

Presentation started with Visual Studio open – nice

Malcolm’s intro – works for ANZ, started as a contractor then got taken over to the dark side of permanent employment with an offer he couldn’t refuse.


  • Telerik Ultimate collection ($US2000)
  • 2 x Mindscape Megapack Premium

Now you wish you’d come right?

{less} – a way of making CSS easier

Shout out to Mindscape’s Web Workbench product – check it out!

{less} lets you add comments to your styles…

{less} lets you add variables (warning, live coding to follow);

@bgcolor: "#ff0000"
    background-color: @bgcolor;


{less} has mixins;

    backgroud-color: @bgcolor;
    width: @width;

OK – not sure I can keep up with these code snippets!

Demo gods in the house but nice comeback "Let's just pretend that worked"

You can even turn this;

    text-decoration: none;
    color: Red;
    color: Black;


    text-decoration: name;
        color: Red;
        color: Red;


CoffeeScript time – makes writing readable Javascript a breeze.

“I’m almost embarrassed to talk about CoffeeScript with Douglas Crockford in the room” – haha!

Lots of cool code samples, plenty to make the life of a web developers easier.

My takeaways – less is more and coffee is always good.

Raffle time for the prizes – business cards go into a raffle!

OK – that’s all from me folks, I’ll leave you in the hands of one of our Xero developers, Liam. Take it away Liam…


11.10am – 12.50pm with Liam

Now up: Aaron Morton, Freelance developer
5-minute countdown. People attempting to reclaim seats and swig down coffee and muffins. (Muffins were delicious, for the record.)

And we’re away! Aaron will be talking about Apache Cassandra.

Cassandra started life at Facebook, and was sourced to Apache in 2010. Some of the current companies that use it are Netflix, Twitter, Reddit, and Rackspace.

Now having a quick look at Cassandra working at the cluster level. Cassandra uses consistent hashing to evenly map keys across the nodes, and also minimises key movements when nodes join or leave.

Some nice diagrams to explain the concepts. Looping circles of tokens and nodes.

Replication strategies:

  • SimpleStrategy with RF3 – clients connect to any node in the cluster, and that node is known as the coordinator.
  • Use of Quorum.
Moving on form the cluster to the data model…

Some code demonstration now for creating the model, with keyspaces and column families. Slides moving at quite a rapid pace, so unable to jot down some sample code just now, unfortunately.

Setting up a sample database around user tweets.

Now some example of how to access detailed information, such as last tweet or tweets today, but using simple commands against the columns.

Sample code (all I could jot down, he’s really moving so fast!):

    key_validation_class = 'CompositeType(UTF8Type, UTF8Type)'
    Comparator = 'CompositeType/IntegerType(reversed=true), UTF8Type)


Aaron Morton


For batch deleting tweets:

row_key = this_user
columns = [
batch.remove(user_tweets_cf, rowkey, columns=coulmns)

Wrapping up now, the Twitter clone up and working during the talk. A very intensive presentation, with a few people looking thoroughly overloaded!

All done, and time for another break before Lea Varou comes on.

Now up: Lea Varou, CSS guru

Lea began by introducing herself briefly, and has launched into talk about the 4th dimension.

Transitions and animations allow for the sense of time through CSS.

Abrupt transitions are bad UX. Using examples of the Mac genie effect to demonstrate the difference between abrupt transitions and nice smooth, transitions. “Transitions are not just fluff.” Talking about how these animations allow users to see where the window has gone: to the dock. It let’s less experienced users know something that might not be intuitive to them otherwise.

“Delays are even worse.” Power users might not necessarily want transitions and animations, especially if they get in the way. “Don’t piss of your users.” Advice not to overuse transitions just to show off the power of CSS.

Talking about including kilobytes of code just for the use of transitions. “How many of you have used JQuery just for the animations?” A sheepish show of hands…

Examples of how to use transitions in various ways to achieve different effects when hovering over a button. Background transitions, font colour transitions, immediate/abrupt transition on hover and one second transition fade when hover ends. Very aesthetically pleasing, but comes with a warning that while CSS is more efficient than Javascript, they can still be expensive.

Transitions are supported by Firefox 4+, Opera 10.5+, Chrome since version one (crowd laughs), and Safari 3+. Internet Explorer gets exposed as the problem. “It’s coming. They can’t keep it in beta forever.” Poor IE…

Animations are supported by Firefox 5+, Opera 12+ (“it used to be a problem”), Chrome since the start, and Safari… with IE once again getting singled out as not supporting them at all.

Examples of supplying two parameters for the transition property (eg, transition: 1s 1s), which means that the transition takes one second, and takes another second before it is fired off. Demonstrated by hovering over a div that only expands after it’s been hovered over for a second.

Now showing how specifying attributes in transition can lead for some fancy effects.

div {
transition: 1s height,
            1s 1s width;
div: hover {
transition: 1s width,
            1s 1s height;

This allows for some nice growth in order with hover on and off.

Some awesome slides in this presentation, like a drunk blow-up doll. Many laughs coming from the audience for the first time today.

Talking about intermediate values between properties, and how they don’t exist. For example, what is the intermediate value between block and none? There is nothing in CSS 3 that allows for transitions between backgrounds, for example. This is why you can’t transition display properties. (Display will also override transitioning visible in most browsers as well, so you can’t cheat around it.)

Showing how you can animate backgrounds and borders by transitioning position and width, etc. Some really snazzy looking stuff.

CSS4 and the future: you will be able to transition background images, as it will crossfade behind the scenes. An example of how this is already supported in Chrome, with some nice smooth crossfading between titled logos of the various browsers.

Lea and her awesome slides

Lea and one of her awesome slides

Some examples now about how to use ease in transitions, and a demo of cubic-bezier and a helper app that allows you to get a handle on how these transitions work with visual aids.

transition-timing-function: cubic-bezier(0, 1.5, 1, 2);

Transition limitations:

  • Can’t be fired on pageload.
  • Can’t be repeated.
  • Can’t have multiple states (keyframes).
  • Can’t be about different properties.
  • It’s not mandatory that they go all the way.

An example of the latter is that the user stops hovering over something that hasn’t finished it’s long transition, and it starts reversing from the point it has arrived at, rather than finishing it’s transitions.

This is why we have animations, a more powerful form of transitions.

Animations have to be declared with keyframes, even if you don’t intend to reuse them. Also have the ability to specify how many times an animation will repeat, right up to infinity.

Example of a beating heart for using these animations. An attempt to smooth it out, so that it grows smoothly but doesn’t snap back abruptly.

@keyframes pound {
    to { transform: scale(1.2); }
.heart {
    animation: pound .3s infinite alternate;


The alternate property allows it to really look more natural, like a beating heart in the way it shrinks faster than it increases.

Caveat: If a property isn’t animatable, it gets dropped completely and doesn’t show.

Animation limitations:

  • Can’t grow indefinitely.
  • Can’t have fixed speed/variable duration.
  • Can’t be synchronized.

Reality check: because of these features not being fully implemented properly, you’ll have to write lots of repeat code with browser prefixes in front of each one.

Wrapping up for lunch, now. Lea’s talk was a nice, fun, clear and concise way to unwind after Aaron’s full-on presentation. We end with a picture of a laughing donkey, which really sums up the lighthearted nature of this presentation. Come back at 1:50pm, after lunch, for Ronan’s live blogging of the discussion panel.


1.50pm – 3.50pm with Ronan
Now up: PANEL
* Douglas Crockford, Yahoo
* Ryan Seddon, CSS Ninja
* Vim Jobanputra, co-founder, bitbybit
* Kyle Barrow, Xero

Lunch in the belly and a prize draw for the prizes kindly organized by Malcolm Sheridan. Didn’t get the names of the winners, but they know who they are.

And now into the panel discussion. Xero’s own Matt Vickers, Product Manager for Mobile and Bank Feeds is moderating the discussion.

Douglas Crockford was likened to Indiana Jones, but he has no hat or whip that I can see from here….

First up: Javascript generally – what is the role of Javascript on the web today:
Ryan – Crossover between CSS and JS is increasing. It’s cool to see people pushing technologies even if they might be a bit of a hack.
Douglas – JS has historically been the workaround tool. As CSS etc fill in these gaps, it’s role will change.

Javascript and mobile – what are differences between that and the web?
Kyle – Modern mobile browsers are keeping the differences to a minimum – the bad old days are behind us.

Vim – JS is a compact language. It’s availability means you can get started easily.

Douglas – (possible QOTD) “Ok, I will write this in Javascript, but there is no way I will know what I am doing” – a common approach to Javascript today.

Why do people create tools to get around Javascript, like Coffeescript?
Douglas – I like Coffeescript, has a lot of nice syntax, and doesn’t try to give you the whole language. Javascript has a new role as a virtual machine for the Internet.

What tools do you use:
Kyle – Texttool. CodeKit
Ryan – webkit dev tools, remote debuggers on iOS. Browserstacks API for testing. Browsers have different quirks. Quirks seem to be coming up a lot today.
Vim – (doesn’t use VIM) Texttool, browser debuggers are getting better and better
Douglas – Text editor called Geany. Test tool called JScheck (correction via @widged)

Do frameworks obscure Javascript?
Vim – There is a danger they hide Javascript, but a lot of advantages.
Kyle – Not a big fan of heavy frameworks. Advice is not to use things like Coffeescript as it hides the JS.

Sorry if I’m not getting all the tool names etc right, no slides to work off and I am Irish so don’t understand all these strange accents.

And boom, Douglas gives it to Matt, explaining he doesn’t understand the question as he is a native English speaker. Take that Kiwi accent.

Javascript on the server:
Douglas – Avoids a lot of the issues that you get with threaded based systems. Javascript can be run in so many different ways.

Mobile and Javascript
Kyle – 85% of Android apps are just web views.
Douglas – Javascript actually works for mobile. They have tried a whole lot of other stuff that failed.
Ryan – Javascript is becoming the way to write apps for mobile. Write once for many devices.

There seems to be some concern for Windows developers from Matt. Panel seems unmoved.

Matt Vickers, Douglas Crockford, Vim Jobanputra, Ryan Seddon & Kyle Barrow

How will Adobe respond to the rise of Javascript?
Ryan – Pivoted away from flash. Embracing HTML5 and web standards.
Douglas – Adobe has always been strong in Javascript, been doing it all along. Winning isn’t so important, they just don’t want to lose.

Has Javascript helped deliver apps on the web?
Ryan – Javascript has helped the delivery of apps via the web. Single page apps that never need refreshing, though that poses it’s own problems.

Questions from the floor

Javascript for enterprise apps?
Douglas – Real issues with floating point types in JS.

Would you like to see the death of the browser? Javascript running outside of that?
Douglas – Be a real pity if Javascript was the last programming language, but not much on the horizon.

What could take Javascript’s place?
Douglas – For Javascript to be supplanted, something more accessible needs to come along. It suits all users – advanced and beginners (who maybe shouldn’t be using Javascript at all!)

On web standards:
Douglas – Web standards will have an impact on us, so we need to make our voices heard.
Ryan – Seeing standards forming around jQuery – it’s good to see.

Breaking news – Douglas Crockford recommends everyone learn Coffeescript. But don’t use it in production. It is a good tool for training, prototypes etc.

In terms of hiring Javascript developers, how can you test their expertise?
Douglas – have them bring in some code and walk you through it. See they understand it.

That’s it from the panel. A short break now and we might find out what the strange noises are – maybe the wind is whipping up around the waterfront?

Now up: Hamish Friedlander, CTO, SilverStripe

Hamish is from my friends at Silverstripe. He reckons you should use Entwine, Backbone.js and Silverstripe for all your web projects.
Just to confirm, Hamish is wearing pants. It is in his notes. He is a good looking fella too, but don’t take my word for it. See for yourself.


  • Name of the Silverstripe open source CMS, but also an OO PHP framework.
  • New CMS version just released, Silverstripe 3.0. Framework and CMS have been decoupled.
  • Silverstripe is a great open source framework. He admits he is paid to say things like that though


  • The C for your MV framework
  • Entwine.js can be found here
  • Entwine adds about 41Kb to page loads
  • Released a couple of years ago. It is part of Silverstripe 3
  • You can use Entwine by itself, but best used with a Javscript side MVC frameworks, but Hamish recommends Backbone.js

Best way to decide to use Entwine is by giving it a go, Hamish reckons. We are getting into a lightning speed demo now, hoping the videos up later will cover this better.

Hamish Friedlander

It’s quick and easy to create a data model and expose it via a REST interface in a few lines of code. We will make sure we throw the code samples up later.

He’s given us a taster to get you started (hopefully). Hamish used Reveal.js for his presentation, it looked lovely.

Now up: Alla Boglaeva, Technical Wizard, Provoke

Alla is going to tell us how to be a web developer. She started by making us stand up to show who is a back end developer, front end developer or not a developer at all. As a retired dev, I was in the last group.

Not getting a lot of interest when asking if anyone wants to try Sharepoint development. Even she admits it is a complex product. Another possible QOTD: “Sharepoint development is not very sexy”.

Complexity though, is not just about the product. The developer can have tunnel vision and not have an eye to other factors, or consider what might happen if someone else comes along later and needs to work with the code.

Someone has popped up to fix Alla. She isn’t broken, but her microphone is on the fritz. We can work through that.

Some challenges she has set herself:
– Can she find different ways to achieve the same solution?
– Can others take something she has started and continue it?

RESTful services using SharePoint 2013. Some cool stuff here. APIs are always good.

With RESTful services, it opens up Sharepoint to developers that don’t need to be Sharepoint developers. It also means Alla is communicating to others the object model and how they can develop with Sharepoint.

The key thing here is that there is always something new coming. Don’t fall into the trap of doing the same thing all the time. Mix it up – work with developers outside your core competencies.

She has said it a few times now, but I agree – try something new!

That’s it from Alla, slides up later. I’m signing off, but before I do, I have to admit I typed in ‘Anna’ rather than Alla a couple of times (since corrected) – sorry Alla!

Alla Boglaeva

4.20 – 6.00 with Matt
Now up: Vaughan Rowsell, Founder and CEO of Vend

Vaughan has just sauntered up to the stage like a louche ringmaster, ready to whip the audience to a frenzy – but nicely checks first that everyone’s awake.   Has decided to change topics from HTML5 offline apps – and is starting off with this video (which was entirely built in HTML5):

Vaughan hasn’t touched a line of code in about 12 months, but plans to talk about his journey through developing Vend, which began four years ago. Vend was developed as a prototype to prove that POS didn’t have to be bad – and he want ed to create something purely in the browser, with no plugins, in pure HTML and JS.

He wanted to create something offline – but this was before HTML 5, so he started out by creating something with Google Gears. Which was a great idea – but then the iPad came along, which changed everything – but in a technical sense, it actually only required 5 lines of code to support – and the choice to go with HTML and JS was vindicated.

Vaughan Roswell

Vaughan predicts that full HTML 5 support won’t actually happen until 2022.

HTML5 is easy because there is only 20 APIs, whereas native has thousands. HTML5 is great because you can use existing skills and resources, but there are some benefits to native: performance and coverage in App Stores are the big ones.

Vaughan is refuting that you can’t do great animation and graphics with HTML5, by showing us animated pasta, and is now showing us that you can use camera input with HTML5 also, by taking a screenshot of himself on stage using a pixelated Super Mario filter (sort of).

HTML 5 is getting better and better – but while it offers a world of possibility, sometimes the sad reality is that browser support isn’t quite there to meet it.

Vaughan’s now showing us how to use the HTML application cache for offline storage. Looks like you’re underway just by adding a manifest atrribute to your HTML tag. Neat. Once you’ve got a manifest file, the browser will serve up content from local storage. If you change the manifest, it’ll get new resources.

Vaughan’s now stepping through some of the cool features of HTML5.

Some problems with the blog and our VPN – bear with us, we’re just restoring some of the images.

Using the Web SQL Database you’re able to actually store a database on the client, but it isn’t widely supported. Alternative you can use indexedDB, which Vaughan thinks is the way forward. It supports cursors and transactions, though it is tricky to do complex searches. It has wide support and is not as bolted down as Web SQL.

Quota API is useful to keep track of your local storage quota.

Web workers offload processing from your browser to some JavaScript in the background. It really helps with UI performance. Vaughan is demonstrating this using a route-finding function while interacting with a map.

Speech Input is quite cool – Vaughan’s doing a live demo – “If you can understand me please say hi” was interpreted as “sammy please a” which got a good laugh.

Web sockets (yay!) real time comms back to the server.

Form field types on mobile bring up native controls for mobile sites.

Vend now supports only Chrome and Safari – which is not a deal-breaker for their customers – though he concedes that if you’re doing B2C you’re out of luck.

A few resources shared with the audience (we’ll add them later), and we’re done!

Now Up: Douglas Crockford, Paypal

Douglas is going to talk about programming style and your brain. He’s going to show us why some programming styles are better than others.  He is going to also talk about the brain works, referencing Daniel Kahneman’s Thinking Fast and Slow.

This comes back to economics, and there are two basic systems, our head and our gut.

Visual Processing is really hard for computers, but is something that humans do really easily. Douglas is now showing us an optical illusion. Brains that are confronted with inconsistency they compensate – they lie to you.

Advertising delivers messages directly to the gut, selling us things we don’t need. He’s using tobacco as an example. Our brain tricks us.

We use these same fallible brains to write computer programs. Originally there was a desire to write Artificial Intelligence to write computer programs for us. But you can’t give AI a set of requirements, so it doesn’t really work: we’re still writing programs in the same way were in the 50s, all that’s changed is the level of abstraction. Perfection is extremely hard to achieve – and when we’re not perfect (inevitable) a computer has permission to do the worst thing at the worst possible time. Even passing tests is not proof of perfection, because even tests only test what we know we don’t know.

Biologically we’re hunters and gatherers, and we’re using the same brain to with computers. We use our head when we code, but there is also a role for our gut. The gut helps us discover the need for change of perspective – but he has no evidence to support that statement, though his gut tells him this is true. :)

Computer programs are about tradeoffs, and the gut is bad at tradeoffs.

Every language has good parts and bad parts, JS has some of the best good parts ever, and some of the worst bad parts.

JS Lint was written to help people write better JavaScript – it will hurt your feelings. Programmers will argue a lot about things like curly braces. There’s no good reason for any particular style for curly braces – but like driving on roads – it’s a really good idea for people to agree on the same rules.

But in the case of JavaScript, Douglas argues that curly braces are important.

The difference between

ok: false


return {
ok: true

is that the first example the return will get a semi-colon after it, causing a silent error.

With switch there’s a problem with fallthrough hazards.

We don’t spend most of the time power-typing, we gaze into the abyss. We tend to black-out parts of the programming we’re doing, and that’s how we’ll make mistakes.

“That hardly ever happens” is another way of saying “It happens.”

We’re now on to medieval copyists and scribes – how conventions around lowercase, work breaks and punctuation developed.  Innovations like these reduced the error rate for scribes.

Cool – Douglas is now talking about Strunk & White’s Elements of Style.  Style’s important and it’s just as important for computer programs – programs are not just communications to computers, they are communication to other programmers.  We should be using literary conventions in our programs.

Douglas is now pointing out some good conventions for JavaScript development: the correct use of spaces, and the correct way to lay out functions – so that we don’t have the invocation stick out like dog balls.

Never rely on automatic semicolon insertion. It was well-intended, but it is a broken feature of the language.

Don’t use the with statement – it can be interpreted in strange ways, write out the expression directly, to avoid confusion.  We want to avoid confusion – it’s not friendly to others.

Always use ‘===’.  ‘==’ is confusing, it has unexpected results depending on the implied type of the left/right hand side of an assignment operation.

Multiline string literals are a fairly new feature, but they’re confusing too – if you stick a space on the end of part of a string you’ll get a syntax error.  Confusing.

Douglas’s advice: instead of using confusing syntax, find out how to express exactly what you mean (which is possible in JavaScript) and do that.

let is coming – probably in ES6, which will declare a variable to the block scope.  When that happens, we should use let instead of var.

Global variables are evil, but if you need to use them, stick them in all caps.

Douglas hates the ‘++’ operator, he’s a fan of ‘x += 1′. Does the clown using ‘++’ know the difference between pre-increment and post-increment?  Tracking down bugs related to this are really hard.  He doesn’t understand why programmers are deeply invested in ‘++’ – but they are.

He makes the point that if we are going to be more agile, our coding needs to be more resilient, style is important if we’re going to code fast.

Who are the bad stylists? They’re:

  • Under educated
  • Old school.
  • Thrill-seeekers
  • Exhibitiionists

Essentially it’s either a lack of knowledge or showing off – but just because you can, it doesn’t mean you should.

Programming is the most complicated thing that humans do, programs must be perfect, but humans are not perfect.  Good style helps reduce error rate and brings us closer to perfection.  The alternative is to descend into the abyss.

JS Lint was created to automatically detect defects related to style.

Douglas Crockford

The language designer is powerless to remove bad features once the language is out there, but it’s the coder that has the power to use the good parts of the language and avoid the bad parts.

As Nietzsche once said: When you gaze into the abyss, the abyss gazes into you.

And that’s a wrap folks! Time to party.


Read more about Developers


1 comment

23 November 2012 #

This can be a four star evaluation.

Add your comment

We welcome all feedback but prefer a real name and email address.