Iteraciones, valor y el nuevo San Mamés

El mundo de desarrollo de Software tiene su propia velocidad. Las ideas van y vienen, se crean tendencias, se testean nuevos enfoques y se descartan otros. Pero en otras áreas de la ingeniería en las que la responsabilidad civil es mayor, los cambios en los procesos tienen otros ciclos. Esto implica que no siempre es fácil ver como se plasman ideas consideradas axiomas por el agilismo.

Hoy os quería comentar un ejemplo relacionado con esto. Como los más futboleros sabéis, el Athletic Club de Bilbao ha creado un nuevo estadio de futbol, el Nuevo San Mamés (ni media vuelta al nombre)

Este proyecto tenia ciertas restricciones:

• El nuevo estadio ocuparía parcialmente el área del anterior.
  Esto en el mundo del software sería algo parecido a tener código legacy. ;)
  
• El equipo debe empezar a jugar la liga en este nuevo estado tan pronto como sea posible. (Las dos primeras jornadas en "casa" se jugaron en el estadio de la Real Sociedad)

Revisando la planificación del mismo, podemos observar que se dividieron los hitos a cubrir en tres fases:

Fase	Operación	Fecha fin
Inicio	Primera piedra.	26 de mayo de 2010.
	Inicio de las obras.	25 de junio de 2010.
Fase 1	Construcción de las tribunas laterales y norte.	Verano 2013.
	Primeros partidos.	Temporada 2013/14.
Fase 2	Demolición del antiguo San Mamés.	Temporada 2013/14.
Fase 3	Construcción de la tribuna sur.	Verano 2014.
	Fin total de las obras.	Temporada 2014/15.

Y este me ha parecido un muy buen ejemplo de buenas prácticas aplicadas a la obra civil.

Si nos fijamos:

• Se hace un tratamiento especial sobre el hito principal del proyecto que ataca la restricción anteriormente citada (Jugar los primeros partidos en el estadio tan pronto como sea posible) dentro de la Fase 1.
  
• Cada una de las fases tienen un claro objetivo y aportan valor.
  En todas se define un entregable (medible) que funciona y sobre el cual se iterará para dar más valor al cliente.

Este es el cometido de realizar nuestro trabajo en iteraciones, liberar valor lo antes posible. Esto también nos permite recoger feedbak lo antes posible para poder corregirlo (Creo que algún espectador le tocaron goteras ;)) y rebajar la presión sobre el proyecto general.

Además las entregas (siempre que cumplan las expectativas del cliente) generan confianza y crean una relación de colaboración que mejora la relación entre las partes y hace más fácil que el proyecto llegue a buen puerto.

Esta forma de desarrollar el proyecto, junto con la reducción de costes sobre lo originalmente planificado (también de capacidad), puede ser un buen caso de éxito de las técnicas de sentido común agilidad fuera del ámbito del Software.

Más allá del misterio: Asignando valores con el Revealing Module Pattern

Un patrón bastante extendido cuando desarrollamos código en JavaScript es el Revealing Module Pattern para poder establecer ámbito sobre ciertas partes de nuestro módulo. Quien más quien menos que desarrolle en JavaScript (y no esté en una cueva) ha oído hablar de él así que no vamos a hacer un análisis en detalle sobre el mismo.
Por otro lado, es bastante común exponer un objeto con los nombre de las propiedades que coincidentes con los métodos y propiedades que exponemos y aquí viene el punto propenso a errores que quiero mitigar con este post.
Imaginemos este código:

   1:  var Person = function () {

   2:      var name,

   3:          sayHello = function () {

   4:              alert('Hi, my name is ' + name);

   5:          };

   6:      return {

   7:          name: name,

   8:          sayHello: sayHello,

   9:      }

  10:  }

  11:   

  12:  var andoni = new Person();

  13:  andoni.name = 'andoni';

  14:  andoni.sayHello();

Si yo os pregunto que mostrará la función sayHello por pantalla, que me diríais?
Pues aunque no os lo creáis un bonito mensaje: "Hi, my name is undefined"
Ahora es cuando viene lo de:

“¿Pero que ha pasado? Si yo he asignado el name a "Andoni"!!!

Esto seguro que es por lo del this, o lo del lexical scope … JavaScript es un mierda y que porque no nos habremos quedado en la era de COBOL...”

Que no cunda el pánico, vamos a entender que ha pasado antes de pegarle fuego a V8, Chakra y a todo lo que se mueva...

Tened en cuenta que si aplicamos el patrón, la función nos devuelve otro objeto con dos propiedades (name y sayHello). Cada una de ellas apunta a los objetos reales que está revelando. El código que hemos visto arriba recibe ese objeto y lo que está haciendo es cambiar a que apunta la propiedad name del objeto revelado, que obviamente, no es lo que esperábamos... (recordad los punteros)

Revisemos nuestro código problemático con una modificación:

   1:  var Person = function () { 

   2:      var name, 

   3:          setName = function(nameToSet){ 

   4:              name = nameToSet; 

   5:          }, 

   6:          sayHello = function () { 

   7:              alert('Hi, my name is ' + name); 

   8:          }; 

   9:      return { 

  10:          name: name, 

  11:          setName: setName, 

  12:          sayHello: sayHello, 

  13:      } 

  14:  }

  15:   

  16:  var andoni = new Person(); 

  17:  andoni.setName('andoni'); 

  18:  andoni.sayHello();

Ahora si que recibiremos el mensaje esperado, debido a que la modificación se esta realizando sobre el mismo objeto y no sobre la propiedad del proxy que nos está siendo revelado.

Es un problema sutil y en ocasiones difícil de corregir así que espero que les sea de utilidad.

Un saludo desde Seattle!!

Andoni Arroyo

[Off-Topic] Javascript – Desde cero hacia las mejores prácticas (Materiales de la charla)

El pasado día 29 de noviembre tuve el placer de dar una charla en el comité sobre JavaScript con el título “Javascript – Desde cero hacia las mejores prácticas”

Aquí os dejo los materiales de la charla por si os pueden resultar de interés.

Descargar materiales

Un saludo

Andoni Arroyo

Como desarrollar con Javascript y no morir (ni matar) en el intento – III

En JavaScript el concepto de Objeto representa un papel clave. Si tenemos en cuenta que no existe el concepto de clase que manejamos en otros lenguajes, es el objeto sobre el que recae la responsabilidad de definir el modelo y almacenar el valor de la instancia.

Una vez interiorizado este concepto, (superado el shock…) debemos tener en cuenta que en JavaScript disponemos de cinco tipos primitivos por valor que son: number, string, boolean, null, y undefined. Todo lo demás son objetos (más o menos especializados)

Estos tipos por valor (exceptuando null y undefined) poseen lo que se conoce como primitive wrapper objects. Los objetos wrapper pueden ser creados utilizando los constructores predefinidos Number(), String(), y Boolean()

Veamos este código al respecto:

   1:          //// number (primitivo)

   2:          var n = 100;

   3:          console.log(typeof n); // "number"

   4:          // objeto Number 

   5:          var nobj = new Number(100);

   6:          console.log(typeof nobj); // "object"

Estos objetos exponen una serie de métodos que nos ayudan a trabajar con la naturaleza de los datos a los que representan. Por ejemplo el objeto Number expone métodos como toFixed() o toExponential o el objeto String los métodos substring(), charAt() o toLowerCase().

Como hemos comentado alguna vez JavaScript es muy propenso a interpretar de la mejor manera que pueda el código e intentar hacer que funcione, con resultados algunas veces imprevistos.

¿Que os parece si os digo que estos métodos pueden ser aplicados también sobre los métodos primitivos por valor?

Pues en principio lo menos que os puede parecer es raro… Bueno, lo que esta ocurriendo detrás de la escena es que JavaScript promociona puntualmente el tipo primitivo a su correspondiente objeto, ejecuta el método y a continuación descarta el objeto creado. Lo dicho, buenas intenciones pero si no conocemos este comportamiento, puede provocar más de un dolor de cabeza…

Por ejemplo, como se nos ocurra la idea de aumentar un tipo primitivo, el interprete de JavaScript no nos arrojará ningún error, puesto que desde el punto de vista sintáctico todo está correcto, pero la propiedad incluida lo será sobre el objeto que se descartará automáticamente con lo que mal negocio hemos hecho.

Veamos un código que ilustra este ejemplo:

   1:          // string primitivo
   2:          var enterprise = "Plain Concepts";
   3:          // El primitivo es convertido a un objeto con el fin
   4:          // de ejecutar el método split()
   5:          console.log(enterprise.split(' ')[0]); // "Plain"
   6:          // Si intentamos aumentar un tipo primitivo no es un 
   7:          // error
   8:          enterprise.CIF = "XXXXXXXXXX";
   9:          // pero como el objeto es decartado automaticamente después de
  10:          // la promoción, la propiedad se pierde...
  11:          console.log(enterprise.CIF); // "undefined"​​

Este comportamiento, no ocurriría si instanciamos un objeto del tipo concreto (String(), Number(), Boolean()… ), por lo que si estamos pensando en aumentar el objeto creado no es buena idea usar los primitivos. 

También podríamos usar el constructor Object que incluye cierta lógica para crear el tipo derivado apropiado en base al valor recibido. (Una especie de factory)

Por ejemplo:

   1:           var n = new Object(3);

   2:           console.log(n instanceof Number); // True

Esta característica es un arma de doble filo puesto que nos puede llevar a errores o comportamientos inesperados cuando empleamos tipos dinámicos, por lo que en general se desaconseja su empleo siendo mas aconsejable (por sencilla y certera) emplear la notación literal.

Como desarrollar con Javascript y no morir (ni matar) en el intento – II

Cuando trabajamos con JavaScript una de las características que más quebraderos de cabeza nos pueden dar es el ámbito de las variables. Así como en otros lenguajes tenemos la capacidad de definir un ámbito dentro de varios elementos (por ejemplo en C# dentro de una clase, método, usign…) en JavaScript el único elemento que nos permite definir ámbito es el objeto function. (Y digo objeto porque en JavaScript una función es un Objeto, es decir puede tener propiedades y métodos…)

Hoy vamos a analizar un efecto conocido como Hoisting. Este efecto ocurre porque en JavaScript podemos dispersar las declaraciones de nuestras variables a lo largo de nuestra aplicación.

Veamos el siguiente código:

   1:          var name = "global name";

   2:          // global variable 

   3:          function func() 

   4:          {    

   5:              console.log ('name value: ' + name);   // undefined   

   6:              var name = "local name";    

   7:              console.log('name value after assign value: ' + name);  
                                                          //local name

   8:          };

   9:          func(); 

Como podéis ver en este código tenemos una variable “name” con el mismo nombre en el ámbito global y dentro de la función. Como hemos comentado antes, la función nos permite definir ámbito de variables, por lo que la variable “name” es diferente dentro y fuera de la misma.

Si analizamos el código anterior podemos observar que en la línea 5 se accede a la variable “name”. Sería lógico espera que dicha variable tenga el valor “global name” pero aquí entra en juego la característica de JavaScript llamada Hosting…

Con este nombre, JavaScript nos permite colocar múltiples “var” en cualquier punto de la función de tal manera que ellos funcionen como si hubiesen sido declarados al principio de la función.

Lo que tenemos que tener en cuenta es que la declaración de la variable se promociona al tope de la función (como si “var name” se colocase antes de la fila 5) pero la inicialización de la misma se ejecuta en el punto definido (la línea 6 en el código anterior). Es por eso que ocurre el efecto comentado anteriormente, es decir, en la línea 5 la variable “name” de la función (“var name”) se ha ejecutado pero no la inicialización de la misma. (Por eso el valor undefined)

Una vez entendido como funciona y con el fin de evitar errores un tanto confusos que disparen el coste de mantenimiento, un buen hábito es asumir la convención de definir todas las variables que vamos a usar al principio de la misma.