Sunday, May 8, 2016

Cómo adquirir buenos hábitos y deshacerte de los malos

¿Quieres saber cómo puedes crear hábitos saludables y modificar hábitos perjudiciales de forma sencilla y eficaz? Aunque parezca complejo, la ciencia nos demuestra que es más fácil de lo que parece. Simplemente tienes que saber cómo funcionan los hábitos, cómo se crean y cómo se modifican. 

¿Quieres saber cómo? Sigue leyendo.

Qué son los hábitos



El cuerpo humano se compone de unos 650 músculos capaces de proporcionarnos el impulso necesario para realizar movimientos, siendo la mayoría de estos músculos son voluntarios. De esta forma, podemos conscientemente mover y coordinar cualquier parte del cuerpo para caminar, comer,  jugar al tenis o conducir un coche.

Imagina que estas comiendo un filete. ¿Serías capaz de indicar cómo se come un filete? Seguro que sí, ¿verdad?, simplemente indicarías algo como que con una mano coges el tenedor y con la otra el cuchillo. Mientras pinchas con el tenedor una zona del filete, con la otra mano acercas el cuchillo y cortas un trozo. A continuación, el trozo pinchado con el tenedor te lo llevas a la boca, masticas y lo tragas.

Aparentemente es algo muy sencillo, sin embargo, esta tarea implica la activación de muchos de estos 650 músculos que tienen que ir siendo contraídos y relajados de forma coordinada con una precisión realmente alta. ¿Serías capaz de indicar cómo se come un filete pero ahora señalando cada uno de los músculos que tienes que ir contrayendo y relajando? ¿Verdad que no? Esta tarea es realmente compleja. Ni siquiera eres consciente de qué músculos tienes que ir moviendo para aproximar la mano al plato, ni para sujetar el cuchillo ni el tenedor. Simplemente, estas acciones “te salen solas” sin que activamente estés pensando los movimientos.

Entonces, ¿por qué nos parece tan sencilla una tarea que realmente es extremadamente compleja?

La respuesta es porque la hemos convertido en un hábito y la hacemos inconscientemente de forma automática, y lo que es más importante, de forma extremadamente sencilla para nosotros. Es decir, no pensamos cómo hacerlo, simplemente lo hacemos, hemos automatizado el proceso de forma que nos sale sin el más mínimo esfuerzo mental. Es igual que conducir un coche, podemos ir conduciendo durante horas pensando e, incluso, visualizando cosas que nada tienen que ver con la conducción. Podemos ir pensando cómo será ese hotel al que nos dirigimos para pasar nuestras vacaciones con el máximo nivel de detalle sin que la conducción se vea afectada.

Por lo tanto, una vez convertidas en hábitos, tareas tan complejas como comer, conducir un coche o jugar al tenis pasan a ser acciones increíblemente sencillas que ni siquiera nos obliga a pensar.

Dicho con otras palabras, el cerebro de cualquier animal está constantemente tratando de trabajar menos.

¿Qué pasaría si esto no fuera así? ¿Cómo sería la vida si tuviéramos que ser conscientes de todos y cada uno de los movimientos que necesitamos para desempeñar día a día nuestras actividades? La respuesta es que difícilmente la vida sería posible porque el esfuerzo mental a aplicar en cada acción sería muy elevado, haciendo que la energía consumida por nuestro cerebro a lo largo de un día fuera excesiva y provocando que su tamaño fuera mucho mayor dificultando el nacimiento y aumentando las tasas de mortalidad de madres e hijos.

En definitiva, el cerebro funciona así porque trata de ser lo más eficiente posible.

Adquisición de hábitos


La facilidad de realizar tareas complejas no fue siempre así, nadie nace sabiendo comer, conducir o jugar al tenis. Al principio, en el momento del aprendizaje, estas tareas son muy complejas, el niño tiene que aprender a cortar y a introducir la comida en la boca sin que se le caiga. La persona que está aprendiendo a conducir se esfuerza muchísimo en coordinar los pedales y los movimientos del volante mientras activamente observa la vía, los demás coches y cualquier obstáculo que pudiera interponerse en su camino.

La clave está en que los hábitos, se adquieren mediante repetición. Es repitiendo las tareas una y otra vez cuando al cabo del tiempo, se automatizan y podemos llevarlas a cabo de forma fácil sin pensar.

Este procedimiento se puede medir en un laboratorio con ratones. Si se introducen ratones en un laberinto y colocamos chocolate al final del mismo, los ratones una vez escuchan una campana y se les deja libres, al principio se sienten desorientados sin saber qué hacer. Comienzan a oler el chocolate e intentan llegar a él a través del laberinto, consiguiéndolo al cabo de un rato. Si se mide la actividad cerebral de estos ratones, se observa que el cerebro está constantemente trabajando de forma activa desde que suena la campana hasta que consiguen el chocolate. Es decir, el ratón se esfuerza durante todo ese tiempo en conseguir llegar al chocolate a través del laberinto.

Cuando el ratón hace este ejercicio varias veces, cada vez lo hace mejor y más rápido. Lo curioso es que cuanto mejor lo hace, menos actividad cerebral se detecta,  es decir, el ratón está resolviendo el problema de forma más eficiente, consumiendo menos energía. Por lo tanto, el ratón ha convertido la rutina de resolver una y otra vez el laberinto en un hábito.

Podemos decir que un hábito se compone de tres pasos que tienen lugar dentro de nuestro cerebro:

·            Una señal que nos hace entrar en modo automático.
·            Una rutina que puede ser mental o física.
·            Una recompensa que le permite al cerebro determinar si merece la pena o no recordar este ciclo en el futuro.

El hábito se forma mediante la repetición frecuente de estos tres pasos. Por ejemplo, imaginemos que nunca hemos sido una persona que hayamos tomado postre en el almuerzo. Salimos de la Universidad y en el restaurante de nuestro trabajo lo que ofrecen es un menú del día que incluye postre. Conforme pasan los días, iremos adquiriendo el hábito de tomar postre de forma inconsciente. En este caso, la señal que nos hace entrar en modo automático es el hecho de almorzar, la rutina comer siempre postre porque viene incluido en el precio y la recompensa esa ingesta de azúcar que nos hace sentirnos más feliz después de la comida.

Una vez adquirido este hábito, cuando salgamos a comer a un restaurante, aunque no tengamos el postre incluido, tendremos inconscientemente la tentación de pedirlo. El motivo es que en el momento de producirse la señal, la acción de comer, estamos taurante, aunque no tenga men azun restaurante, aunque no incluya menene incluido en el precio y la recompensa esa ingesta de azdeseando sin ser conscientes el postre, lo que nos hace seguir la rutina de pedirlo.

Esto es lo que se conoce como “el ciclo de los hábitos”: una señal, seguida de una rutina y una recompensa.


Modificación de hábitos




Al igual que los hábitos se pueden crear, también se pueden modificar. Eliminar un hábito es una tarea extremadamente compleja. Una vez lo tenemos arraigado, en cuanto se produce la señal, automáticamente lo llevamos a cabo. Esto para los hábitos buenos es lo deseable a diferencia de para los malos hábitos. Sin embargo, el hecho de que sea muy complejo eliminar los malos hábitos no significa que esté todo perdido. Las investigaciones científicas muestran que aunque es muy difícil eliminar un hábito, es relativamente sencillo sustituir los malos hábitos por hábitos más beneficiosos. Simplemente se trataría de, ante una señal, encontrar una rutina más beneficiosa que nos provoque una recompensa igual o más deseada que la del hábito malo.


Imagina que cada día, después del trabajo, tienes la tendencia a sentarte en el sofá y pasarte el resto de la tarde viendo la televisión. Aunque esto en sí no tiene por qué ser un mal hábito, lo que sí que es cierto es que existen hábitos más saludables como salir a correr. ¿Qué podríamos hacer para sustituir el hábito de sentarnos en el sofá por el de salir a correr un poco?

Tal como hemos dicho, el ciclo de los hábitos lo componen tres pasos: una señal, una rutina y una recompensa. La señal está clara, llegamos a casa después del trabajo y tenemos que hacer algo. La rutina sería salir a correr. Y la recompensa tener mejor salud y una mejor figura. Sin embargo, en este caso y muchos otros, el hábito no se llega a adquirir. Solemos hacer esto unas cuantas veces pero normalmente siempre terminamos desistiendo. ¿Por qué? ¿Todo lo que hemos dicho es mentira? Por su puesto que no, el problema es que la recompensa es a muy largo plazo: “te sentirás mejor a la larga”, “tendrás una figura mejor dentro de unos meses”. Son recompensas que no son lo suficientemente cercanas en el tiempo para que cuando se produzca la señal, la estemos deseando y nos facilite realizar la rutina de salir a correr.

Afortunadamente, existe un truco extremadamente eficaz. ¿Por qué no nos damos una recompensa a corto plazo que, unida a la de largo plazo, nos motive a seguir la rutina? Si nos damos una recompensa a corto plazo, por ejemplo, nos decimos después de salir a correr me voy a tomar un helado, no demasiado grande, o voy a tomarme una chocolatina, cada vez que se produzca la señal, vamos a desear ese helado o esa chocolatina, y nos facilitará salir a correr.

Resumen

  • Los hábitos se fundamentan y se adquieren a través de lo que se denomina “el ciclo de los hábitos” que se compone de una señal, de un rutina y de una recompensa.
  • La repetición de estos ciclos es lo que hace que un hábito nazca
  • Los hábitos se puede crear, pero también se pueden modificar, habitualmente mediante sustitución de hábitos. Es decir, podemos crear hábitos buenos y sustituir hábitos malos.
  • La realización de la rutina se facilita al esperar a corto plazo una recompensa.

Convierte Edapty en un hábito, selecciona un momento del día, quizás cuando llegues del trabajo, unas de irte a la cama. Realiza los ejercicios que Edapty te propone en función de tus necesidades, sólo serán 10 o 15 minutos cada día. Espera tu recompensa, crecer personalmente, superar ese sufrimiento que te acecha o conseguir adquirir técnicas para tener mejores relaciones sociales.

Todo depende de ti, sea lo que sea, lo puedes conseguir, y Edapty está a tu lado para ayudarte a conseguirlo.

Referencia:

Charles Duhigg (2014). The Power of Habit: Why We Do What We Do in Life and Business. Random House Inc.


  

Saturday, May 7, 2016

Arqueología

Ayer tras una presentación se sorprendieron de que yo llevara 25 años programando.
Realmente, no llevo 25 años, llevo más de 25 años. Comencé a programar un MSX en Basic a los 11 años.

Ayer me puse a recuperar programas y juegos de la época y esto es lo que he podido recuperar.

Phatal Day 1994


Este juego, está programado en QuickBasic y Ensamblador (gráficos) e incorporaba varios aspectos técnicos que no eran habituales por la época: fundidos, scroll suaves, efectos acordeón, etc. todo ello interactuando directamente con la tarjeta gráfica a través de interrupciones. En esa época las tarjetas gráficas eran aún muy lentas y se podía ver cómo se iban dibujando poco a poco las ventana de Windows cuando se movían con el ratón.


Tetris 1993


Programado todo con QuickBasic y fue el primer juego que conseguí terminar.


PCAD 1992

Un clon del AutoCAD de la época, que costaba más de un millón de pesetas.  La idea era seguir ampliándolo introduciendo más funcionalidad pero lo dejé ahí. Todas la formulación matemática, vectores, trigonometría, etc. la saqué del libro "Elementos de Matemáticas" de J. Rey Pastor.

No he conseguido encontrar un programa que hice con 11 años, también clon de lo que se conocía como Utilidades Norton, que lo llamé Utilidades Isidro. Pero en este caso, recuerdo que lo tenía impreso en decenas de hojas de papel matricial, que quizás encuentre en alguna carpeta algún día.


Wednesday, August 26, 2015

Curiosa intuición

Supongamos que un sello junto con un sobre cuestan 1,10€. Si sabemos que el sello cuesta 1€ más que el sobre, ¿cuánto vale el sobre?

Cuando hicieron una pregunta similar a esta estudiantes en Universidades de prestigio, un porcentaje muy elevado contestó que el sello costaba 1€ y sobre 10 céntimos.

Es fácil, ¿no?

Pues la verdad es que no tanto. Si el sobre costara 10 céntimos y el sello cuesta 1€ más, el sello costará 1,10€. Por tanto, el sello junto con el sobre costarán 1,20€ (10 céntimos más de lo que se indicaba).

El cerebro está diseñado para esforzarse lo mínimo, de esta forma ahorra energía. En este caso, llegamos de forma automática a una solución aparentemente tan sencilla que ni siquiera verificamos su validez.

Es lo que Daniel Kahneman en su libro Thinking, Fast and Slow detalla al diferenciar la parte intuitiva del cerebro (Sistema 1) de la parte racional pero perezosa (Sistema 2). La parte intuitiva del cerebro llega a una solución aparentemente tan sencilla, que ni siquiera la parte racional del cerebro se molesta en comprobar.

Por lo tanto, el hecho de llegar a conclusiones de forma inmediata, fácil e intuitiva, nos debe alertar para que hagamos una mínima comprobación. De esta forma podremos detectar si hemos sido "engañados" por nuestro cerebro.

Por cierto, el sello cuesta 1,05€ y el sobre 5 céntimos.

Wednesday, July 29, 2015

El pitch de Pixar

En el libro "To Sell is Human", Daniel Pink presenta una técnica para contar historias de forma efectiva.

Esta técnica se basa en la narrativa que comparten las películas de Pixar. El hecho de referirse a Pixar no es casualidad. Todas las películas de Pixar son un éxito en taquilla por lo que merece la pena analizar qué es lo que hacen bien. Según Emma Coats, guionista de Pixar, todas las historias siguen la misma estructura:

Érase una vez (Once upon a time there was) ...
Todos los días (Every day), ...
Un día (One day), ...
Debido a eso (Because of that), ...
Debido a eso (Because of that), ...
Hasta que por fin (Until finally), ...

Por ejemplo, podemos ver como el guión de la película Buscando a Nemo sigue esta estructura:

1. Érase una vez... un pez viudo, llamado Marlin, que era muy protector con su único hijo , Nemo.
2. Todos los días... Marlin advertía a Nemo de los peligros del océano y le imploraba que no nadara lejos.
3. Un día... en un acto de desafío, Nemo ignoró las advertencias de su padre y nadó en mar abierto.
4. Debido a eso... es capturado por un buceador y termina en la pecera de un dentista en Sydney.
5. Debido a eso... Marlin se embarca en un viaje para recuperar a Nemo, con la ayuda de otras criaturas del mar por el camino.
6. Hasta que por fin ... Marlin y Nemo se encuentran, vuelven y Nemo aprende que el amor depende de la confianza.

Según Daniel Pink, podemos usar esta misma estructura para contar nuestras propias ideas y proyectos de forma efectiva y diferente.

Thursday, May 21, 2015

Prueba empírica del problema de Monty Hall

El problema de Monty Hall es un problema matemático bien conocido (es.wikipedia.org/wiki/Problema_de_Monty_Hall).

En este post voy a mostrar un simple programa para los incrédulos que aún piensen que la solución no es correcta.

Este tipo de problema consiste en los siguiente:

En un concurso, nos muestran tres cajas, donde en una hay escondido un premio y las dos restantes están vacías.

El presentador pide que seleccionemos una caja. A continuación, de las restantes cajas, el presentador abre una de ellas, la abre y muestra que está vacía.

En ese momento nos pregunta si queremos cambiar de caja.

¿Qué responderías?

En el momento de tomar esta decisión, hay dos cajas cerradas y sabemos que en una de ellas está el premio. La intuición nos dice que la probabilidad de que el premio esté en nuestra caja es del 50%.
Por lo tanto, cambiemos o no de caja, la probabilidad de llevarnos el premio será del 50%.

Pero esto no es correcto. Si cambiamos de caja, la probabilidad de acertar es aproximadamente del 67%

Aparentemente no tiene sentido, ¿no?.

Si en el momento en el que tenemos que tomar la decisión de cambiar o no de caja, viniera una persona que no ha visto lo que ha sucedido y se pusiera en nuestro lugar, la probabilidad de que se llevara el premio en ese caso sí sería del 50%. ¿Cómo puede ser que si cambiamos de caja aumente la probabilidad de ganar el premio?

La respuesta es muy sencilla. Cuando tenemos las tres cajas, la probabilidad de que el premio se encuentre en la caja que hemos seleccionado es del 33% (1/3). Sin embargo, la probabilidad de que el premio se encuentre en alguna de las cajas que no hemos seleccionados es del 67% (2/3).

Cuando el presentador muestra una caja vacía, la probabilidad de que el premio esté en la caja que hemos seleccionado sigue siendo del 33% y la probabilidad de que el premio se encuentre en alguna de las cajas que no hemos seleccionado también sigue siendo del 67%. Pero ahora el resto de cajas que no hemos seleccionado es una, ya que el presentador ha abierto la otra. Por lo tanto, cambiar de caja hace que la probabilidad de llevarnos el premio pase del 33% al 67%.

La persona que viene de fuera no tiene tanta información, no sabe que antes había tres cajas y que el presentador ha abierto una de las cajas que no tenía el premio. Es esta información lo que hace que nuestra probabilidad de llevarnos el tiempo sea del 67% frente al 50% que tiene la persona que viene de fuera.

Una forma sencilla de ver esto, es imaginar que en vez de tres cajas, hay 1000 cajas. En este caso, igual que antes, seleccionamos una caja y el presentador, a continuación, abre 998 cajas mostrando que están vacías. En este momento estamos en el mismo caso que antes, tenemos dos cajas y en una está el premio. ¿Cambiarías ahora de caja?. Seguro que sí, ¿no? La probabilidad de haber seleccionado la caja con el premio a la primera de entre 1000 cajas, es bastante baja.

Para los incrédulos, aquí he hecho un programa en Java que simula este concurso y lo prueba:

import java.util.Random;

public class ChangeVariable {
  private boolean boxes[];
  
  private int boxWithTheBall;
  private int shownEmptyBox;
  private int boxSelectedByPerson;
  
  private Random rnd;
  
  public ChangeVariable(boolean changeBox) {
    rnd = new Random();
    
    start(changeBox);
  }
  
  private void putBallInBox() {
    boxWithTheBall = rnd.nextInt(3);
    boxes=new boolean[3];
    boxes[boxWithTheBall]=true;
  }
  
  private void showEmptyBox() {
    do {
      shownEmptyBox = rnd.nextInt(3);
    } while (
        shownEmptyBox==boxWithTheBall ||
        shownEmptyBox==boxSelectedByPerson);
  }
  
  private void selectBox() {
    boxSelectedByPerson = rnd.nextInt(3);
  }
  
  private void changeBox() {
    for (int i=0;i<3;i++) {
      if (i!=shownEmptyBox && i!=boxSelectedByPerson) {
        boxSelectedByPerson = i;
        break;
      }
    }
  }
  
  private boolean isGuessed() {
    return boxSelectedByPerson==boxWithTheBall;
  }
  
  private void start(boolean changeBox) {
    int iterations = 100000;
    int hits=0; 
    
    for (int i=0;i<iterations;i++) {
      
      // Put a ball in a box
      putBallInBox();
      
      // The person selects a box
      selectBox();
      
      // Show an empty box which
      // is not the selected by the person
      showEmptyBox();
      
      if (changeBox) {
        // The person changes the box
        changeBox();
      } 
      
      if (isGuessed()) hits++;      
      
    }
    
    System.out.println("Hits: "+(hits/(float)iterations));
  }
  
  public static void main(String args[]) {
    boolean changeBox = false;
    
    new ChangeVariable(changeBox);
  }
}

Cuando lo ejecutamos con changeBox=false (no cambiamos de caja), la probabilidad que sale será algo parecido a 0.333 que corresponde al 33% (1/3) que matemáticamente corresponde.

Sin embargo, cuando lo ejecutamos con changeBox=true (siempre cambiamos de caja), la probabilidad que sale será algo parecido a 0.666 que corresponde al 67% (2/3) que acabamos de ver.

Sunday, April 26, 2015

Encontrando gente con el mismo cumpleaños

Hace algunos meses escuché en un programa de Redes que la probabilidad de que en una fiesta haya dos personas que cumplan años el mismo día es bastante alta. A priori, esto choca un poco. Por lo general, de forma intuitiva, diríamos que esa probabilidad es bastante baja. El motivo podría ser que consideramos esa probabilidad similar a la de encontrar en una fiesta alguien que cumpla años el mismo día que nosotros. Sin embargo, ambas probabilidades no tienen nada que ver.

Para calcular la probabilidad de que en una fiesta de N personas existan dos personas que cumplan años el mismo día, podemos pensar en 365 vasos y N bolas colocadas en alguno de esos vasos al azar. La probabilidad es la misma que 1 menos la probabilidad de que en los 365 vasos haya como máximo una bola. Es decir, la probabilidad de que en algún vaso haya más de una bola (al menos dos personas con el mismo cumpleaños).

La probabilidad sería 1 - 365!/exp(365,n)*(365-n)!

En base a esta ecuación, en una fiesta con 20 personas, la probabilidad de que haya dos personas con el mismo cumpleaños es del 41% y en una fiesta con 50 personas, esta probabilidad es del 97%. Es decir, casi con total seguridad, en una fiesta medianamente grande, va a haber al menos dos personas que cumplen años el mismo día.

Por otro lado, la probabilidad de que cuando llegamos a una fiesta con N personas haya al menos una persona que cumpla años el mismo día que nosotros, se puede calcular como la probabilidad de que al colocar N bolas al azar en 365 vasos, no haya ninguna en el vaso donde está nuestra bola.

La probabilidad sería 1 - exp(364/365, n)

Por tanto, que en una fiesta con 20 personas haya alguien que cumpla años el mismo día que nosotros es sólo del 5%, mientras que en una fiesta con 50 personas es del 13%.

Friday, January 23, 2015

Cómo usar el plugin Database Migration de Grails

A continuación describiré una manera de trabajar con el plugin Migration de Grails basado en Liquibase que me resulta especialmente cómoda. La diferencia respecto a la del manual es que podemos seguir trabajando en local con el modo dbCreate=create-drop sin necesidad de tener en cuenta las migraciones hasta el momento del pase a Producción.

Supongamos que tenemos nuestro modelo de datos en local (con dbCreate=create-drop) y es la primera vez que se va a instalar en Producción. Lo primero que hacemos es detener la aplicación en local, y generar el changelog inicial de la siguiente forma:

grails dbm-generate-gorm-changelog changelog.groovy

Esto generará el fichero changelog.groovy en /grails-app/migrations

En este caso, al estar nuestro entorno local en modo create-drop, cuando se ejecuta este script se creará el esquema tal como refleje las clases del dominio en ese momento.

Para instalar por primera vez en Producción, simplemente haremos contra Producción grails prod dbm-update y se creará el mismo esquema de base de datos que tenemos en local.

Obviamente, en Producción dbCreate debe estar comentado porque queremos que el esquema se cree y actualice mediante changelogs y no de forma automática.

En este momento los esquemas en local y en Producción serán iguales.

Seguimos nuestros desarrollos en local, creando y modificando clases de dominio sin preocuparnos de nada, ya que estamos en modo create-drop.

Llegado el momento, decidimos migrar el esquema modificado a Producción. Lo que queremos es aplicar únicamente los cambios, por lo que tenemos que obtener en primer lugar el changelog de los cambios. Para ello, simplemente comentamos el dbCreate para que no se autogenere el esquema a partir del dominio, y borramos el esquema local mediante cualquier cliente de base de datos (el esquema debe quedar vacío, sin ninguna tabla).

Con estas premisas, ejecutamos en local grails dbm-update, asegurándonos que en grails-app/migrations está el changelog.groovy que se ejecutó en Producción. Esto hará que nuestro esquema local sea en ese momento idéntico al de Producción que queremos actualizar.

A continuación hacemos grails dbm-gorm-diff updates.groovy. Esto generará el changelog con las diferencias entre el modelo local (dominio) y el esquema copia de Producción, que será precisamente lo que haya que ejecutar en Producción.

Los cambios contenidos en el fichero que se acaba de generar grails-app/migrations/updates.groovy los copiamos en changelog.groovy y ejecutamos contra Producción grails prod dbm-update. Esto hará que se apliquen los cambios quedando Producción actualizado.

Por último, en local volvemos a descomentar dbCreate dejándolo de nuevo en modo create-drop para seguir trabajando de forma cómoda en local.



Tuesday, September 23, 2014

¿Cómo funciona this en JavaScript?

En JavaScript, comprender el funcionamiento de this en las llamadas a funciones no suele ser sencillo al principio. Sin embargo, si se entiende lo que internamente hace JavaScript en las llamadas a funciones, todo queda más claro:

Cuando se llama a una función:

foo('hola')

internamente es como si se hiciera lo siguiente:

foo.call(undefined/window, 'hola');

Por otro lado, si se llama a una función perteneciente a un objeto:

objeto.foo('hola')

internamente es como si se hiciera lo siguiente:

foo.call(objeto, 'hola');

El primer parámetro de call es el valor de this dentro de la función. En modo estricto (strict mode), el valor pasado como this será undefined, mientras que en modo no estricto, será el objeto global (objeto window en cualquier navegador).

Teniendo esto en cuenta, veamos lo que pasaría con un objeto como el siguiente:

var person = {
    firstName: 'Isidro',
    sayHello: function() {
        console.log("Hello, I'm "+this.firstName);
    }
}

Si hacemos:

    person.sayHello();

Por consola se mostrará "Hello, I'm Isidro". En este caso, internamente se ejecuta algo como:

    person.sayHello.call(person);
   
Por lo que this.firstName "sería" person.firstName

¿Qué pasaría si obtengo una referencia a la función del objeto y la llamo desde fuera en modo no estricto?

var f = person.sayHello;
f();

En este caso, por consola se pintará "Hello, I'm undefined"

Esto es porque internamente se ejecuta algo como:

    person.sayHello.call(window);
   
y por tanto, como en el objeto window no hay ningún objeto llamado firstName, muestra undefined.   

En este caso, si quisiéramos ligar la función con un objeto en particular, usaríamos bind:

    f = person.sayHello.bind(person);
   
Ahora al ejecutar la función devolvería:   

    f(); // Hello, I'm Isidro
   
¿Qué pasa con las funciones anónimas?

Supongamos que la clase person es ahora:

var person = {
    firstName: 'Isidro',
    sayHello: function() {
        function getCapitalizeName() {
            return this.firstName.toUpperCase();
        }
        console.log("Hello, I'm "+getCapitalizeName());
    }
}

y ejecutamos:

    person.sayHello();   
   
En este caso, se muestro por consola de nuevo: "Hello, I'm undefined"
El motivo se entiende claramente si traducimos la llamada a la función getCapitalizeName() por lo que realmente se está ejecutando:

    getCapitalizeName.call(window)

De nuevo, dentro de getCapitalizeName, this apuntará a window y como en el objeto window no existe el objeto firstName, devuelve undefined. No podemos pensar que como la función getCapitalizeName está definida dentro del objeto person, automáticamente this apunta a person.

Para que funcione tal como esperamos, podríamos llamar a la función getCapitalizedName de forma explícita:

    console.log("Hello, I'm "+getCapitalizeName.call(this));  

En este caso, mostraría: Hello, I'm ISIDRO

Saturday, August 9, 2014

Herencia Prototípica y AngularJS

A veces, aquellos que vienen de lenguajes con herencia clásica como Java, se encuentran con serios problemas cuando empiezan a trabajar con otros tipos de herencia como la prototípica de Javascript (Prototypal Inheritance). 

Un ejemplo es cuando se trabaja con AngularJS y se usan directivas que crean scopes que heredan prototípicamente de su scope padre, en concreto, directivas como ng-include, ng-switch, ng-controller o directivas con scope:true. En estos casos, el desarrollo puede generar dolores de cabeza si no se entiende bien este tipo de herencia.

Veamos un ejemplo. Supongamos que tenemos una directiva como la siguiente:

directive('test', [function() {
    return {
     scope: true,
     template: '<input type="checkbox" ng-model="active"></input>'
    };
}])

En este caso, la directiva crea un nuevo scope que hereda prototípicamente del scope padre.

Supongamos que tenemos un sencillo controlador como el siguiente:

controller('TestCtrl', ['$scope', function($scope) {
$scope.active=true;
}]);

Si nuestro template es el siguiente:

<div ng-controller="TestCtrl">
<div test1></div>{{active}}
</div>

Vemos que cuando ejecutamos la aplicación, aparece el checkbox marcado y bajo él la palabra true como era de esperar, ya que en el controlador la variable active se inicia a true.

Hasta aquí todo bien. Pero, ¿qué pasa cuando desmarcamos el checkbox?  ¡Sigue apareciendo true debajo del checkbox!

¿No debería cambiar la vista adaptándose al valor actual? Pues sí, pero aquí entra en juego la herencia prototípica que complica un poco las cosas.

La herencia prototípica tiene la siguiente peculiaridad: para leer siempre se recorre la cadena de prototipos hacia arriba hasta encontrar la variable, mientras que para escribir no se recorre, por el contrario, se escribe en el objeto (scope) actual.

Lo que realmente está pasando es que tenemos dos scopes, uno el del controlador (S1) y otro el de la directiva (S2) que hereda prototípicamente de S1:

S1, que es el scope asociado al controlador (TestCtrl), incluye la variable active=true.
S2, que es el scope asociado a la directiva, no incluye esa variable.

Cuando se ejecuta la aplicación, la directiva enlaza el valor del checkbox con la variable active del scope. Pero, ¿de qué scope? pues del scope de la directiva. En este caso, intenta leer el valor de la variable active en el scope S2. Como en este scope no está definida, siguiendo las reglas de la herencia prototípica, busca en el scope padre S1 donde sí se encuentra y se muestra el checkbox marcado. Por otro lado, en la vista se muestra true porque ésta va enlazada con el scope S1 del controlador.

Cuando desmarcamos el check, lo que se está haciendo es una escritura. De nuevo, se comienza por el scope de la directiva S2. Como antes, en este scope no se encuentra la variable active y, aquí surge la confusión, se crea una nueva variable active con el estado false en S2.

En este momento hay definidas dos variables active, una en S1 con el valor true y otra en S2 con el valor false. La nueva variable active de S2 es la que a partir de ahora estará asociada al checkbox y la S1 seguirá asociada al controlador (vista). Es por ello, que en la vista aparece true ya que realmente la variable que se está leyendo para formar la vista es la de S1.

Si volviéramos a marcar el checkbox, el proceso sería el mismo, quedando en este caso la variable active de S2 con valor true, el checkbox marcado y en la vista la palabra true proveniente de la variable active del scope S1.

Una forma para evitar este tipo de problemas es usar variables accedidas por referencia en vez de por valor. Pero esto lo veremos en otro post otro día.