The vocal portions of the Web that care about such things seem to have already made up their minds about Dart, the new web programming language from Google. My opinion of it has been flipping between intrigue and tedium.

Maybe you don’t even know what I’m talking about so here’s the gist of it: last week at the GOTO conference Google unveiled, to moderate hype, their new programming language called Dart. The official aim of Dart is to help developers with writing “structured web applications” – which sounds like a euphemism for “[eventually] replace JavaScript” — to some at least. I’m going to explore that loaded sentence (or go to tl;dr).

Origins of Dart at Google

Google and the Web are inseparable. To many, the Web would pretty much cease to be useful without Google Search and Gmail. Google pioneered, or at least popularised, the foundations of modern web application development, namely AJAX. When Google Maps was released it was a breath of fresh air in its product niche and an astounding achievement in programming and UX. The thing to note here is the J in AJAX, which stands for JavaScript. Having wedded itself to the Web, Google has had to wrestle with this piece of technology since the beginning of its forays into anything more complicated that a search box and a list of results.

I doubt a Google spokesperson has ever come out to say it, but it’s clear that Google staff are no fans of JavaScript. Six years ago, they got sick of figuring out the look and feel of things and started work on GWT. A few years later they got fed up of the performance of JavaScript runtimes and wrote the source-to-source Closure Compiler/Optimiser for JavaScript and started work on their own V8 JavaScript Engine which powers Google Chrome (and notably also NodeJS). All in all, a business expense of at least tens of millions of dollars, not to mention the headaches and opportunity cost. Of course, Google has to go all this effort because of the scale of their JavaScript codebase, which makes any criticism from small- to medium-sized development teams utterly moot when they say “we’ve never had a problem with normal JavaScript” — yes, of course you haven’t, because you’re not juggling a web application product line which includes Gmail and Google Docs.

This leaked email from Googler and ECMAScript committee member Mark Miller emerged last year. It provides an insight into Google’s view of JavaScript as a bottleneck in their efforts to build products that compete with native applications. It’s a long read but the gist of is that Google can either wait for JavaScript to evolve slowly, and/or take action and write its own better JavaScript, codenamed “Dash” in the email. The main goals of the new language are listed as performance, developer usability (including familiarity) and improved tooling (a.k.a. clearer code structuring and packaging), which no-one will deny are lacking in JavaScript.

So they did just that. Sort of.

Dear Google, Public Relations != Developer Relations

<rant>

Google suffers from NIH Syndrome: it does not take from the outside world, preferring to build its tools from scratch, and anything it produces it does so mainly for consumption by the thousands of people it employs (this manifests itself in things like their approach to Platform development, too). Don’t let the odd open-sourced project fool you.

In the case of Dart (not the first Google-made langauge) they may have hyped up its announcement, but they clearly have no intention of letting programmers — the only people who care — actually experiment with the new language yet. When you go to Dart’s code repository, there is little effort made to make it simple for you build and use anything. Maybe Dart is just not ready for too much public airing, but that means they should have left its unveiling until it was. Google is not providing a pre-built compiler or VM binary for Dart, and their build instructions are just about tedious enough that I’d rather not waste my time. If git clone and make install are good enough for many a large project, why am I being instructed to install and use a Google-specific tool to merely fetch code?! No thanks.

</rant>

What’s Dart Like?

Apart from syntax and code samples that run in the browser, there isn’t much to go on. I quite like this article that says Dart is to JavaScript what C# is to C++: basically cleaning up some of the mess. Here’s a summary of what I think are the main features to give you a feel.

Key Language Features

Purely class-based

The class and interface concepts from Java are brought into Dart, almost exactly, with multiple inheritance being achieved through implementing several interfaces. The “purity” here refers to the idea of everything-has-a-class (or everything-is-an-object), which is lacking in both Java and JavaScript, and can only be a good thing. This applies to functions, of course, which makes closures possible in the same way as JavaScript. Compared to JavaScript’s prototype-based model of OOP this class-based approach makes writing Dart code less crufty, more familiar to the average programmer, and will make tooling and dealing with hierarchy of the code simpler or at least easier to adapt from existing tools.

I suspect this model improves the run-time performance of Dart code compared to JavaScript, too, since JavaScript’s prototypal inheritance and functions-as-objects idiom are expensive (objects are cloned or recreated instead of referenced or re-used), at least without a good JIT compiler (but don’t hold me to that).

Optional typing

This is one of the more baffling features for me. You could write Dart code without any consideration for variable types, but you could also annotate your variables with types, like String or any class you’ve defined. The baffling nature of this is that the annotation is just that, an annotation: it makes no difference to how your code works, other than the compiler giving you a warning if you’ve misused the variable (e.g. tried to assign a number to a String variable). The code will still compile and run.

The justification for this feature is that it provides “documentation” and aids debugging and static build tools during development. I’m not convinced by this half-feature. Perhaps the makers didn’t want to put off web developers with scary strong typing or the goal of making Dart compilable to JavaScript was an obstacle. The official advice is “use types where they make sense”. To me, that advice doesn’t make sense.

Structure and isolation

One of the big practical difference between JavaScript and Dart is that when embedded in HTML, each script tag containing Dart code is isolated and can not access other scripts directly, i.e. there is no per-page global namespace. Also, Dart code isn’t simply run when it is encountered but a main() function needs to be included as the entry point into each piece of code. In theory, the designers intend each portion of code, or isolate, to be able to run in its own thread, but such multi-threading support is non-existent in browsers.

This is where the “structured” nature of Dart is most obvious and I personally like it compared to JavaScript, but those used to the way JavaScript behaves will resist it.

In the language specification, there is some detail about the concurrency model of Dart, which involves these isolates behaving like actors which perform local computation and then communicate via message-passing. I didn’t spend much time trying to understand these, but this (rather negative) write-up has an explanation.

Why you won’t use Dart

Firstly, there is obviously no practical implementation for developing or deploying Dart code, so don’t waste your time on it yet. Even the Google Chrome team aren’t 100% on whether and when they will implement a Dart runtime, let alone other browser vendors.

Secondly, although all concepts used in Dart should be familiar, it is still a paradigm shift for web developers and you can get by just fine with JavaScript. This extends to the way Dart handles DOM events which is something many developers take some time to completely absorb even in JavaScript with all the online documentation available, let alone with Dart’s event model.

Thirdly, if you really don’t want to write in JavaScript, and you don’t have Google’s NIH Syndrome, you already have access to many well-established alternatives. I have written a non-trivial amount of code in CoffeeScript, which is a pleasure to use, and look forward to playing more with ClojureScript, which is elegant but still immature. Of course, JavaScript isn’t just “assembly language for the Web” which can be ignored and you still need to fully understand its intricacies before trying to work around it.

tl;dr

This chap on StackOverflow got it right, in my opinion: Learn JavaScript, use CoffeeScript, check out Dart.

WK’s High Frequency Trading How To covers some of the technical aspects of software and systems that handle high frequency trading from someone that has worked in the area. Hopefully the blog will continue with regular posts and get more in depth as it goes on – it looks good so far.

120 individual PNGs for one jigsaw

As mentioned before, Jigosaurus is a multiplayer jigsaw puzzle that is played through a web browser. When Aleksei, Yasser and I joined as part of the Caplin Graduate Scheme, we were given the task of getting it running and improving it, and today we’ll be looking at the client facing end.

Following the route of the jigsaw from server to client, we quickly found a limitation. Each jigsaw that we wanted to be played had to be generated from an image with another tool before it was ready to host on the server side. This meant cutting the full image into around 200 individual pieces and saving them as PNG files ready to transfer over the internet. Then with many <img> tags placed in the right position, the clients browser could give Jigosaurus piece elements their correct look.

Variety is the spice of life

Clogging up the network with hundreds of requests

This “chop up once, serve many times” method may be good in a situation where everyone plays the same kind of jigsaw, but as soon as someone wants to try the same puzzle that has more or fewer pieces not only would we have to run the same image through the chopping tool again, but we would waste space on additional PNG files that represent pieces of the same image.

Even if we were ok having no variety in our puzzles (boo, hiss), we still have the problem of actually sending multiple images over the network. These piece images will rarely be sent over the network in complete parallel and so have to queue behind each other. Combined with the overhead of sending each file, this means more time waiting and less time puzzle solving.

CSS is more than a pretty face

Sprites for the Gmail Inbox page are held in one image file

The problem seems to be a server side limitation of pre-processing things for an individual, so we could try doing things with a bit of extra code on the client side. We could use Javascript as a work horse to cut up each user’s jigsaw, but this would be slow and there is a cleaner way.

Browsers are optimised to handle styling through CSS well, so we can take advantage of this and get the browser to cut up our jigsaw natively. This technique is known as CSS Sprites.

This technique is normally used for pages that contain multiple images that are usually used all at once. Icons, logos and other pretty pieces of image could be served up individually like our jigsaw pieces, but are instead mashed together and sent all in one go. Each relevant element references this large mashed together image, but by using the background offset CSS property, the element only shows a window of this one large image. This means only dealing with the resource overhead of one file and taking advantage of a browsers optimisations for CSS styling.

This technique is perfect for Jigosaurus, so we ditch the <img> tags for each jigsaw element and just add an individual background-image style that references a small window of the full image that would normally have to be cut up.

Before: 72ms page load - the majority being images

After: 8ms page load - a dramatic improvement

Not only do we see a dramatic drop in loading times, but we also pave the way for jigsaws of different shapes and even jigsaws that aren’t just static images…

A Google Tech Talk by James Whitaker on The Future of Testing brought up the topic of adding visualisations to software, saying that we need code to become visual for us to be able us it effectively and some people here at Caplin were somewhat unimpressed with his assertion.

Now there are definitely some people who agree with Whitaker. Hollywood understands that people love visuals. When the elite hacker is breaking into the CIA mainframe, a fantastical scene unfolds before your eyes, perhaps with lasers and gigantic “Access Denied” messages. It’s a great plot device, the layman can understand the tension of what the black hat is doing and the computer programmers can make fun about how ridiculous it all is.

A real, though somewhat impractical, 3D file browser used in Jurassic Park. (Courtesy http://www.siliconbunny.com/fsn-the-irix-3d-file-system-tool-from-jurassic-park/)

While I agree that most movies prefer the fiction part of science-fiction, I don’t believe this means that they don’t have the right idea. Humans, software engineers included, are visual creatures. We prefer graphs, not tables. We like green/red lights, not reading test logs. We draw class diagrams, not print out class definitions.

Yet when it comes to try and push a visual interface onto our code more directly, there appears to be an immediate reaction that “it would never work in real life”.

But why is this so ridiculous? After all, if a console application can have a GUI interface, why can’t our source code have a visual augmentations? Architects started to manipulate their designs through renderings as soon as the technology became available and yet we still insist on writing things at the most basic levels.

We often use class diagrams for planning, yet these are seldom visualised in IDEs. (Courtesy http://www.conceptdraw.com)

Is it so ridiculous to have a 3D rendering of how our classes interact with each other? Perhaps a line diagram showing how data flows through our application? How about a color coded background to indicate the complexity of certain methods and classes? What about a heat map showing which classes and methods have had the most bug fixes?

As code grows ever more complex it is going to become more and more important for our code to become as visual as our daily lives. While we will never be able to get away from writing our code in files, it is ridiculous that in 2010, after all the advancements in our technology and profession, we are writing our code in much the same way that we did in the 1980′s.

if you don’t have a good name for it, give it a bad name. a really, really bad name so you’ll fix it later.

Good naming is hard

Sometimes when writing a class, or occasionally even a method, I struggle to find a good name for it. After a while I give up trying to find a good name for it and chose something that is just about “OK”, a working title if you like. Unfortunately this tends to create poor generic names, such as “ConnectionManager”, that vaguely make sense, but can obfuscate the true purpose of the class. I’ve lost count of the number of times that I’ve heard developers say something like, “Oh, so that’s what that class does!”

The problem with these “OK” names is that they tend to have a strong inertia to change. Typically I have the intention of going back and renaming it, however the longer I leave it the less likely this is. If the name is adequate, but not great, then why go through the effort of renaming it? Sure, some IDEs, such as Eclipse, do a superb job at refactoring, however a lot of the code we write here at Caplin is in JavaScript and the tool support for this isn’t as good. Regardless of this, even where there is good tool support, there are time pressures, backward compatibility and other considerations that lead to “OK” names sticking.

Overcoming renaming inertia

This brings me back to Kent Beck‘s excellent suggestion. If you provide something with a really bad name the inertia to change it will be non-existent. You will have to change it before it becomes part of your public API or other developers have to use it.

The great thing with this is that it allows you to write your class and see what it responsibilities are before you provide its proper name. This should lead to meaningful names that define exactly what a class does, ensuring no one is surprised when they try to use it.

Personas are a tool we use at Caplin to help us REALLY understand who our users are and engage everyone in the company in building something compelling that will delight our users. No I am not talking about a sexy, gimmicky UI which when first stumbled upon people go “Wow”. I am referring to a product that seamlessly fits into the user’s life, compliments their day-to-day tasks and basically engages them to a level that they no longer can live without it.

So what is a persona?

A persona represents a group of users that hold the same goals – an archetype. These goals are not “I like to use this feature” BUT “what’s the end goal in an individual’s or company’s day/week. It’s only when we look outside the boundaries forged over time that we begin to really understand their needs. If you are passionate about doing this you will deliver products that delight.

The persona also includes people that are driven by the same motives, driving like-minded behavior with common frustrations.  Just think how powerful this is when developing a product. There will be no self-referential in a meeting room arguing, ” No, I think it should do this because that’s what I would like to do”, or “how cool would it be if we added this feature”.

EVERYTHING is referred back to the persona – does it help them achieve their goal? No? Then out. Yes, then how?  Design meetings become focused on making the persona’s life easier,  aligned to removing the pain points in their process. No swirling gimmicky feature just because the technology can do it, it has to add value to the persona.

At Caplin, we have found it has removed the ambiguity around the term “user” and has also been a great educational tool on who our users are. We are now seeing many developers refer to the persona by name in discussions and has really helped us “walk in the shoes” of our users and show real empathy during the development process.

The real power also comes when you use Personas with Narrative Journey Maps.

When an end to end acceptance test fails, the failure could be due to any one of a large number of source lines or expectations changes across a large body of code.  Debugging may be quick, but often isn’t.

Small tests run faster too! While a typical small test may take 10 milliseconds to run, a large acceptance test may take twenty minutes.

Just a small back of the envelope calculation tells us that if a developer checks in twice a day and saves an hour each time because potential issues had been found before check-in with fast small tests, and the faster feedback, or has reduced their time spent debugging – that is two hours a day per developer that could be put to better use.

2 hours a day * thirty developers * two working weeks = 600 additional hours per two week iteration available.

This is equivalent to adding seven and a half developers to the team!

What value do you get from tests of different sizes?

Ignoring this testing just generates projects which will fail – not may fail – will fail, categorically will fail!

There are two sets of tests that are critical here…

Good unit test coverage and a TDD approach to development ensure that the rest of the organisation is supplied with product that works as developers expect it to.

Component tests and functional acceptance tests ensure that the product does what the product owner expects it to.

• Practically, the only way to do solid testing on new features is to have a stable product.
• Practically, the only way to assure a stable product is to either have solid regression testing on each release or to not make any changes.
• Practically, the only way to make sure that adequate regression testing is done is to automate the regression tests (unit, component, functional).

Without these tests in place, iterating quickly places an impossible to meet burden of verification demand on the testers and product owners, which just gives you a fragile process not an agile one.

Is your process Agile or Fragile?