Rob Conerys Blog

Knowing More Programming Languages Will Make You Smarter

2013-05-13T10:00:00-05:00

There's a thought in neuroscience/psychological circles that words are much more than sounds that represent things: they are the abstraction of our higher brain function. Words are language, code is language. Restricting yourself to one or two languages is limiting your cognitive abilities

image from http://visual.ly/network-graph-programming-languages-influence

Words as a Conceptual Map

There's a small bit of setup here - bear with me. I relistened to one of my favorite RadioLab podcasts ('Words') this weekend and had my mind blown, once again. They dug into what words mean to us and, according to the show, words are much more than expression vehicles.

Words are the very structure of our higher reasoning.

In other words: if you can't say it, you can't think it. The words themselves are cognitive variables strung together to represent feeling, emotion, memory - abstract things made concrete by the words we put to them.

High-minded stuff and rather than regurgitate the whole show here - go listen if you haven't, it's very good. It left me quite inspired and I wondered if the the ideas in the show could extend to programming languages. Why not? Code is simply syntax laid on top of process that a machine needs to understand... hmmm....

We tell machines how to think - which directly reflects how we think. Writing code always seemed like such a "machine-y" thing to do, but I think that's not the case: Programming languages are true languages written for us to describe problems that a machine can understand.

These languages are stripped of nuance and imbued with functionality (loops, terse conditionals) for a myriad of problems. How well do you speak code?

A Thought Experiment

Code is language, and how we solve problems with a given programming language directly relates to how we think in that language. This doesn't seem like an amazing revelation in and of itself - in fact I think you probably already understood this quite well.

But what if we reversed it? What if you couldn't think any other way - other than what that language allowed you to think. What if your coding language of choice was the abstraction over your programming thought process - that you actually lacked the mental faculties that lie outside of what that language can represent?

Let's say you walk into an interview and you get hit with a classic interview question (no, not FizzBuzz): write a routine that spits out Fibonacci numbers. It's something every dev has had to do at some point.

Now, slow your brain down and rewind. What language are you using to express this? What is that language allowing you to do.

If the only programming language you know is C# you're probably writing some LINQ in your mind and running a modulus. If you use Javascript you're probably doing something similar but maybe spread over two functions utilizing callbacks.

Rubyists out there might do something similar - favoring a more idiomatic approach with blocks/yield rather than a terse one-liner.

Now write it using a Monad.

Recursion?

I'm sure a few of my readers could do all the above (LINQ, callbacks/blocks, Monad and Recursion) but I doubt that most of you can. This is due to the languages you know, the idioms they use, and the way those languages allow you to think about a problem.

Expanding Your Thought Process

I don't know anything about monads but I've done recursive programming in the past (sometimes not-intentionally). When I started using Ruby, I began to value the idiom of passing control back and forth using blocks and yield. You can do this in many languages - but for some reason it wasn't something I routinely did in C#.

The asynchronous nature of Javascript has awakened a part of my mind to evented programming. Again you can do this in many languages but it's idiomatic in Javascript and Node.

I can "think" in these terms and solve problems in ways I could never do when I knew only one language well (C#). At the time I liked the idea of "going deep" - of knowing a language so thoroughly that I could solve any problem with it and not clutter my mind with the different syntaxes of other languages.

I'm glad I didn't. And listening to that Radiolab podcast this last weekend made me understand why. I used to think it was that learning new languages would help me "think differently" but now I know it's more than that: I'm smarter now.

I'm not an egotistical guy and it hurts a bit to write that last paragraph - as if I'm suggesting that I'm smarter than people who know only one programming language - which is clearly not true. My point is only that I'm smarter than I was 4 years ago and the reason I think that is because I can solve problems in more ways than I could before and if my definition of "intellect" is accurate...

... then yeah: I think it's OK to say I'm smarter than I was with respect to programming.

The thing I enjoy most about all of this is that I would never have thought about this until I heard that Radiolab podcast. They put the words to the very idea that words are our higher reasoning.

A lovely bit of recursive fun.

Would I have recognized that recursion a few years ago? Hmmmm....

Vim: The Alpha and Omega

2013-04-28T10:00:00-05:00

I love experimenting with text editors and occasionally IDEs. In the last 6 months I've used no less than 5 different ones... each time I learn just how valuable Vim is to me.

image from http://jonathanpberger.wordpress.com/2011/02/06/vi-tutorial-for-dvorak-typists/

Skillz

Consider: if you're a coder you type for a living. Code, email, docs - whatever. One of the biggest efficiency gains you can achieve is to become a faster editor. This is what Vim does best: help you edit Faster, Better, Stronger - and you can carry these skills with you to almost any editor available today.

Notice I didn't say that Vim makes you a "faster typer" - no a faster Editor. Modern IDEs have focused on that of late - and no one is better at it than JetBrains.

For the last 4 months I've been using RubyMine and WebStorm and have fallen in love with them. WebStorm especially - if you're a Javascript person (Node or whatever) - it's a great deal at $49.

I'm not an intellisense person (since moving my focus away from .NET) but I do find it extremely helpful when working with new libraries. For instance: the Angular plugin for WebStorm helped me explore many of the "ng-" tags that I would not have seen otherwise.

In the Tekpub Angular Series I've been using WebStorm exlclusively and I've really enjoyed it.

Both RubyMine and WebStorms have interesting navigation schemes (I think this extends to Resharper for VS too):

Cmd-O allows you to search by a class name
Cmd-Shift-O allows you to search by file name
Cmd-Option-O allows you to search by symbol (a method name, for instance)
Cmd-B takes you to a class or method declaration directly
In the gutter of a Rails project are "go to view" (when you're in a Controller) and "go to Controller" when you're in a view
Cmd-E opens a popup of recently edited files

Really helpful stuff. In addition there are some great inspection features that offer "squigglies" (as Hanselman calls them) when methods aren't found, script files don't exist, etc. If you trust it - the editor will also give you refactoring options for your code...

These are helpful features - but are they helping me edit code faster? In some ways yes... in other ways...

Enter Vim

Rob Ashton was out here in Hawaii visiting recently and he is a devoted Vim user. I was showing him WebStorm and all the neat things that go with it - but both of us agreed that we could code faster in Vim.

Note: I know there are Vim plugins for JetBrains bits (and most other IDEs) - I'll get there.

While recording a video for our upcoming "Career Reboot" production at Tekpub, I asked Rob "what tools do you take with you while you hop the globe, journeyman coding"?

For the last year or so Rob has been travelling the planet, working on various projects for a few weeks at a time. His experiment was a simple one:

Pay for my travel, lodging and food and I'll do the work for free

With him was a single bag for his clothes and a backpack with 2 computers. He gave up his house and all of his furniture and put a few small things in storage and then set out - ending his journey here in Hawaii.

His work was varied and he wasn't sure for than a month at a time where he'd be next. Aside from the practical aspect - how do you prepare your machine for working in projects ranging from .NET to C++, Ruby to JavaScript. Rob hate's VMs as well - preferring to work on the native OS.

He has one Windows Machine and one Mac. He wiped OSX off his Mac, however, and installed Ubuntu...

So what does Rob rely on for writing code?

Vim

For much of the code he writes, Vim will suffice, everytime. He can load up any set of plugins he needs to write effectively in Ruby, Javascript or Python. He knows the commands well and to watch him use the editor is a fascinating treat.

When working in Visual Studio, he uses the VsVim plugin and, according to him:

If I didn't have these Vim plugins for VisualStudio I'd be screwed

Most IDEs have a Vim "overlay". All of the JetBrains IDEs do, and so does SublimeText and ... well just about any editor you can think of.

Vim, Everywhere

In terms of editing code, Vim won. The eternal Vim/Emacs war will rage on forever - but I don't think anyone can argue that, in terms of pure editing power: Vim does what it does, extremely well.

From your new shiny Mac Air to the Linux box in the cloud somewhere: open the terminal and hit "vim" and it's likely there, ready to edit config files or code. Vim is the Alpha and Omega editor - the beginning and the end. Vim is everywhere.

So it's back to Vim for me. I like the JetBrains tools and I enjoy SublimeText 2 a lot... but I can move and edit in Vim at twice the speed.

You might be wondering: "why not just use a Vim plugin dude?"

The inspections, plugins and "helper" functions in the JetBrains tools are interesting and helpful, but they come at a price (to me). It slows down the IDE, slows down typing, and many times it offers things I just don't want (like spelling corrections in my HTML files).

Often-times I feel like I spent an increasing amount of time diddling with the IDE more than the code. Looking up shortcuts, setting up configurations for testing, running and debugging... when I know how to do this already without the slick interface.

I like a pretty coding surface. I appreciate clean font rendering and seeing a project tree with all my code files and a fast, fuzzy file-finding feature. And I can get all of that with Vim.

I proved that to myself yesterday when editing a Rails project. Leader-P brought up PeepOpen, "/mailto" took me to a broken mail link. "c4w mailto:support"and the broken email was fixed. RController pro[tab] and I'm editing the ProductsController...

My Vim-glee was broken, however, when I realized I had forgotten the syntax for ActiveRecords eager-loading feature (include, include?, includes). Uh oh.

Rob put it very well when discussing IDEs:

If a tool starts thinking for me, starts remembering the syntax that I need to write... I'll forget the code and start becoming reliant on that tool to do my work for me.

This has happened to me ... quite often. When I was working in .NET it was nearly impossible for me to free-hand (without intellisense) simple structures like lambdas or a generic class definition using an interface. It's a syntax-heavy language and I can see how intellisense helps you with it.

The thing you lose, however, is thinking in that language. When the syntax is ready in your brain, you can think in code and sidestep the translation through the editor.

This is where Vim shines most and languages like Ruby flex their expressive muscle. You think the code, Vim expresses it directly.

The best part? You don't need to be using Vim to use Vim. Drop a plugin in a JetBrains IDE or Visual Studio and you're off (if you need to use those tools for whatever reason).

You never know, one day you might need to work in Clojure in Vilnius...

Models and Services in Angular

2013-04-25T10:00:00-05:00

It can be confusing when trying to structure a client-side application, especially when it comes to separating models from controllers and services. Doing this in Angular means diving into some details.

Image from http://union-bulletin.com/news/2012/aug/03/one-part-science-one-part-excitement-equal-success/

What's a Model? What's a Service?

I read over a post by Joel Hooks today called Modeling Data and State in Your AngularJS Application and the idea was put forward that you can clean up your Controllers by (basically) using Angular's service as a model.

The idea is a good one: Clean Controllers are Godly Controllers but there's some confusion in the post that I think will end up spreading.

Straight up-front: All services (service(), factory(), provider()) in Angular are SINGLETONS. It's difficult under any circumstances to consider a Singleton as a model.

There are so many jargon-filled terms disseminated throughout different approaches to software design... but I think we can agree that a model is representative of data (as opposed to a Domain Model which is all of your stuff under a big umbrella).

In the post above, Joel has a list of authors and a quote from each one - a simple data structure:

var fowler = {
    name: "Fowler",
    quote: "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
},
twain = {
    name: "Twain",
    quote: "Why, I have known clergymen, good men, kind-hearted, liberal, sincere, and all that, who did not know the meaning of a 'flush.' It is enough to make one ashamed of one's species."
};

One might consider this list to be two instances of a single Model, Author:

var Author = function(atts){
  var self = this;
  var initialSettings = atts || {};
  //initial settings if passed in
  for(var setting in initialSettings){
    if(initialSettings.hasOwnProperty(setting))
      self[setting] = initialSettings[setting];
  };

  //with some logic...
  self.fullName = function(){
    return self.first + " " + self.last;
  }

  //return the scope-safe instance
  return self;
};

Translating this to Joel's code:

var fowler = Author({
    name: "Fowler",
    quote: "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
}),
twain = Author({
    name: "Twain",
    quote: "Why, I have known clergymen, good men, kind-hearted, liberal, sincere, and all that, who did not know the meaning of a 'flush.' It is enough to make one ashamed of one's species."
});

So far, so good. Unfortunately I think some confusion crept in - here is the full example of Joel's code for his authorListModel:

  angular.module('modelDemo').service("authorListModel", ['$rootScope', function($rootScope) {
      var fowler = {
              name: "Fowler",
              quote: "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
          },
          twain = {
              name: "Twain",
              quote: "Why, I have known clergymen, good men, kind-hearted, liberal, sincere, and all that, who did not know the meaning of a 'flush.' It is enough to make one ashamed of one's species."
          },
          //...

      this.list = [fowler, twain, poe, plato];

      this.selectedAuthor = null;
      this.setSelectedAuthor = function(author) {
          if(this.list.indexOf(author) > -1) {
              this.selectedAuthor = author;
              $rootScope.$broadcast('authorModel::selectedAuthorUpdated', author);
          }
      };
  }]);

In the first line we've told Angular that this function is to be used a Service. Services in Angular are Singletons - which can cause all kinds of interesting headaches if you treat that service as a Model.

In Joel's case there's nothing wrong with the code here - except that it's not a Model - it's a Service and before you think I'm nitpicking - Service, in Angular, has a very particular reason for existence and it's not this:

... the “M” in MVC, model classes encapsulate your application’s data and provide an API to access and manipulate that data. The other classes in your application will make requests of models via this API. When data on the model is updated, the model dispatches events that the other classes within your application can react to.

The definition is a good one - unfortunately the code that is being offered to support the definition is actually a Service, not a Model.

So What About a Model?

I get asked this a fair amount and my answer is typically:

Your model lives on the server

hat-tip to Steve Sanderson for this

This works in many ways: it frees you from duplicating code on the client and it keeps secret things secret (such as applying discounts to a shopping cart, etc).

But what about behavior on individual bits of data? Here's where things get interesting with Angular.

Let's say you use Angular's $resource to hook up to an Author resource in the sky somewhere:

var app = angular.module("authorApp", []);
var api = function($resource){
  this.authors = $resource("/authors");
}
app.service("Api", api);

You can use this in your controller like so:

app.controller("AuthorCtrl", function($scope, Api){

  //returns [{first : 'Mark', last : 'Twain', quote : '...'}]
  $scope.authors = Api.authors.query();
});

That will send a GET request off to "/authors" and return a promise that will provide some data on success. Angular works really well with promises so there's no more code to be written here - when the data shows up, it hits the $scope which is "bound" to the UI through ng-repeat and off we go.

But how can we use our Author prototype above? A number of ways - let's go through this...

The first way is to get away from using "service" and have a bit more structure with a factory:

var app = angular.module("authorApp", []);
var api = function($resource){

  var authorResource = $resource("/authors");
  var queryAuthors = function(next){
    //use a callback instead of a promise
    authorResource.query({}, function(results){
      var out = [];
      //Underscore's "each" method
      _.each(results,function(result){
          //using our Author prototype above
          out.push(Author(result));
      });
      next(result);
    });
  }
  return {
    authors : queryAuthors
  }
}
app.factory("Api", api);

A bit more code... but either way we can use it this way:

app.controller("AuthorCtrl", function($scope, Api){

  //returns [{first : 'Mark', last : 'Twain', quote : '...'}]
  Api.authors(function(results){
    $scope.authors = results;
  });

});

Now we have a nice array of Authors. But we've also bent Angular just a bit because we're thinking like Software Developers - expecting "behavior" like "fullName()" to be on our model.

If we take a step back and consider what we're doing here (instrumenting the UI) - that doesn't make all that much sense. Here's where Joel and I will increase our disagreement :) and maybe you'll think I'm a dope.

Domain vs. Presentation Concerns

What is the motive for using the Author prototype? Typically, when working with Single Page Applications it's something that relates to:

Code Reuse (Author might be reusable around the app)
Centralized Logic (fullName(), daysUntilBirthday())

I'm going to put forward a bit of a strong opinion: if it's not presentation-related, it doesn't belong here. Hopefully we can agree on this as, well, the page is all about presentation and while yes there's logic flying around - it's presentation logic!

Angular provides a better facility for this kind of thing: they're called filters. In Angular we can do this:

var fullNameFilter = function(){
  return function(person){
    //you can have some logic in here to introspect "person"
    //for "first" or "firstName" or whatever
    return person.first + " " + person.last;
  };
}
//add it to the app
app.filter("fullname", fullNameFilter);

In your code you can now ask for the full name like this:

<ul>
  <li ng-repeat="author in authors">{{ author | fullname}}</li>
</ul>

The really nice thing about this is that you can reuse these filters - in any project! Turning this back to Joel's post - can we solve the problem without introducing a new model/service?

I think so. In looking at the controller code that Joel wants to refactor, we see this:

$scope.list = [twain, fowler, poe, plato];

$scope.selectQuote = function(author) {
    $scope.selectedQuote = author.quote;
    $scope.selectedAuthor = author;
}

$scope.isSelected = function(author) {
    return author === $scope.selectedAuthor;
}

I can guess as to a few reasons why it exists - but I don't think it's going out on a limb to think Joel wants to indicate visually which author the user wants to know more about.

There are a number of ways to solve this - from drop dead simple:

<ul>
  <li ng-repeat="author in authors">
    <!--select the author, then set the class or whatever is needed. Yay dynamic languages!-->
    <input type='checkbox' ng-model='author.selected'>
    {{fullname | author}}
  </li>
</ul>

To a more advanced solution involving directives (which I'll sidestep for now - this post is long enough). My ultimate point is that we're in presentation land here and while it's tempting to put your engineering muscle to work, there's just no need.

Ember... What If (Part 1)

2013-03-23T10:00:00-05:00

The Ember guys are having a hard week. I promised Tom Dale I'd try and help by "arm-waving" an API together that I feel expresses a bit more about the main ideas behind Ember. It's Friday, I've had a beer or two... but I got inspired...

image from The Rusty Shield

Hello There!

Setting a happy tone immediately is job one, in my mind. When you add Ember to a page you want to know it's there, and it's ready for you. Moreover you want to get going writing some code!

Right now you're stopped immediately with script warnings about including Handlebars and jQuery (if you don't have them installed). Can we make that experience better?

Yes. Bundle them! Angular bundles jQlite, Ember should bundle Handlebars and the same library. If they can't do that (for whatever reason): tell me (using console.log):

Ember needs Handlebars and jQuery to run! You can download them directly or just use add these tags above the ember.js script tag:
<script src="http://cdnjs.cloudflare.com/ajax/libs/handlebars.js/1.0.0-rc.3/handlebars.min.js"</script>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>

How nice is that! I still like the idea of bundling, however.

Default App.

Ember is all about convention. Convention with naming, with various objects following MVC - what if we flexed that even more.

The assumption is this:

If you include Ember, you want to build a Javascript application

I think that's a pretty solid assumption. So let's turn this around - instead of writing this:

var App = Ember.Application.create()

Just make "App" exist already! We know that jQuery is a dependency - so go with it and load that statement up by default:

//Part of Ember.js
$(function(){
  if(!Ember.bootstrap){
    App = Ember.Application.create();
  }
});

This can be overriden (which keeps in the spirit of Ember) in a new method Ember.bootstrap:

Ember.bootstrap(function(app){
  Tekpub.MyApp = app;
  //config etc.
});

For me, 9 times out of 10 I'll just work with "App". No need to change things in my mind and if you need to - just run App.config(function(app){})" and change things in $(document).ready().

That Naming Thing

Right now there are a lot of concepts that hang loosely from a naming scheme. This is a double-whammy that I think makes Ember hard to use.

What if we reversed this entirely? What if we defined the "name" up front? Here's what the Index definition would be (it could easily be "Post" or something else):

App.Index = function(){
  //wrap the notion of an Index in a "Definition" object
  //this is clean, and in one place
  //the naming concerns are implied
  return {
    //all of the below is optional
    model : {
      //this is an Ember.Data thing
      //or I can override some methods using
      //my own Ajax stuff with jQuery
    },
    routes : [
      "/:thingy",
      "/stuff",
      "another-override"
    ],
    controller : function(model,routeParameters){
      //route params are available via route.thingy, etc
      //this function is optional and exists for you
      //created by Ember
      //this method is available in my view
      this.posts = function(){
        //fetch from the model and return the result
      }

      //another...
      this.comments = function(){
        //etc
      }

    }
  }
}

The view is just a script tag with the id "index" in keeping with the spirit of Ember. In the view I can use all the same templating and expect to use whatever method/data that I've declared on my controller.

The nice thing about this setup is that I'm using the model as a separate idea - it's not magically melded to my controller and it keeps the concepts a bit cleaner (to me).

Let's put the name first and formalize the overrides in a single place. This is how I think about things, at least, and it would be nice to see it all in one place.

A Little Help?

OK, You've installed Ember after reading a tutorial. You've seen a post with the API above and you want to get started writing some code.

Ember has created the App for you, but it doesn't have a View:

Ember is installed and ready to go! The first step is to create a view:
<script type = "text/x-handlebars" data-template-name='application'></script>

Put that tag on your page where you want to see your app.

Nice - you copy paste that into your HTML page, and the next thing you see is...

Hello, Welcome To Ember

This is your Index space and you can override me by defining an index template:

< script type="text/x-handlebars" data-template-name="index">

... and overriding App.Index:


App.Index = function(){
  return {
    //the code you see above
  }
}

You can read the Documentation on what this is here.

Not only did Ember create an App for us - it also created a default Index "space" if you will. That Index defaulted to a nice helpful message on what to do next.

Arm Waving

That's what this is. I might be completely crazy, I might utterly misunderstand what Ember is trying to do.

I'll tell you this, however: if this is the way Ember crafted their API, I'd love it..

So there it is! I like being constructive when I can - hopefully this helps the team :).

Hell... Is Other People

2013-03-22T10:00:00-05:00

Get up from your desk or chair or floor and go for a walk. Right now - I challenge you to do this. If you can walk through a crowded place - that's even better. Go by yourself, and soak it in... all of it...

image from venndiagrams.tumblr.com

Garrett Is A JERK

It's 7:40am and I'm sitting outside my office with a warm, steamy cup of my favorite roast from Hanalei Roasting company. It's the perfect shade of rich, deep oakey-brown that tells me I hit the right mixture of milk and sugar.

I'm looking over the hills from the upstairs walkway in front of my office door. Behind me, the door is open and work is waiting for me... in front of me the sun is poking through the golden morning clouds and the dew from the damp air is everywhere.

It's quiet, and I'm loving it. Until Garrett entered my life.

Well, it was Garrett's girlfriend, actually. It started with a low, shrill sound that came from around the parking lot. It was muffled somewhat but it sounded like someone in trouble. Naturally I looked around, thinking someone might need my help.

Then all of a sudden the volume increased dramatically as she got out of her car. She was in full hysterics, yelling into the phone about how Garrett was a FUCKING PIECE OF SHIT JERK ASSHOLE etc. etc.

She stood there for about 30 seconds in the parking lot that was filling with cars as people came to work. They walked past her, careful not to look.

After a while she slammed the door of her car and stormed upstairs. She works in the office next to mine. I decided to give her some space so I went inside and shut the door. She decided to stay outside and vent her rage over the entire parking lot, into the golden sunrise morning I was just enjoying.

She stayed there for 20 minutes, then went inside. I got to learn all about Garrett... who apparently is not a very nice person.

Yeah Yeah Yeah

4 weeks ago I took my family to Kalihiwai Beach where we like to go for barbeques with friends. It was a lovely night, the sun setting much the same way it comes up: golden light poking through swollen, puffed clouds full of warm rain.

6 of us were sitting around the tailgate of my truck, when right next to us pulls up a black Hummer with blinking blue lights underneath. It's a high-end "situational" rental car that is completely out of place here, on this beach in Hawaii. It's an LA ride that looks like the UFO it was apparently dropped from.

Out of the car comes a 30-something markety/dotcom guy. Thick glasses, tall and in shape. He's from LA - as am I - and we can smell it on each other. He tips his head back: "SUP".

We wave as he reaches back in his car and flips on, full volume, one of the worst remixes of one of the best Yeah Yeah Yeahs songs there is. He opens the door wide - the one that faces us. He then goes to the back door and does the same... and then turns it up with a remote control in his pocket. All... the way... UP.

My chest thumps as the bass booms from inside. Purple beat-lights glow with the pulse of this horrible song as the trees ring with the echo of cheesy synth loops.

He's 20 feet away from us. There are no other cars on this half-mile stretch of beach. He's got this song on a loop so it plays... continually.

As opposed to Garrett's girlfriend, we didn't stand for it long. My buddy's wife casually went over and asked them to shut the doors facing us and to ... maybe open the doors facing them (no, really). They did, but not without giving stink eye.

Bookended

At lunch 3 months ago I sat at a table with a friend from out of town and a couple proceeded to get into a fight next to us. The lady stood up to storm away but thought of something clever so turned around just on the other side of us and, snappily, and let him have it. A lovely insult about his new car, flying right over the top of our heads and into his anger-laden face.

He fought back, she stayed put. We're square in the middle. I sat back and just listened - turning my head as if at an emotional tennis match between the two. The guy looked at me as if to say "bug off", I shrugged with my hands in the air ("where should I go?")... and they went outside... glaring back at me on the way.

CONTEXT

So many people are absolutely, stunningly unaware about the little bubble that surrounds them, defined by their thoughts, emotions and words. An interesting (and at the same time scary) thing is that groups of us share these things together - and our bubbles grow as we join into a group.

We walk around like pachinko balls ... bouncing our bubbles off someone else's. They either repel, or like bubbles, can join and grow larger. You can manage this process.

In a room full of other people, you have to manage that bubble of yours quite methodically - especially when you're with a group of friends having what you think is a private conversation. It almost never is.

That person sitting next to you on the bus/train/plane speaking really loudly into their cellphone? The new parents involving the entire restaurant in the little game they're playing with little Dylan? Or maybe the person in the front of the line who just now thought about looking at the menu and deciding what to eat...

Awareness. A Good Thing.

Whatever you're saying, thinking, emoting - all of it is shared with the people around you to some degree - even if they can't directly hear you. We're a sensitive animal and have senses built into us forged by millions of years of survival, intellect, and cunning. To pretend that words alone define meaning is complete folly.

Joking with your friend in a room full of diverse people isn't necessarily harmful, until you become blind to your own context as each of the people in the above stories were. Sometimes it doesn't matter. Other times it does.

You might be sitting next to someone who's sitting on an emotional grenade. That clever little joke you just made? It could be about guns, politics, gay marriage... or dongles. Well it might set that grenade off.

Call it professionalism, politeness, or just Old Fashioned Decency - it's why these things exist: so we can get along and avoid atomic swarm tendencies.

Until another person welcomes you into their context - no - you're not free (socially speaking) to do as you please without consequence. As much as you might feel you're protected by law to walk naked down the street singing that horrid Yeah Yeah Yeahs remix - your actions have an effect (and consequence) with others.

The same goes for being upset. Be aware of yourself and just how angry you've become. Think about why, and remember you're in public, around strangers. Think about your actions carefully in the way that the people in the story above did not.

This doesn't simply sit along gender lines (saying There are Ladies Present is a bit off the mark to me - the issue could as well have been racial or religious). I prefer to think there are other people present.

The only way to truly avoid the hell that can be other people is to understand the power of your own presence. Believe that you do have an effect on others. Just make it a positive one always.

Ember: Baby Steps

2013-03-20T10:00:00-05:00

If you read my blog, you know I've been goofing around with quite a few Javascript libraries. Some are easier than others. This time, it's Ember's turn.

A Bit Steep

I figured it's about time to get constructive in terms of getting to know EmberJS. The only reason I haven't up until this point is that I've been very busy with Tekpub's Angular production.

So, today's the day. Let's get started.

Baby Steps

Getting Ember setup is frustrating. The Ember guides are focused heavily on concept, not utility. For instance - getting Ember to load (for the uninitiated) is a matter of refreshing until the errors go away. I'll save you that time :).

Kick open a console (if you're on Linux/Mac) or crack open VS/WebMatrix if you're on a Windows machine. We want a bare application here so let's start by creating a directory:

mkdir hello-ember
cd hello-ember

Now we're in our directory. Let's create the pages/directories we'll need:

mkdir js
touch index.html

The next step is to get the scripts we'll need. We'll need 3:

jQuery
Handlebars
Ember

Ember won't work unless you have all three of these. I like to use the jQuery CDN at Google, but you'll need to download Ember directly and also Handlebars. Put these files in your js directory.

Be sure to use the unminified version for development. This goes for any library you're learning - the unminified versions are easy to traverse if you have a debugger, and they typically have helpful debug statements built in.

Save these files in your js directory.

Let's add one more file where our application code will go:

touch js/app.js

Open up the index.html page and stub out our skeleton, with the script references in place:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Hello Ember</title>
  </head>
  <body>
    <div>
      <h1>Hello Ember</h1>
    </div>
  </body>
  <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
  <script type="text/javascript" src="js/handlebars.js"></script>
  <script type="text/javascript" src="js/ember.js"></script>
  <script type="text/javascript" src="js/app.js"></script>
</html>

Let's run this:

python -m SimpleHTTPServer

Things should be cycling on port 8000. If you're on Windows, just hit F5.

Now let's write some Ember code.

Step 1: The Application View

Up front: there's a lot of magic that happens behind the scenes with Ember. Just about any tutorial you read will spend 75% of the time explaining the concepts behind Ember, and 25% of the time on actually using it.

This can be daunting for people who "want to get a feel" (like me) and don't like sitting through conceptual lectures. I like to write code to understand a tool - so let's do that and I'll explain what I know along the way.

Open up js/app.js and create the Ember application:

var HelloEmber = Ember.Application.create();

We have an application, which is a lovely start. We need at least two more things before we know that Ember is even alive and running:

a View
a Controller

The simplest view to create is the overall application view - let's add that to our HTML page, removing the first-level headers:

  <body>
    <div>
      <script type="text/x-handlebars" data-template-name="application">

      </script>
    </div>
  </body>

This script tag is a Handlebars template. If you don't know what that is: it's just like an ERB template in Rails (or a Razor template in ASP.NET MVC) except it works with Javascript on the client.

Handlebars is pretty simple to use, and Ember extends some of its functionality to make it work happily with the Ember bits.

We've identified this template using data-template-name as being the main application viewport. Let's stick something in it.

Step 2: The Application Controller

If you're familiar with Rails-style MVC, well... forget it. There are many flavors of MVC and we'll be working with Desktop/Smalltalk-80 style here. This confused me greatly, and I still don't know how I feel about it, but it doesn't matter. This is the way Ember works.

In short: Controllers in Ember convey data to your templates.

To see this let's create our first Controller. Open up app.js:

var HelloEmber = Ember.Application.create();
HelloEmber.ApplicationController = Ember.Controller.extend({
  greeting : "Good Morning Starshine!",
  happyThought : "The Earth Says Hello!"
});

If you've used Backbone before, this will look very odd. I should also mention that using the ApplicationController like this is not a good idea - I'll fix it in just a second.

Let's update the view so we can see our data:

<body>
  <div>
    <script type="text/x-handlebars" data-template-name="application">
      <h1>{{greeting}}</h1>
      <h3>
        {{happyThought}}
      </h3>
    </script>
  </div>
</body>

If you're working in Chrome, make sure the console is open by using Cmd-Shift-I (or Ctrl-Shift-I in Windows). If you see any errors here, correct them. It's likely you might have a 404 reference to one of your script files, or you've put them in your page in the wrong order (use my code above for the right order).

If everything is working: refresh your page - you should see a nice, Wonka greeting.

Step 3: Conventions

Look back over what we've written. Nowhere did we state "get this template and render it this way". Instead, Ember used the name of our template and married it up with the name of our Controller - and it all just worked.

This is a key bit of understanding with Ember: Naming things properly is everything.

To see this, let's get out of working with our ApplicationController directly.

First, create a new Controller, we'll call it the "IndexController". Don't name it something else - IndexController is what shows by default:

var HelloEmber = Ember.Application.create();
HelloEmber.IndexController = Ember.Controller.extend({
  greeting : "Good Morning Starshine!",
  happyThought : "The Earth Says Hello!"
});

Now, let's update our view so that the application view doesn't have hard-coded values in it:

<body>
  <div>
    <script type="text/x-handlebars" data-template-name="application">
      {{outlet}}
    </script>
    <script type="text/x-handlebars" data-template-name="index">
      <h1>{{greeting}}</h1>
      <h3>
        {{happyThought}}
      </h3>
    </script>
  </div>
</body>

Refresh your page. You should see the same thing we saw before: a nice Wonka greeting. But what happened here?

Again: naming conventions at work. The ApplicationController is gone from our code, but it still exists "behind the scenes" as Ember created it for us. In the first example (where we worked directly with it) - you can think of that as "overriding" the ApplicationController.

The same goes with the IndexController. It was always there - but we didn't need it. In the second example we essentially "overrode" the IndexController and created a view for it.

The rendered view was then injected into the application view where {{outlet}} sits on the page. You can think of {{outlet}} in the same way that yield is used in Rails.

Step 4: Models and Routing

We've done some basic stuff here, let's explore the other parts of Ember. Once again, I'll keep it extremely simple.

In app.js, let's define a model. I'll do this by extending an Ember Object:

HelloEmber.Greeting = Ember.Object.extend({
  greeting : "Good Morning Starshine!",
  happyThought : "The Earth Says Hello!"
});

Update - this code has been changed based on feedback from Tom Dale and comments below.

Now, let's define a Route. Routes in Ember help to link models to Controllers:

//our app
var HelloEmber = Ember.Application.create({});

//our model
HelloEmber.Greeting = Ember.Object.extend({
  greeting : "Good Morning Starshine!",
  happyThought : "The Earth Says Hello!"
});

//our route
HelloEmber.IndexRoute = Ember.Route.extend({
  model : function(){
    return HelloEmber.Greeting.create();
  }
});

This is all the code you should have in app.js. Notice how we have no Controller? We don't need one. This is confusing, but let's make sure things are working - refresh your page and you should see everything working just fine.

Assuming that it is - what we have here is naming magic at work, again. We've always had an IndexRoute (Ember created it for us since we didn't explicitly declare one) - but this time we wanted to specify a model so we needed to use a Route.

I mentioned that the Route exists to marry up a Controller to a Model, but we have no Controller! This can be maddening: we do have a Controller, we just didn't have to write the code for it: Ember did that for us.

The Controller that Ember created (the IndexController) was associated to our Route because we kept with the Ember naming magic. That Controller took the model that was available on the Route and "grafted it" onto itself, making the data on the model available to our view.

Good Job!

If you've made it this far, you now know as much as I do. There's a lot happening in the background with Ember; the goal being that the Ember team wants to reduce the tedious "boilerplate" code you write with other frameworks, like Backbone.

This can be a neat thing, it can also be highly confusing if you don't know what's going on.

I encourage you to play around with Ember and Handlebars now that you have your footing. It's an interesting thought experiment that works well for many developers.

Note: I'm not an Ember expert by any stretch so if you've found any misstatements or silliness here, please do let me know and I'll adjust.

Convention Over Incantation?

2013-03-18T10:00:00-05:00

Convention over Configuration is now simply an assumed thing for modern frameworks - and this is (mostly) a good thing. Sometimes I wonder if it's being taken too far.

Conventions? Curations? Innovations?

Convention over Configuration is a "pull" - meaning that it's derived from practice. Conventions evolve and ultimately people agree on them… thus the term "convention".

Rails made use of this most profoundly when it was introduced. From Giles Bowkett:

When Rails first arrived, in many instances, it took the greatest ideas and most common use cases of Web development, streamlined them, simplified their developer interface, and repackaged them within cleaner APIs.

Rails also decided to innovate at the same time, and mixed together its conventions with its innovations. The results have been mixed (in my experience):

The Asset Pipeline was an interesting solution to a problem that I'm not sure many people had. I spent more time trying to get the thing to work as expected - and then finally tossed it.
I used CoffeeScript for a bit, but don't care much for it. This decreases the interest in the Asset Pipeline.
I like RSpec. I like Factories vs. Fixtures. I tend to completely replace the entire testing experience Rails.

These aren't complaints, really. Every framework you use needs to be modified to a degree to fit how you work - but I do agree with Giles' assertion:

it is literally impossible to impose a convention on a community. It is a contradiction in terms, Orwellian doublespeak, and the human-language equivalent of a syntax error.

For all of the syntax niggling, Rails still lets me do what I want/need to do so I'm a happy camper. I also think the "conventions" it once imposed are being tweaked by innovation and becoming something else.

Giles calls it "Curation over Configuration" and I think I agree with him.

Put Your Left Foot Here, Touch Your Nose, And…

It seems that most frameworks (of any kind) are beginning to follow Rails' example by introducing some level of Convention over Configuration. This is a great timesaver, unless there are no conventions to adopt.

Which is something I've encountered with EmberJS. No, I'm not going to rant on Ember - I'm still pursuing Trek's prediction:

@locks next post will be about @robconery's Road to Damascus Moment. ;)
— Trek Glowacki (@trek) March 10, 2013

I haven't given up on Ember - even though I said as much in my last post. Well it's partly because of my last post that I can't give up - it wouldn't be fair of me would it :).

As I dive into Ember more, however, I've begun musing on "conventions" in general:

Ember.js uses naming conventions to wire up your objects without a lot of boilerplate. You will want to use the conventional names for your routes, controllers and templates.

By "convention" the team means "prescription". This is important because there is no convention when it comes to Single Page Applications in the traditional sense of the word "convention". Their naming guidelines are prescriptive - and something more.

A lot of frameworks do this kind of thing: Rails, Django, ASP.NET MVC (and I'm sure many others) expect certain files (views, for instance) to be in a particular place (which you can usually override). I like this - it promotes consistency.

Ember takes this to a different level, however. If you name things a certain way you can benefit from background code generation:

One of the ways that Ember.js helps to minimize the amount of code needed and handle things for you behind the scenes is through naming conventions. The way that you define and name your routes (and resources) impacts the naming of your controllers, models, views and templates

At what point do we call these "Incantations" instead of "Conventions"?

The Light Isn't Blinding Me Yet

Again - not here to pick on Ember. Strong naming has been around for a while (though I'm not sure I've seen it trigger code generation) and, far from condemning Ember - I applaud the team for taking a bold step.

I'll admit that it's not immediately sitting right with me, but I'm going to give it time to see how hard it will be for the incantations to work their way into daily memory. I'll keep travelling the road... until I'm blinded by the light or... get delirious from the heat.

EmberJS Confuses Me

2013-03-06T10:00:00-05:00

I've been teeth-deep in Client-side Javascript frameworks over the last 4 months for Tekpub. This month is Angular, last month was Ember's turn and I gave up. It's the first time I've given up - here's why.

I Tried

Saying something confuses me is no great claim - many things do. It's entirely likely that I didn't study Ember long enough, or maybe I didn't give it the "time to soak in" that it deserved. Either way I punted on my efforts to bring an Ember title to Tekpub.

Normally I'd just go about my business and sidestep posts like this one - but today I had a conversation with Trek Glowacki (core dev on the Ember team) and he was confused as to my confusion. I offered to blog my thoughts - he couldn't understand the points I was making about my confusion.

So here's that post, stripped of hyperbole and "it's ON FIRE" statements. It's my honest take on this framework.

You Keep Telling Me It's MVC...

Yes, the concept of MVC has been contorted over the past decade as web frameworks have adopted it and massaged it to their own ends. What does this mean?

Controllers in web MVC have a very short lifespan, and there are a lot of them typically
Views dont' communicate directly to a controller - they have to use an intermediary layer in HTTP (headers, querystring, etc)
Models are injected into views by Controllers
Controllers don't command the views directly

In more classic MVC (aka "Desktop") your controllers are typically spun up when the app starts, and configured one time, right there. A controller's job is to command aspects of the view as data changes, and to change the model when things on the view happen that mandate it.

The model encapsulates the business logic for whatever its modeling, the view presents the data in a nicely formatted way to the user, and the controller sits between. I think we agree on this much - so what's the problem?

OK this is MVC as far as I have come to know it. There are lots of denominations I am sure - I have to think the church of MVC is about as crowded as the church of REST on any given holiday but there's room for all of us so let's move on...

Separation. Only Not.

In EmberJS, the controller's job is changed a bit:

A controller may have one or both of these responsibilities:

Representing a model for a template.

Storing application properties that do not need to be saved to the server.

Most of your controllers will be very small. Unlike other frameworks, where the state of your application is spread amongst many controllers, in Ember.js, we encapsulate that state in the router. This allows your controllers to be lightweight and focused on one thing.

For me, this is where the confusion begins. A controller proxies the model, and then exposes itself to the rendering engine so that the view can consume it (you may need to read that sentence twice). As a result, we have view code like this (this is Handlebars):

{{#each person in personController}}
  <h1>{{name}}</h1>
{{/each}}

This can be shorthanded to this:

{{#each controller}}
  <h1>{{name}}</h1>
{{/each}}

This is where I hit a conceptual wall. First: let me say that I'm not the best programmer in the world and I could be dead wrong on this. But as far as I understand it, this is about as tightly bound as we can make things.

As stated above, a controller "proxies" the model onto itself for use in the view. I'm trying my best to reconcile this with the notion that a controller (classically speaking) is supposed to ... well control the view. Here, it's not doing that.

If I'm not mistaken, the view is controlling the controller and the model is nowhere to be found. Well that's not true I spose: the model is the controller. Sort of. Well it's not literally the same thing in concept but in practice the controller and the model are one. Bound. Together. Tightly.

In Angular this separation is achieved by a "scope" object that is, basically, a vehicle of sorts that gets passed between the controller and the view:

var PersonCtrl = function($scope){
 $scope.people = [{name : "Rob"}, {name :"Mary"}]
}

In your view, you declare which controller you're using and then consume the information that's on the scope:

<div ng-app>
  <div ng-controller='PersonCtrl'>
    <ul>
      <li ng-repeat='person in people'>{{name}}</li>
    </ul>
  </div>
</div>

The downside to this approach is that your HTML is "compromised", if you will, and many developers don't like that. My thought is that it's already compromised using Handlebars so what's the difference here? Personally I have no issue using the ng-* directives. Some people do, and I respect that.

But let's get to the controller code. Notice that the $scope is injected? That's Dependency Injection at work and is a core concept in Angular which greatly helps testability.

Now you might be saying "but ROB! The controller is declared directly in the view! That's the same problem!". And that's true - until you loop in routing (below) and you can remove that directive since it's handled explicitly by routing:

<div ng-app>
  <ul>
    <li ng-repeat='person in people'>{{person.name}}</li>
  </ul>
</div>

In Backbone a view is created (optionally) with the model (or collection) that it needs for data. There are no controllers (classically) in Backbone - though you can surely wedge one if needed and have it deal with the view.

These concepts align with my understanding of MVC. Not the case with Ember - if anything it confuses me greatly.

Routes, Objects, and More Confusion

I can get past the controller issue - I'm not a purist and if there's a reason the team wanted it this way, then I believe them. It's Yehuda and I think Yehuda is a very nice and smart person (as is Tom Dale - the co-creator of Ember).

I respect these guys so much I want to be very careful to not suggest that they don't know what they're doing. As I keep saying: this is my confusion. I own it.

Which brings me to Routes. Here's one way to define a route using EmberJS that looks rather familiar:

App.Router.map(function() {
  this.resource('posts', { path: '/posts' }, function() {
    this.route('new');
  });
});

Rails devs will recognize this straight away as a Resourceful Route. But what does a "resource" have to do with a Desktop app? When talking routes, urls, and resources - that's a RESTful consideration and involves stateless state "stuff" (sidestepping the REST debate here). What is this concept doing in a desktop app?.

Here's another way to define a route:

App.Router.map(function() {
  this.route("about");
  this.route("favorites", { path: "/favs" });
});

This is straightforward. Client MVC apps can manipulate browser history with "hashbang" URLs for bookmarking convenience. To manage that, we use a router and define routes.

And if you know that Ember relies heavily on naming conventions you could probably assume that you'll need an AboutController and a FavoritesController (like Rails - and Yehuda is a Rails core dev too so it would make sense...).

But that's not quite what needs to happen. You need to also define a RouteObject (which you can think of as a route handler):

App.FavoritesRoute = Ember.Route.extend({
  model: function() {
    return App.Favorites.find();
  },
  setupController: function(controller, model) {
    controller.set('content', model);
  }
});

I've been repeatedly told that "Ember uses MVC in the classical Desktop way" following Cocoa/Smalltalk style. OK I can buy that - but if that's the case why are controllers being tied to routes and models, conceptually? That might make sense for the web, but hardly for a desktop app.

Now I completely understand that we can throw theory at this and that Smalltalk-80 MVC was instrumental in forming the concept behind Ember.

But even then - one model could be used in many controllers (and the reverse) depending on the need. I'm happy to shift my mind into Desktop mode - but it seems Ember still wants to retain some conceptual likeness to Rails, which I find most ... strange.

I remember watching Geoffrey Grosenbach explaining this in Peepcode's very well done video tutorial on EmberJS and feeling rather confused. I rewound the section and played it back, to see if I could understand what I was seeing.

And rewound it a few more times after that. It wasn't sinking in. I could not understand the difference between declaring a route, and configuring a RouteObject. Why not have the URL be a setting on the Ember.Route?

Now it could be that it was this way in the past - I've only gotten to know Ember 1.0 rc1 and I also know that the API changes rather dramatically from time to time.

But this is really confusing.

Here's how you do it in Angular:

//declare the app and any dependencies
var App = angular.module("App",[]);

//configure the app, injecting the Route Provider
App.config(function($routeProvider){
  $routeProvider
    .when("/about", {
      templateUrl:"about.html",
      controller : "App.AboutCtrl"
    })
    .when("/favorites", {
      controller : "App.FavoritesCtrl",
      templateUrl: "favorites.html"
    })
});

Angular's approach is interesting and somewhat "concept-y" if you're not familiar with Dependency Injection. Once you get past that (or maybe you love it already) it becomes straightforward to understand that "here's a route, use this template and this controller". This is straight up configuration: which is exactly what the method name is.

I love parity between method names and the code I'm writing.

Here's how you do it in Backbone:

App.Router = Backbone.Router.extend({
  routes: {
    "/about": "showAbout",
    "/favorites": "showFavorites",
  },
  showAbout: function () {
    //render the view, or call to a controller
  },
  showFavorites: function () {
    //render the view, or call to a controller
  },

The Router in Backbone is also a bit confusing - there's no doubt about it. It can quickly turn into a mess of configuration AND instrumentation - in other words doing a controller's job.

I think this is why the Ember team tried to separate the configuration of the routes from the route itself. But in doing so they marginalized the controller (which was their intent, if you read the controller's definition).

With Backbone I know what I'm getting into. I can use the Router as a controller (it used to be called that btw) and when things get a bit nuts, I can create a controller of my very own (or just use MarionetteJS that has this concept built in).

Naming

Ember relies heavily on naming conventions that must not only follow syntax guidelines, but also casing guidelines.

The reason for this is straightforward: Ember will generate code for you if you just need basic, boilerplated stuff, alleviating you from tedious coding which is rampant in other frameworks like Backbone.

The problem I have with this is that the relationship between things is in name only, and that seems like it's a rather brittle rule. It also tells me that I have to know the naming conventions as well as how to use the framework - which is fine, typically, as long as there's a big payoff.

And that's where I get stuck (again): what's the payoff, aside from implicit code generation, for following the naming conventions here?. Consider the routing code, above:

App.Router.map(function() {
  this.route("about", { path: "/about" });
  this.route("favorites", { path: "/favs" });
});

App.FavoritesRoute = Ember.Route.extend({
  model: function() {
    return App.Favorites.find();
  },
  setupController: function(controller, model) {
    controller.set('content', model);
  }
});

The only way I know that one thing depends on the other is by name. Now I know that should seem obvious and you might be thinking "well duh, Rob, that's the point!". Yes, but it's also a great way to have a highly confusing API.

What's the problem with something like this:

App.FavoritesRoute = Ember.Route.extend({
  url : {name :"about", path: "/about" },
  model: function() {
    return App.Favorites.find();
  },
  setupController: function(controller, model) {
    controller.set('content', model);
  }
});

This, to me, is a whole lot more apparent and I'm not reconciling functionality through a naming filter. For some that might be much easier than reading the code (or reading the tests) - to me it seems arbitrary and confusing.

You Asked, I Answered

In wrapping this up, I would like to say that I am writing this as a way to make my points a bit clearer to Trek as Twitter doesn't work well for this kind of thing. He didn't understand my confusion about Ember (specifically why I didn't think it aligned with my understanding of MVC) so I told him I'd write something that explained my confusion.

It would be easy to see this as "Rob ranting on Ember" and I'm sure it will be taken that way by many. Not my intent, really. I have 4 videos to edit in front of me, and a book to write. I took time out of my day to respectfully respond to the Ember team with my thoughts - even if they're not glowing and exciting with praise.

If Ember works for you I think that's great. It doesn't work for me.

Pair Coding With KnockoutJS

2013-02-21T10:00:00-05:00

I was lucky enough to get some help from Ryan Niemeyer (KnockoutJS core contributor) recently, and, like I do, I asked if I could record it. I love stuff like this: I need this to work well for the Real World, and I want to do it right.

An Expert at Work

Most of us can figure out what we're trying to do with a new toolset - it's all about reading the docs and playing around until the philosophy of the thing creeps its way in and the tool begins to fit our hand just a bit better.

Every now and again, though, you're reminded just how much you don't know. That was the case when I asked Ryan Niemeyer to take a look at the Knockout Cart that I open sourced from Tekpub's codebase. I was proud of that thing but I also knew it needed a little help.

As with so many things - I was in a hurry, it worked, I felt like it was a decent initial release, etc. Anyway, Ryan joined me and from that we have our latest video on Tekpub:

This one is wall-to-wall coding, and Ryan doesn't miss a trick. Great stuff, and I was happy to be a part of it! You can watch the whole thing up at Tekpub

Customer Service vs. Serving the Customer

2013-02-18T10:00:00-05:00

If you've ever sent a support email to Tekpub, you know I'm in the habit of asking questions. I think truly serving the Customer sometimes means asking questions, and sometimes even saying "No"...

May I Help You?

I receive a number of support emails during the normal work week. They are mostly technical ones about our streaming player or questions about our content. Occasionally requests for certain topics.

And then there are the requests for refunds. This happens rather rarely, but when they do I tend to take extra time with them. This tends to piss people off and typically I have to wade through a lot of back and forth before we get down to the problem.

The following really happened, and (as you might expect) I'm paraphrasing a bit - not revealing names:

Customer: "I don't find your service worth it and would like my money back."

Me: "Sorry to hear that! What's the problem"

Customer: "As I said I don't find value in your videos - can I have a refund or not? Is this going to be one of those things that I have to fill out some questionnaire or stupid survey. DUDE JUST CANCEL MY SUB"

So at this point I have a problem. Do I continue asking him about the problem or do I just refund him and remember that "The Customer is Always Right". What would you do?

One thing I know is that an unhappy customer, tended to correctly, will rapidly turn into one of your happiest customers. It's a gamble, especially when CAPS are invoked... but I pressed on.

Me: Listen I understand you're not happy but sometimes it comes down to knowing just a bit more about a problem and I can fix it - and often it makes people very happy. If you had the time to explain just a bit - I would really appreciate it. Your refund is on the way, by the way.

This is one of my standard responses. Typically (not always) I will send the refund immediately. Upset people tend to become less upset, and then answer your questions. In this case, it worked out really well:

Customer: Sorry I should be a bit more clear. I love your videos and they're really good, but I can't afford the service and I thought I could but I just lost my job and I need to pull things back in. I didn't mean to be insulting and I guess I'm a bit stressed out. Thanks for the refund and if I get another job soon I'll come back.

Me: No problem at all and thanks for letting me know this - it really does make a difference. XXXXXXXXX - that's a coupon for an Annual Subscription. Educating yourself will help find work and, if you want to pay me back, buy an annual for someone else.

Needless to say, the Customer was ecstatic and we solved the problem - something I would never have known about unless I pushed a little bit - pushed the Customer to let me help them.

I give stuff away constantly - especially to people who need it.

This Backfires

Just today - in fact it's the reason I'm writing this post - someone asked me for a refund. It was the first in 4 months and, as I do, I asked some questions first.

Many businesses adopt a "No Questions Asked" policy and I understand why - it's a blind guarantee and gives the appearance of standing squarely behind your product or service.

I find that this is short-sited but NOT because you shouldn't blindly guarantee your stuff, but it's more likely there's simply a misunderstanding happening, and you can FIX IT.

So anyway the Customer wanted a refund:

Customer: I want a refund for my monthly subscription because Pluralsight has more content than you.

Me: They sure do, but I can't guarantee our stuff against another company's. I do know you'll be happy with what we offer because it's quite good and I notice you've only watched half of a single episode of all of our stuff. Might I recommend you give it some more time?

Customer: I didn't ask you to guarantee Pluralsight - but you should do something to compare your stuff vs. theirs so people know the difference. Your refund policy states "... 'snip' ..." Thus I'd like a refund.

Here I have a problem. They haven't watched any of our stuff and are, essentially, having "Buyer's Remorse" as they saw more stuff at Pluralsight. And Pluralsight has a whole lot of stuff. Buyer's remorse and Pluralsight's catalog are not covered under our refund policy (as you can imagine) so...

If I keep pushing this angle, I'll lose. Pluralsight has an amazing library but there are differences in our content - I need to get that across as well as the main point: Why not have both!. It's $15 + $29 == $45/month. Think of what that means in terms of educating yourself and readying your career! Yet people scrutinize this expense as if it were some kind of luxury!

OK, so back to the matter at hand. How would you respond here? This is what I said:

Me: Our return policy covers what we create and if you don't like it, then yes we'll stand behind that. But you haven't tried it out yet and, forgive me if I'm misunderstanding here, you're asking for a refund because Pluralsight has more stuff.

I don't want unhappy customers and I'm sending your refund now - but when you get to Pluralsight you might not want to look at Lynda.com.

If you use Peepcode don't try CodeSchool or Treehouse. What you see as an advantage (more videos) is hardly a measure of the content (and its relevance to you). Either way, your refund is on its way"

I should have left that last part out. That was my ego, feeling bruised and frustration setting in because I felt that what they were asking for was not entirely fair.

And, as expected, the customer didn't like my response. Things started getting personal and I was told my Customer Service sucks (which wouldn't be the first time). The Customer ended things by saying "I was planning on coming back to Tekpub if I didn't like Pluralsight but... not with this Customer Service experience".

Which means I lose. Actually, we both lost because I don't think he'll have the same option at Pluralsight.

Turning It Around. Or Turning It Off?

I lost that battle because I tried to reason with someone who was unhappy - and that is almost always a bad idea. There are ways of asking questions that don't lead the Customer to believe they're being screwed or messed with - and I was trapped with this one.

They gave me money, and they regretted it even though they didn't even try what they paid for. To me, I was utterly convinced that if they tried our stuff, they'd love it and I kept trying to communicate that... but in the wrong way. I think I understand why many companies simply refuse to do refunds - it forces customers to consider a bit more carefully.

This is not to say that you shouldn't show Customers the door. I've had people (literally) try to extort me by "taking it to Hacker News" unless I refunded them for videos that my logs showed they were clearly sharing (multiple downloads to same IP over the period of a month). I asked them if it's OK to loop in their legal department, then I deleted their account and banned them.

There are some customers you need to cut loose - basically a No Soup For You policy. They exist, it sucks, and it spoils it for customers who aren't Out To Get Your (to-date that's happened 5 times and I'm not happy about it... but it needed to happen).

On the bright side, I've managed to turn unhappy customers into Big Fans about 85% of the time: simply by asking questions and trying to care instead of following some old-school, outdated tome.