Sunday, January 13, 2013

My coffee shop name

You may have read the article on the Economist blog recently called 'My Starbucks Name'. The guy who wrote it has a name that he considers a liability in coffee shops so when the baristas ask his name he uses a pseudonym, "Sam", that's easy to say. "If you use a Starbucks name, why do you do it? For convenience, speed, or privacy?" he asks. As well as prompting me to answer him, I found the article interesting for two reasons.

One: if a blog post about giving a made-up name to the person who makes your coffee is good enough for The Economist (even if the blog is about words and language) then I'm going to stop worrying about the relevance of my posts.

Two: I know how S.A.P. (the Economist blogger) feels. His article brought me back to a situation a couple of years ago when I did the same thing myself. I adopted a coffee shop name.

The Story

Every day at 2 o'clock we would take the lift down from the 8th floor to go and get coffee. Even if you didn't particularly want coffee, you would go and get coffee. There were usually around 5 of us and we always went to the same place straight after lunch. It was happy hour: $2 for a huge coffee.

It was usually busy so we needed to streamline our operation. I had struggled to make my name (Ralph, but pronounced Rafe) understood to people who worked in other coffee shops and I was sick of explaining how to pronounce my name over and over, so I hit on the idea of picking a name for this new place, a Starbucks name, one that worked well over a noisy channel: Alex. As well as being my kid's name, it's short and doesn't tend to get confused with other names.

Alexander at Bohali"Hey Dad, can I use the computer?" "Sure son, if I can use your name."

Why not just allow my name to be pronounced the normal, phonetic way, i.e. pronounced 'Ralf'? Well, I consider that to be a different name, and if I'm going to capitulate on the name thing I'm going to at least please myself and pick a name I feel like using for this purpose, not the mispronounced version of my actual name. And it all worked fine for a while: we'd banter with the girls who served us while we ordered and then waited, and they'd use my name as part of the conversation. But I was just getting in deeper.

Hacking coffee time

I thought I was being clever, hacking coffee time - I thought I was simply using a variable. But when the barista girls found out my name wasn't actually Alex they didn't see it like that. They thought I was a bit of a creep. Names matter, and it seemed I had deceived them. They professed to be outraged and shocked. Undoubtedly there was a bit of game-playing and silliness going on. But there was little doubt that they did consider that I had breached some sort of social contract, however tenuous our relationship. Maybe it was because since they had to wear a name badge all the time, customers should be equally transparent with their names - I don't know.

When I explained to them why I’d done it they claimed to understand, but I still got the odd crack about it for weeks after. This is despite the fact that they could see what happened when I used my real name in front of any of their co-workers who weren’t privy to the whole name change thing. We both would watch them get confused, and they could see first-hand why I did it. In fact, they themselves, the ones who had made the biggest fuss, would start getting my name wrong, until ultimately I said “Please, let’s just revert to my coffee shop name.”

The boxes of our mind, and their labels

What I find interesting about the whole thing is to imagine how the people with whom you use a pseudonym might react when you reveal it's just that; a fake name. I actually don't blame the coffee-shop people for being ticked off. We put people in little labelled boxes in our mind, each friend or acquaintance, even just coffee-shop acquaintances, and it's jarring to have them taken out and shuffled around. Usually people go in a box and stay there - you don't often mistake someone's name and have to relabel them, so it's not something you're used to.

So that’s why I use a coffee shop name. That term has a nice ring to it, and I don’t use Starbucks, so that’s the term I’m using.

Tuesday, January 8, 2013

Getting started with TypeScript

The introductory TypeScript video on Channel 9 by Anders Hejlsberg (AH) is great, but how do you remember the examples he used? In this article I go through some of them.

I watched the video, and took inspiration from it. It all made sense, it flowed like poetry. But video doesn't lend itself to bookmarking or random access, never mind copying and pasting. How is one supposed to remember the concrete examples that AH uses in that video? I thought I'd simply list those examples in an article for my own benefit, mainly to serve as a personal starting reference, but naturally being a blog post I'll be glad to hear if anyone reading this gets any use out of it too.



At the very beginning of the talk, one of the most fundamental TypeScript concepts is introduced: type annotations. That's where the much-vaunted 'type safety' of TypeScript comes from, or if you like, 'static typing'. You can tell TypeScript that a property, or even a function, represents or returns a particular data type, say, a string. It can't make the resulting JavaScript type-safe, because there is no such guarantee in JavaScript, but as long as you stick to TypeScript to author your JavaScript, then you're ok. And - an important concept in TypeScript - annotations signal your intent within the code.

I've actually changed the examples AH uses slightly. Alright, I changed them a fair bit, mainly - I dunno - to make it fun for myself, and to avoid feeling like I was just parroting the great man's words. Make sense? Ok, let's go.

1. Classes

One of the first things AH does is create a class.
class Country{
    Capital: string;
    Population: number;
    SomeoneWasBorn: () => number;
}

var country = new Country();
country.Capital = "France";
So we're telling TypeScript that the Capital property is a string, Population is a number, and SomeoneWasBorn is a function that returns a number. Notice the statement completion when you type "country." - TypeScript prompts you by suggesting the 3 possible properties. Noooice! Also, if you look at the generated JavaScript, the properties don't exist, at least not in the declaration of the Country object. It's only when you new up an instance of country and assign values to any of its properties that it actually appears in the generated code. It's lazy like that.

2. Constructors

class Country{
    Capital: string;
    Population: number;

    constructor(Capital:string, Population:number){
        this.Capital = Capital;
        this.Population = Population;
    }
}

var france = new Country("Paris", 60000000);
Pretty straightforward. But what if we want to make our constructor smarter? We could have it take an initialization object, but not any old arbitrary object. We could make it take a strongly-typed object.

3. Interfaces

interface ICountryProperties {
    Capital: string;
    Population?: number;
}

class Country{
    ....
    constructor(properties:ICountryProperties) {
        this.Capital = properties.Capital
        this.Population = properties.Population;
    }
}

var ireland = new Country({Capital: "Dublin"});
The constructor now takes an initialization object that implements ICountryProperties, which tidies up that hitherto rather messy looking parameter list and provides some tooling benefits to boot, since the editor will dutifully light up if you omit any of the requisite (Population is optional) properties.

4. (Instance) Methods ...

class Country(){
    ...
    GDP() {
        return this.Population * 100)
    }
}
var france = new Country({Capital: "Paree"});
var gdp = france.GDP();
You normally would put instance methods for an object on the prototype of that object, that's just good JavaScript form, but with TypeScript you don't have to worry about any of that. If you want to you can inspect the generated code and see that that's exactly where the method has been declared. Note the extraordinarily low GDP as high achievers all flee to Belgium or Russia to avoid M. Hollande's tax.

... and how to turn them into properties by adding an accessor

get GDP() {
     return this.Population * 100;
}

var GDP = france.GDP;
Note addition of "get" and subsequent disappearance of "()";

5. Static members

class Country(){
    ...
    static numberInEU: number = 27;
}
alert("france is one of " + Country.numberInEU + " countries in the EU.");

6. Private members

class Country{
    ...
    private dirtyLittleSecret:string;
    constructor()
    {
        this.dirtyLittleSecret = "Ships weapons to Korea";
    }
}
var country = new Country();
country... // no dirtyLittleSecret property
Note that the private property doesn't appear in the statement completion when you new up a country object despite appearing to be a normal variable in the generated JavaScript. Privacy is purely a TypeScript expedient: there is no equivalent notion in JavaScript. Again, very much a case of signalling intent.

7. Automatically generated properties

class Country{
    // no need for those properties...
    constructor(public Capital:string = "Australia", public Population:number = 22863449){
        // ...and no need for those assignments
    }
}
var australia = new Country();
A nice little piece of 'syntactic sugar'. The properties get generated on the object from the arguments, and we're whacking in defaults too for good measure. So we no longer need to specify those properties on the class, nor assign to them in the constructor. Less code to type, more time to spend with our loved ones. Note that the population is the estimate for 2013.

8. Inheritance

class France extends Country{
    // France-specific stuff
}

var france = new France("Paris", 65350000);
alert(france.Capital);
Statement completion on the base properties! C├ęst formidable, non?

8. Arrow functions

class Country{
    Population: number;
    constructor(population:number) {
        this.Population = population;
        setInterval(function() ()=> {
            this.Population++;
            alert(this.Population.toString())
        }, 1000);
    }
}
var c = new Country(1300);
In this example, I new up a country with a seed population and watch as there's one born every second. The "this.Population" only works because it is lexically scoped to the outer "this", i.e. the Country class itself. If we leave the "function()" in place instead of the "() =>", "this" refers rather uselessly (for our purposes) to the Window object, ergo "this.Population" is NaN. To get around this (and indeed, this is what TypeScript has to do), you normally have to resort to 'this-aliasing':
var _this = this;
which is fugly. As well as all this there is the very real advantage that this syntax makes you look cool. Any jackass can read 'function()' and see what it means: most mortals, when confronted with lambda syntax like '() =>' quiver in fear. Not us, oh no.

9. (Internal) Modules

module World {
    export module Europe {
        export class Country {
            Population: number;
            constructor(population:number) {
                ...
            }
        }
    }
}
var ireland = new World.Europe.Country(1000);
Modules are so hot right now. If you look at the generated code for this simple example, you'll soon see that writing a module like this saves a lot of space and well, obfuscation. The TypeScript is a lot clearer.

In these examples I've deliberately avoided showing the generated JavaScript. That's because it's somewhat irrelevant what the JS ends up looking like as long as you 'model' it correctly with TypeScript - you've delegated responsibility to TypeScript to do that. Rest assured that you get clean, idiomatic JavaScript, almost certainly better than the stuff you were going to write yourself. It reminds me of the way we all relinquished micromanagement of our SQL when we made the move, maybe at first reluctantly, but eventually without giving it a second thought, to Linq?

Anyway, like I say, this was just a way for me to keep some of the 'canonical' TypeScript idioms in one spot for my own convenience. Hope you find it useful too.