Disorganized

Battle for the planet of the APIs

It might be that RSS is the canary in the coal mine for my data on the web.

If those services don’t trust me enough to give me an RSS feed, why should I trust them with my data?

Jeremy Keith complements Anil Dash’s The Web We Lost about the state of the open web, using the availability of APIs in general—and RSS in particular—as a litmus test.

Oh yeah: every WordPress blog comes with an RSS feed for free. Oh, and WordPress is free too.

Link
WordPress

Thanks WordPress

It’s tough to overstate the impact WordPress has had on my life. If it wasn’t for WordPress, I probably wouldn’t be working on the web, and I definitely wouldn’t be working for Automattic.

I’ve outlined my web development trajectory previously, so I won’t repeat those details here. What I do want to say is that I’m incredibly grateful to everyone in the WordPress community. To Matt and Mike, who started the ball rolling 10 years ago; to all the developers who’ve contributed; to all the unsung heroes in the forums; to all the theme designers who’ve made WP look a place we wanted to be; to all the bloggers graciously sharing their knowledge; to all the plugin developers making the ecosystem thrive, to everyone who’s been involved in ways that don’t quite fit into those categories: thank you, thank you, a thousand times thank you.

Standard
Web Development, WordPress

App Engine 1.8.0 is now available and includes a Limited Preview of the PHP runtime – your top requested feature. We’re bringing one of the most popular web programming languages to App Engine so that you can run open source apps like WordPress. It also offers deep integration with other parts of Cloud Platform including Google Cloud SQL and Cloud Storage.

This could be a big deal, especially if they build tools to make it easy to install WordPress on App Engine.

Google App Engine adds the PHP runtime

Quote

Just set up the umbrella. Gonna be out here a lot this summer.

Disorganized

Summer Office

Image
Web Development

JavaScript Context Confusion

Or: how I learned to stop crossing my fingers about this.

The mutability of this is one of the hardest things to understand when writing JavaScript (the other is prototypal inheritance). Callbacks make this especially confusing and easy to lose track of.

Here’s a fairly common (and over-simplified) pattern:

var module = {
  init: function() {
    // alias "this"
    var self = this;
    // attach event handlers
    $("#foo").on( 'click', function( event ) {
      // this.takeAction() would throw a TypeError since jQuery
      // makes "this" a DOM Element rather than "module"
      self.takeAction( event );
    });
  },
  takeAction: function( event ) {
    // I need to have (this === module) to work properly
  }
}

module.init();

The problem modular code runs into is that jQuery assigns this to be the DOM Element that was clicked on in the above example. This is good for writing typical jQuery spaghetti code, but not when we want more modular code. So we alias this to something like self or that to be used inside a nested function’s scope. ECMAScript 5 solves this problem with Function.prototype.bind, ensuring that a function is always called in a specified context:

var module = {
  init: function() {
    // attach event handlers
    $("#foo").on( 'click', this.takeAction.bind( this ) );
  },
  takeAction: function( event ) {
    // I need to have (this === module) to work properly
  }
}

// helpful here too!
$( document ).ready( module.init.bind( module ) );

Now, if you find yourself in a situation where you need contextual information from both the DOM Element and the this context bound via Function.prototype.bind, you’re probably doing it wrong. (And anyway, you can still grab it from event.target.)

It would be great if we could just code like this today, but Function.prototype.bind is only supported in IE >= 9. But this is a common problem, and most frameworks solve this in some manner.

// jQuery.proxy
var module = {
  init: function() {
    // attach event handlers
    $("#foo").on( 'click', $.proxy( this.takeAction, this ) );
  },
  takeAction: function( event ) {
    // I need to have (this === module) to work properly
  }
}

// _.bind
var module = {
  init: function() {
    // attach event handlers
    $("#foo").on( 'click', _.bind( this.takeAction, this ) );
  },
  takeAction: function( event ) {
    // I need to have (this === module) to work properly
  }
}

I would recommend, whenever possible, to use Underscore’s _.bind over jQuery.proxy, since the latter can create some oddness (see docs) when unbinding event handlers. Plus Underscore is awesome.

And now I have some old code to go cringe at.

Standard