Recent Posts

Inherited Initialization in Backbone

One of the niceties that Backbone provides is the ability to perform some level of inheritance in your Backbone objects. You can, for example, create 'base' models that provide some kind of functionality; perhaps they override the fetch method to match your API. Views can share similar functionality or use sub-views to share functionality across various pages.

Here's an example of an application that has two pages: a home page and a member's personal gallery page, might look like this. This uses Twitter's Hogan.js (essentially, mustache templates.) with Backbone code written in Coffeescript. Both render a photo gallery, based on a model consisting of a collection of photos.

App.Views.Home ||= {}

class App.Views.Home.IndexView extends Backbone.View
  template: HoganTemplates['photos/index']

  initialize: () ->
    @model.bind('reset', @render)
    @render()

  render: =>
    html = @template.render({ photos: @model.toJSON() }, { 
      photoGallery: HoganTemplates['shared/_photoGallery'],
    })

    @$el.find(".photoGallery").html(html)

    @$el.find('.photoGallery').flexslider();

App.Views.Members ||= {}

class App.Views.Members.GalleryView extends Backbone.View
  template: HoganTemplates['members/personalGallery']

  initialize: () ->
    @model.bind('reset', @render)

  render: =>
    html = @template.render({ photos: @model.toJSON() }, { 
      photoGallery: HoganTemplates['shared/_photoGallery'],
    })

    @$el.find(".photoGallery").html(html)

    @$el.find('.photoGallery').flexslider();

As you can see, they're almost the same thing. We can make a base class to inherit from, such as a GalleryView that sets up the initialize and render functions; but, that limits us from the ability to add custom initialize and render functions on our individual page views.

or does it?

With a little trick, you can have your initialize and eat it, too. You can call your ancestor's initialize function, and call your own function, at the same time with a code sippet that looks like:

(javascript)

this.constructor.__super__.initialize.apply(this, [options]);

(coffeescript)

super

And turn that initial code into this:

App.Views.Base ||= {}
class App.Views.Base.GalleryView extends Backbone.View
  initialize: () ->
    @model.bind('reset', @render)
    @render()

  render: =>
    @galleryView = new App.Views.Gallery.GalleryView({ model: @model, el: @$el.find(".photoGallery") })

App.Views.Gallery ||= {}
class App.Views.Gallery.GalleryView extends Backbone.View
  template: HoganTemplates['shared/_photoGallery']

  initialize: () ->
    @model.bind('reset', @render)
    @render()

  render: () ->
    html = @template.render({ photos: @model.toJSON() }, { 
      photoGallery: HoganTemplates['shared/_photoGallery'],
    })

    @$el.html(html)
    @$el.flexSlider()

App.Views.Home ||= {}

class App.Views.Home.IndexView extends App.Views.Base.GalleryView
  template: HoganTemplates['photos/index']

  initialize: () ->
    @render()
    super

  render: =>
    html = @template.render({ })
    @$el.html(html)
    super

    @$el.find('.photoGallery').flexslider();


App.Views.Members ||= {}

class App.Views.Members.GalleryView extends Backbone.View
  template: HoganTemplates['members/personalGallery']

  initialize: () ->
    @render()
    super

  render: =>
    html = @template.render({ })
    @$el.html(html)
    super

    @$el.find('.photoGallery').flexslider();

Super calls it's ancestor's functions. Once the base template is rendered, it calls the base view's, which builds a gallery and sets it up as a slider.

Neat!

Wrap Lines in Vim

If you search for things like 'how to wrap lines in vim', 'line wrapping vim', '80 characters vim', etc, you will often find people saying ':set textwidth=XX'.

But if you want to break, say, selected lines - or if this just plain doens't work for you, try this: !fold -w##. Add -s on the end to break at words. To, for example, select text and wrap it at 80-line sentences, breaking at words, you would select the text and use !fold -w80 -s.

Magic!

Your Most Valuable Asset

Your most valuable asset, as an engineer, is not your particular set of skills, however specialized. It is the combination of your skills and experience that put you at a unique position to be able to deliver innovative concepts.

An engineer who knows Ruby, Python, and Javascript is an entirely different developer than an engineer who knows C#, Java, and Javascript, even when coding in the same language. Both have relevant experience; both may be the best in their fields. A team, however, is made up of both; conflicting and harmonizing experiences which can merge together to forge something that can take the best of all. Likewise, the engineer who has a degree in Chemistry and who does 3D art on the side, and the engineer who has an MBA and is just learning to develop can join the team and offer further, unique perspectives on software development. The young mind is as important to the team as the veteran. Without different personalities, different points of view, the team simply marches on without anyone to challenge assumptions. It's easy to fall into a trap of comfort and assumptions, and that trap is the hardest to get out of.

This doesn't just apply to engineers, although engineers are what I have the most experience with. I see the same thing in all facets of a company. A company without innovation is a company that is waiting to be destroyed, which cannot adapt to new situations, and must maintain the status quo and hope for the best. It won't be long until that status quo is disrupted by someone who can innovate, by someone who knows innovation means they can take the undeserved, underserved customers and build something new.

A homogonized culture is the death of a company.

Redesign

About two months ago, I wrote about ditching Twitter Bootstrap. I had put up a temporary design that was, more or less, a clone of my existing Bootstrap site; brown instead of black and white, but more or less the same. I've decided to revisit some of my decisions, such as the use of a grid system and roughly applied CSS and remove some of the unnecessary stuff.

This new design, then, has much less complexity; it sticks with a very limited palette and uses typography better to set the feel of the site.

The Big Picture

I had written a post a couple months ago, stressing the importance of semantic HTML. I feel good about that article, but I had originally meant to write more about the importance of progressive enhancement. Today, while I was reading an article by Bruce Lawson where he posted a list of interesting articles as he is wont to do, the last article really grabbed my attention. It opened with:

It seems to me that we are slowly switching from publishing content for the Web, to making content accessible to Screen-Readers (SR) - from targeting users, to focusing on devices and modern browsers.

We seem to be in the exact same prediciment that caused the stagnated IE: we're targetting specific browers, even when we have the tools, knowledge, and more importantly foresight to be better than this. To be better than building "Webkit only" sites. I highly suggest that you read it here.

If you want to find out more about progressive enhancement, check out Designing with Progressive Enhancement by the excellent people at Filament Group.

Don't make the mistakes of the past.

<< View Older Posts