Dan Newcome, blog

I'm bringing cyber back

Archive for March 2010

Javascript zen: the class is the object

with 2 comments

I was reading Douglas Crockford’s book `Javascript: the Good Parts’ when I came across an example involving a parser that was seemingly unrelated to the section that it appeared in (Section 5.3, p51). I re-read the section and then looked at the example again, wondering how such an oversight could have occurred in this book, which had up until this point been impeccably organized.

I decided to look at the example in detail one last time before moving on when I was suddenly enlightened.

In the book, Crockford describes a situation in which he had vigorously defended his position that default fall-throughs on switch statements are useful, only to have someone report a bug in one of his projects the very next day involving just such a switch. In that moment he was enlightened and reversed his position.

In a similar way, I had been a proponent of using the `new’ operator with constructor functions for defining classes and instantiating objects (classical inheritance). However, my background has been in strongly-typed languages, so this is the way that I tend think about the subject. However, the more I use Javascript the more evident it is that you need to avoid trying to shoehorn other development methodologies into it and let it shine at what it does best: prototypal inheritance.

Here is the example from the book:

var block = function (  ) {

// Remember the current scope. Make a new scope that
// includes everything from the current one.

    var oldScope = scope;
    scope = Object.create(scope);

// Advance past the left curly brace.

    advance('{');

// Parse using the new scope.

    parse(scope);

// Advance past the right curly brace and discard the
// new scope, restoring the old one.

    advance('}');
    scope = oldScope;
};

Written by newcome

March 31, 2010 at 10:23 am

Posted in Uncategorized

The value of free coding

with 2 comments

Climbers on "Valkyrie" at The Roache...
Image via Wikipedia

In a time where nearly every mainstream development environment has the benefit of IDE support including source-level debugging, auto completion and even incremental compilation as we type, I think that there is still value in stripping things down to just a text editor and a compiler. I have met developers who have been of the anti-IDE camp through-and-through, but the idea that I’m putting forward here is not that IDEs be avoided, but that in the process of cementing new programming knowledge, there is value in doing it `without ropes’.

When rock climbers go without equipment to aid their ascent, it is called free climbing. In this spirit, I’m going to refer to coding without extended tool support `free coding’. In free climbing, for safety, many climbers still use ropes and harnesses but they are never used to aid the actual ascent — only to prevent catastrophe in the event of a fall. Likewise, in free coding we still have some tools that keep us from falling: the compiler as well as language support for stack traces and debugging statements.

I’m not going to go as far as Charles Petzold and claim that advanced tool support is rotting our minds, but I am suggesting that by not forgoing the aforementioned occasionally, we are denying ourselves the opportunity to reflect contextually about the code that we are writing. Instead of pounding away immediately on the keyboard, hoping that Intellisense will know what to do next, we can pause and think for a moment, or perhaps consult the documentation for insight.

One of the main advantages to free coding occasionally is that we can get over the initial panic of not knowing exactly what to do next. I recently interviewed for a job where the first thing that they had me do was to code some simple algorithms in a text editor, without even a compiler to check the programs. Even though the programs were simple, I still had a healthy dose of insecurity about what I was entering into the text editor! I credit that I was able to perform well in this interview to my occasional free coding experiences.

There is another aspect of free coding that I will call `free designing’ which is to approach the problem without referring to prior solutions. I’ll leave this one for another blog post, but I think you can see where I’m headed with it: that others’ solutions can become anchors in much the way that a salesperson’s starting offer anchors a negotiation. Everything is wide open before the anchor drops, and it is valuable to see where your own solution lands in relation to others’. It is the comparison of the actual vs. expected that provides a huge opportunity for growth and understanding.

Reblog this post [with Zemanta]

Written by newcome

March 22, 2010 at 11:47 am

Posted in Uncategorized

How not to write an email opt-out page

with 11 comments

Periodically, I take a hard look at what shows up in my email inbox. Invariably a few emails are sitting there because I either opted in to something unwittingly or perhaps I opted in knowingly but now the emails have worn out their welcome. Either way, it is time for a purge.

This time around I noticed a stark contrast between two opt-out pages that I visited.  Running down through several emails, I hit one from a credit card rewards club. I had been moving along at a nice clip, but upon seeing this page I had to stop and figure out what to do.

What is wrong with this page?

From a visual standpoint, it is not easy to see where the text for one option ends and the other begins. From a content standpoint, the copy is much too verbose. I just want to stop getting emails! Which one gets me there?

Forcing me to stop and think this way might be advantageous to Citigroup in that maybe I will be dissuaded from opting out, or opt to still receive certain emails. However, there may be a better way.

The next opt-out page that I visited was that of Zzounds, an online music retailer.

This page is awesome on a number of levels. In addition to the simple and easy to scan layout, the default action was performed for me. I didn’t have to figure anything out at all to get what I wanted – to stop getting emails. Not only that, I really was thinking “did that actually work?” and the page copy confirms that yes, it was “too easy”. I’m actually not annoyed that they are inviting me back to the list. In fact I’m almost feeling some goodwill here.

An email opt-out page is a point of customer engagement. Someone is expending conscious effort to do something, and from the vendor’s standpoint, that something is a negative event. But any time a customer is engaged is an opportunity to reinforce your identity in their eyes. I don’t have any metrics on the impact of an opt-out page, but this exercise has got me thinking.

Written by newcome

March 12, 2010 at 11:24 am

Posted in Uncategorized