The toString conundrum

Last week, in the course of a technical job interview I was asked this question:

    How to make




The first part, chaining functions, is trivial. As you (should) know, you just need to return the object in each chainable method.

function Counter (numInitial) {
      this.counter = numInitial; = function (howmuch) {
            this.counter += howmuch;
            return this;

      this.minus = function (howmuch) {
            this.counter -= howmuch;
            return this;

To test this class in your browser you just need to instantiate it like this and then call the required methods:

test = new Counter(7)
> Counter {counter: 7, plus: function, minus: function, toString: function}

> Counter {counter: 9, plus: function, minus: function, toString: function}

Of course, the result is not the expected. The tester is asking for the code to return “9”, not the object. Fortunately, there are two methods in the Function() that we can override. These methods are used internally whenever JavaScript need to make a comparison, returning the native value of the Function().

// automatically called to return a String representation of our class

Counter.prototype.toString = function () {
      return this.counter;

Of course, you can define this method inside the original definition of the class. I’m just writing this way for you to copy and paste step by step in your browser’s console.

In any case, by overriding the toString method in our class we should get “9”, since console.log() is returning an String. But it doesn’t. It seems that console.log don’t use .toString or .valueOf in FireFox or Chrome. You should thinks of this as a bug, but if you think of it, the function of the console is to give us accurate information of the objects and variables we pass to it. Converting them would, most of the time, not desirable.

The way to really show that our code is working is to force it to return an String, by converting it before passing it to console.log().

// before overriding toString

console.log( + '')
> [object Object]

// after overriding toString

console.log( + '')
> 9

Monday Rant: del pago al contado y otras leyendas urbanas

Todo el mundo conoce el ¿chiste? del congreso internacional de contables donde el representante español alardea de la gran cantidad de formas de pago que conoce hasta que otro delegado le descubre una nueva: pago al contado. Esa leyenda urbana. Un sistema de pago desconocido en un país donde los primeros en estafar a los proveedores son los organismos oficiales, generando impagos porque ellos lo valen. Continue reading

What’s in an SPA? Part II, the A in SPA

As you may remember from the first part of this thrilling SPA saga, the only object I’ve invoked right now is the Application. What is this Application that everyone in the ‘hood is talking about?

For starters it should be your main dispatcher for all the objects in your application. Remember, we’re not doing a web page or a bunch of html files with some javascript, but an application. Think of it as of your safehouse. Whenever you’re lost (you shouldn’t but you will be) in the maze of your code you can reach up to your fair objApp variable and crawl down from it to known territories. For example, to execute the orderMoreTunnel() method of the Tunnel module. Continue reading

Lo que hay debajo

La mayoría de los frameworks modernos utilizan algún tipo de atributo añadido a los elementos para indicar como dibujar o que controlador asignar a dicho elemento. Por ejemplo, en jQueryMobile y en bootstrap se utilizan los atributos “data-“ para indicar roles, estilos, etc.; de la misma manera, en AngularJS se asignan atributos con el prefijo “ng-“ para asignar, por ejemplo, un controlador a un <div> concreto. No es la única manera de “dopar” la página; la mayoría de las librerías tienen métodos para aplicar un behaviour concreto a un objeto de nuestra página. Continue reading

Legacy code is dragging you down

Legacy is, usually, a nice word until you apply it as an adjective to your work. Then it becomes a hideous monster lurking in the shadows behind your compiler waiting to chop off your head. Or the performance of your app.

Let’s take an example: an app that uses some library directly ported from C# to JavaScript using the old method of running the code and modifying accordingly when the browser complains. Additionally the code has two different responsibilities and it’s not documented or even explained. The resulting library is slow. Specially for certain operations. And the project manager is complaining. Sounds like a dream job. Continue reading