Learning CoffeeScript: use fat arrow => to ensure @ is the correct “this”

A project I’ve been working on has called for CoffeeScript so I’ve been diving into it. One quirk that happens with JavaScript is the scope of variables bound to the function() enclosing them. So what’s wrong with this?

class FooFoo
  constructor: ->
    @foo = 1
    @some_fn()
  some_fn: ->
    $('#some-button').click (ev) ->
      @foo += 1

That interior @foo inside some_fn() is going to have the wrong this when it compiles out:

var FooFoo;
FooFoo = (function() {
  FooFoo.name = 'FooFoo';

  function FooFoo() {
    this.foo = 1;
    this.some_fn();
  }

  FooFoo.prototype.some_fn = function() {
    return $('#some-button').click(function(ev) {
      return this.foo += 1;
    });
  };

  return FooFoo;
})();

So it’s the => fat arrow (hashrocket in Ruby terms) to the rescue. It creates a function-scoped _this and does the right thing inside now:

var FooFoo;
FooFoo = (function() {
  FooFoo.name = 'FooFoo';

  function FooFoo() {
    this.foo = 1;
    this.some_fn();
  }

  FooFoo.prototype.some_fn = function() {
    var _this = this;
    return $('#some-button').click(function(ev) {
      return _this.foo += 1;
    });
  };

  return FooFoo;
})();

Ah, much better.

JavaScript array indexing technique

You’ve probably heard of the Tron in 219 bytes which has the code:

<body id=b onkeyup=e=event onload=
  z=c.getContext('2d');
  z.fillRect(s=0,0,n=150,x=11325);
  setInterval("
    0<x%n
    &x<n*n
    &(z[x+=[1,-n,-1,n][e.which&3]]^=1)
      ?z.clearRect(x%n,x/n,1,1,s++)
      :b.innerHTML='game⬜over:'+s
  ",9)
><canvas id=c>

The part of this I really like is:

[1,-n,-1,n][e.which&3]

Because e.which&3 reduces the keystrokes (i, j, k, l) to an array index that is 0-3. That index then selects a value in the moves array: [1, -n, 1, n]. I’m thinking I’ll use this trick to say index into a set of stored numbers or something, even objects:

error_code = {
  "e100": "Error 1",
  "e200": "Error 2",
  "e300": "Some other error"
}['e' + code_number]

(You can’t begin a hash key with a number.)

Quick Thought: Browsing Rates of Photos vs. Videos/Music

Photos and videos are certainly crazy popular these days. It seems that everyone is posting, sharing, and commenting on them. And photo-centric startups are all the rage. While probably obvious, what’s interesting about photos is that it’s like reading: the viewer can digest the photos at their own rate. For videos (and music for that matter) the viewer is required to slow down and sync their experience with the playback of the video. In other words: photos don’t take time, videos/music take time.

I guess if you’re building a startup or project and you want the maximum amount of throughput you’d probably want to do the following:

  • Focus on photos.
  • Make the eye go mostly in a vertical pattern or at least a very short Z pattern (maybe no more than 1/3rd of the screen width).
  • Use space to clearly demarcate one item from the next.
  • Maybe use subtle colors for all information that isn’t critical to enjoying the experience of the photo, even smaller photo sizes.
  • Use information layers (i.e. you have to mouse onto the photo) to reveal more information.

 

Gist: Comparing Sass (SCSS) vs LESS

From 2011 but probably still pretty valid: https://gist.github.com/674726

Note: I’m using Sass and SCSS interchangeably here. The Gist was comparing SCSS vs. LESS.

Quick summary:

  • Very similar. Both awesome.
  • LESS does variable scoping, Sass doesn’t
  • Sass allows selector inheritance
  • Sass’ arithmetic is more flexible
  • LESS has a kind of namespacing
  • Defining variables:
    • Sass: $name: value;
    • LESS: @name: value;
  • Sass mixins are more explicit than LESS (or LESS’ mixins are more succinct):
    • Sass:
      @mixin foo { … }
      { @include foo; }
    • LESS:
      .some-class { … }
      { .some-class; }

Phew. Back!

Since copying 135 GB from one HDD to another takes quite a while, I had some time to try to fix the posts on this blog. Pretty much everything older than March 2012 needed to get reimported. Thankfully it wasn’t too much of a pain. What was a pain was reading the XML export of the old blog and looking for malicious code, URLs, and other weirdness. Hopefully I haven’t missed anything!