The first online session of the 2014 Ontology Summit on “Big Data and Semantic Web Meet Applied Ontology” takes place today (Thurday January 23) from 12:30pm to 2:30pm (EST, UTC-5) with topic Common Reusable Semantic Content — The Problems and Efforts to Address Them. The session will include four presentations:

• Gary Berg Cross, Use and Reuse of Semantic Content: The Problems and Efforts to Address Them – An Introduction
• Pascal Hitzler, Towards ontology patterns for ocean science repository integration
• Andrea Westerinen, Reuse of Content from ISO 15926 and FIBO
• Megan Katsumi and Michael Gruninger, Reasoning about Events on the Semantic Web

followed by discussion.

Audio connection is via phone (206-402-0100, 141184#) or Skype with a shared screen and participant chatroom. See the session page for more details.

Function binding is most probably your least concern when beginning with JavaScript, but when you realize that you need a solution to the problem of how to keep the context of this within another function, then you might not realize that what you actually need is Function.prototype.bind().

The first time you hit upon the problem, you might be inclined to set this to a variable that you can reference when you change context. Many people opt for self, _this or sometimes context as a variable name. They’re all usable and nothing is wrong with doing that, but there is a better, dedicated way.

Jack Archibald tweets about caching this:

Ohhhh I would do anything for scope, but I won't do that = this

— Jake Archibald (@jaffathecake) February 20, 2013

It should have been more apparent to me when Sindre Sorhus spelled it out:

@benhowdle $this for jQuery, for plain JS i don't, use .bind()

— Sindre Sorhus (@sindresorhus) February 22, 2013

I ignored this wise advice for many months.

What Problem Are We Actually Looking To Solve?

Here is sample code in which one could be forgiven for caching the context to a variable:

    var myObj = {
    
        specialFunction: function () {
    
        },
    
        anotherSpecialFunction: function () {
    
        },
    
        getAsyncData: function (cb) {
            cb();
        },
    
        render: function () {
            var that = this;
            this.getAsyncData(function () {
                that.specialFunction();
                that.anotherSpecialFunction();
            });
        }
    };
    
    myObj.render();
    

If we had left our function calls as this.specialFunction(), then we would have received the following error:

    Uncaught TypeError: Object [object global] has no method 'specialFunction'
    

We need to keep the context of the myObj object referenced for when the callback function is called. Calling that.specialFunction() enables us to maintain that context and correctly execute our function. However, this could be neatened somewhat by using Function.prototype.bind().

Let’s rewrite our example:

    render: function () {
    
        this.getAsyncData(function () {
    
            this.specialFunction();
    
            this.anotherSpecialFunction();
    
        }.bind(this));
    
    }
    

What Did We Just Do?

Well, .bind() simply creates a new function that, when called, has its this keyword set to the provided value. So, we pass our desired context, this (which is myObj), into the .bind() function. Then, when the callback function is executed, this references myObj.

If you’re interested to see what Function.prototype.bind() might look like and what its doing internally, here is a very simple example:

    Function.prototype.bind = function (scope) {
        var fn = this;
        return function () {
            return fn.apply(scope);
        };
    }
    

And here is a very simple use case:

    var foo = {
        x: 3
    }
    
    var bar = function(){
        console.log(this.x);
    }
    
    bar(); // undefined
    
    var boundFunc = bar.bind(foo);
    
    boundFunc(); // 3
    

We’ve created a new function that, when executed, has its this set to foo — not the global scope, as in the example where we called bar();.

Browser Support

As you can see, unfortunately, Function.prototype.bind isn’t supported in Internet Explorer 8 and below, so you’ll run into problems if you try to use it without a fallback.

Luckily, Mozilla Developer Network, being the wonderful resource it is, provides a rock-solid alternative if the browser hasn’t implemented the native .bind() method:

    if (!Function.prototype.bind) {
      Function.prototype.bind = function (oThis) {
        if (typeof this !== "function") {
          // closest thing possible to the ECMAScript 5 internal IsCallable function
          throw new TypeError("Function.prototype.bind - what is trying to be bound is not callable");
        }
    
        var aArgs = Array.prototype.slice.call(arguments, 1), 
            fToBind = this, 
            fNOP = function () {},
            fBound = function () {
              return fToBind.apply(this instance of fNOP && oThis
                                     ? this
                                     : oThis,
                                   aArgs.concat(Array.prototype.slice.call(arguments)));
            };
    
        fNOP.prototype = this.prototype;
        fBound.prototype = new fNOP();
    
        return fBound;
      };
    }
    

Patterns For Usage

When learning something, I find it useful not only to thoroughly learn the concept, but to see it applied to what I’m currently working on (or something close to it). Hopefully, some of the examples below can be applied to your code or to problems you’re facing.

Click Handlers

One use is to track clicks (or to perform an action after a click) that might require us to store information in an object, like so:

    var logger = {
        x: 0,       
        updateCount: function(){
            this.x++;
            console.log(this.x);
        }
    }
    

We might assign click handlers like this and subsequently call the updateCount() in our logger object:

    document.querySelector('button').addEventListener('click', function(){
        logger.updateCount();
    });
    

But we’ve had to create an unnecessary anonymous function to allow the this keyword to stand correct in the updateCount() function.

This could be neatened up, like so:

    document.querySelector('button').addEventListener('click', logger.updateCount.bind(logger));
    

We’ve used the subtly handy .bind() function to create a new function and then set the scope to be bound to the logger object.

setTimeout

If you’ve ever worked with templating engines (such as Handlebars) or especially with certain MV* frameworks (I can only speak of Backbone.js from experience), then you might be aware of the problem that occurs when you render the template but want to access the new DOM nodes immediately after your render call.

Suppose we try to instantiate a jQuery plugin:

    var myView = {
    
        template: '/* a template string containing our <select /> */',
    
        $el: $('#content'),
    
        afterRender: function () {
            this.$el.find('select').myPlugin();
        },
    
        render: function () {
            this.$el.html(this.template());
            this.afterRender();
        }
    }
    
    myView.render();
    

You might find that it works — but not all the time. Therein lies the problem. It’s a rat race: Whatever happens to get there first wins. Sometimes it’s the render, sometimes it’s the plugin’s instantiation.

Now, unbeknownst to some, we can use a slight hack with setTimeout().

With a slight rewrite, we can safely instantiate our jQuery plugin once the DOM nodes are present:

    //
    
        afterRender: function () {
            this.$el.find('select').myPlugin();
        },
    
        render: function () {
            this.$el.html(this.template());
            setTimeout(this.afterRender, 0);        
        }
    
    // 
    

However, we will receive the trusty message that the function .afterRender() cannot be found.

What we do, then, is throw our .bind() into the mix:

    //
    
        afterRender: function () {
            this.$el.find('select').myPlugin();
        },
    
        render: function () {
            this.$el.html(this.template());
            setTimeout(this.afterRender.bind(this), 0);        
        }
    
    // 
    

Now, our afterRender() function will execute in the correct context.

Tidier Event Binding With querySelectorAll

The DOM API improved significantly once it included such useful methods as querySelector, querySelectorAll and the classList API, to name a few of the many.

However, there’s not really a way to natively add events to a NodeList as of yet. So, we end up stealing the forEach function from the Array.prototype to loop, like so:

    Array.prototype.forEach.call(document.querySelectorAll('.klasses'), function(el){
        el.addEventListener('click', someFunction);
    });
    

We can do better than that, though, with our friend .bind():

    var unboundForEach = Array.prototype.forEach,
        forEach = Function.prototype.call.bind(unboundForEach);
    
    forEach(document.querySelectorAll('.klasses'), function (el) {
        el.addEventListener('click', someFunction);
    });
    

We now have a tidy method to loop our DOM nodes.

Conclusion

As you can see, the .bind() function can be subtly included for many different purposes, as well as to neaten existing code. Hopefully, this overview has given you what you need to add .bind() to your own code (if necessary!) and to harness the power of transforming the value of this.

(al, il)

© Ben Howdle for Smashing Magazine, 2014.

In a previous article, I wrote about design before computers became commonplace in the design industry. A fun look back at the days of toxic chemicals and scalpel-sharp cutting tools.

The number of social media shares and tweets showed people were either nostalgic about those days not so long gone by, or fascinated by the process involved in non-electric designing. Where, however, has the computer led us? Is it a slice of Heaven or does it byte?

I was a student of some incredible designers, but Milton Glaser, whose course I admittedly never finished, still stands out in my mind. He was not a proponent of computers for design and while we young designers using computers with Photoshop 1.5 (2.0 had LAYERS!) were confused by his dislike of computers, reasoning they were faster and cheaper for design production, he stood fast. It caused us to suspect his teaching was obsolete. I hope Milton forgives me for that statement as I was young and foolish.

Years later I was reading a blog rant where some designer was blasting Glaser for saying something about the computer being to design as a microwave is to gourmet cooking. Ah-HA! That’s when it hit me. Milton, more mumbling about his dislike of computers, truly saw the future of design. He just didn’t put it in a way that made sense. A quote with a moral or haiku would have been nice!

The biggest change

Unfortunately for Glaser’s comparison, there are too many people who actually believe that a gourmet meal can be cooked in a microwave in just four minutes. There are also those who believe having Adobe CC is as good as a diploma from design school. How did Glaser see it so soon as the technology was so young? Was it the students who floated past him in his class? Every student had to show him a portfolio to be accepted into his class. Once class started, it was obvious he was really casting a season of The Real World: Art School. 

I guess he just knew what the computer, as a tool, would mean to design. It was a crutch for those who couldn’t keep up with the pack. While devotees of Leonardo are practicing drawing perfect freehand circles, there are others who create a perfect circle with a click. Is one person obsolete? Is another person using technology to their full advantage? Is one person right and another wrong?

There is no denying that the current state of personal technology has brought design tools into the hands of the public. From pre-school drawing games and puzzles to the functions adults use to make birthday announcements and garage sale flyers, everyone has seen that design is easy and we are overpaid jerks.

There are those who study the functions of software, skipping color theory, typography, design history and other classes forced upon art students with the purpose of knocking pre-conceived notions out of near-empty heads so they can absorb lessons on creativity and explore the possibilities of design, and they still consider themselves “designers.”

The biggest gain

I’ve always had a terrible eye for right angles. I can’t center anything and using one of those clear blue rulers with picas to inches and everything in between, just never worked for me. Anything that was being used as the layout board that had a grid printed on it (which were most boards), was my only chance at surviving those few years before the computer became my eyes and shaking hands. I blame the chemicals.

The layout functions of design programs have made it a breeze to pump out an entire publication. As I worked for a large publication as the computer age washed over us, I saw it not only cut production time in less than half the time, but the cost savings on production were over half of previous costs.

The personal computer, aside from having the digital age blamed for the slaughter of print, brought about a financial boom for the world. Complain as we might about bidding and crowdsourcing sites, they gave designers throughout the world a chance to compete for work not available in their locale.

It gave small businesses a tool to succeed globally via the internet. Suddenly the world was a possible customer.

Through software, half the administrative chores that bogged down sole proprietors is now automated.

More millionaires are emerging from internet/computer based businesses.

Computers are great for pranking coworkers and destroying the lives of your enemies.

With the number of desktops, laptops, tablets and mobile devices, the world has become connected. We get real news taken on camera phones, meet people in different countries and different cultures on Facebook, Skype and foreign bride sites. Every day the world gets a bit smaller while we learn more and more about each other. That’s a positive thing!

Opportunities abound

Need we talk about the market for apps? It’s not just about coding, it’s also about creativity. The idea, the need and the fulfillment are always driven by creative problem solving.

Other creative projects can be produced over the internet as well as marketed and sold. The options for people to be their own boss, control their own carer paths and steer their own futures is a great thing for creatives who can think of self-initiated, commercial projects.

Taking back design

Anyone can pick up a hammer but that doesn’t make them a carpenter. As creative thinkers, we must master the computer as a tool and apply different, better ways of designing with them. Whether it’s scanning objects for textures or elements of design, hand rendering type for a logo, or breaking rules when designing a web site.

Those who know the tool only for mechanical uses, will never measure up to those who know creative design thought, and can artfully apply it through such a cold, lifeless machine.

Design, of course, must evolve on its own. The tools will change but it is the creativity that will always be the foundation of design. For a while it was Photoshop filters that created the WOW! in design but it was those who mastered the filters and used them in different ways that really set the high bar for such design elements. Photoshop and Illustrator tips and tricks continue to amaze those who learn them and that is part of the evolution of design. In the end, however, we need less to learn about how to make the software work and more about how to make design work!

Was Milton Glaser right about computers destroying design? Has the computer helped or hurt the industry? Let us know your thoughts in the comments.

Images ©GL Stock Images

Mac Photo Bundle: 4 Popular Photo Apps – only $24!

Special Dates:

Wed, Jan 29^th  12-3pm Commons                   Involvement Fest

Wed, Feb 5^th 12-1pm Commons 327              Interest Meeting

Mon, Feb 10^th 7-9pm UC 312                         Tryouts, Learn

Wed, Feb 12^th 7-9pm UC312                         Tryouts, Perform

Practice Monday in FA306 pm from 7-9pm starting Feb 17^th –Apr 28^th 2014

Practice Wednesday in THAC119 from 7-9pm starting Feb 19^th- Apr 30^th 2014

One practice in February: Make scratch offs and set up fundraisers and bake sale date

Relay for Life Performance April 11^th as of now (tentative)

Possibly schedule to perform our routine at an elementary school

End of the year banquet/event: The weekend before the final week of classes. May 10^th or May 3^rd

Intel brings appMobi, their original XDK to end-of-life in about 5 weeks.