miércoles, 18 de julio de 2012

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.

martes, 17 de julio de 2012

[Material del evento] Porque debería automatizar mis pruebas?

Os he dejado en mi skydrive el material del evento Porque debería automatizar mis pruebas? que vimos en el Centro de Innovación Social de Bilbao.

Espero que os resulte interesante, un saludo.

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


Cada día son más las aplicaciones que cuentan con JavaScript como lenguaje de programación.
El motivo de este éxito anunciado es, entre otro, la ubicuidad de este lenguaje, y es que correr en “casi” todos los navegadores instalados a lo largo y ancho del mundo no es poca cosa.

La Web actual requiere cada vez una mayor carga de programación en cliente, hace un uso cada vez más intensivo de las capacidades del mismo (manejo del DOM, AJAX, Almacenamiento en local…) Además existen otros tipos de escenarios donde tradicionalmente JavaScript no tenía presencia (las aplicaciones nativas para Windows, aplicaciones para dispositivos móviles…) que también van convirtiéndose en terreno abonado para JavaScript.
Un claro ejemplo de este cambio ha sido confirmado con la aparición de Windows 8 y su Interfaz Metro. En él, JavaScript se presenta como un lenguaje de cliente de primera clase para desarrollar aplicaciones. Esto lo hace comparable a los hasta ahora intocables lenguajes manejados como C# o VB presentes en WPF o Silverlight.

Este cambio ha sido posible gracias en gran medida a incluir ciertas características que antes formaban  parte de .NET a nivel del Sistema Operativo y, por lo tanto, consumible desde un entorno no manejado como en el que se ejecuta JavaScript. (Internet Explorer)

Además de Metro, en las aplicaciones móviles también JavaScript es bastante común para conseguir reutilización entre plataformas, contando con ciertas artistas invitados como Phonegap…

Y es por todo esto que las comunidades de desarrolladores muy versadas en entornos muy avanzados de programación (como la gente de .NET o Java) van aterrizando en JavaScript y en la mayoría de ocasiones su primera sensación viene a resumirse en la muy común frase “vaya m***** es JavaScript”

Bueno pues la realidad es que sin estar al nivel de los lenguajes y marcos de trabajo modernos tampoco es tan malo como al principio creemos. Lo que si es necesario es realizar el esfuerzo de entender las aproximaciones con las que JavaScript afronta algunos de los problemas comunes. Esta tarea es la que vamos a realizar en esta serie de entradas ayudándonos a encajar los conceptos básicos.
Una de las primeras cosas que debemos tener en cuentas es:

“El problema con las variables globales”

Las variables globales (como su nombre indica) son compartidas a través de todo el código de tu aplicación JavaScript o página Web. Esto quiere decir que la superficie de colisión de dichas  variables es sencillamente: toda tu aplicación, con lo cual es relativamente probable definir diferentes variables globales con el mismo nombre pero diferentes propósitos.

Para entender este problema debemos ser conscientes de que JavaScript es esencialmente propenso a ayudar a que nuestra aplicación funcione a costa de no ser (a veces excesivamente) riguroso en sus validaciones (algo mejorado con el uso del strict)

Se dan dos características para la propensión a este problema:
  • En JavaScript podemos utilizar una variable que no hayamos definido
  • Cualquier variable que no hayamos declarado se convierte automáticamente en la propiedad del objeto global
Veamos un ejemplo:

(Tened en cuenta que en JavaScript el unico elemento que nos permite definir ámbito es el objeto fuction)

   1:   
   2:          function sum(x, y) {
   3:              result = x + y;
   4:              return result;
   5:          }
   6:          console.log(sum(2, 4));  // 6
   7:          console.log(result);  // 6

Como podemos observar aunque el ámbito de la variable result se desea limitar a la function sum en la que se emplea sigue viva fuera de la misma.
La regla de oro es aplicar siempre la palabra reservada var. Este mismo código declarando resutl con un var por delante nos daría un bonito:

Uncaught ReferenceError: result is not defined al ejecutar el código de la línea 7

Sencillo ¿verdad?

Veamos otro código muy similar al anterior pero incluyendo el var que aun  así no funciona como esperamos:

   1:          function foo() 
   2:          {    
   3:              var a = b = 0;
   4:          }
   5:          foo();
   6:          console.log(b);

En este caso lo que está ocurriendo es que solo se aplica el var a la variable a, que se está inicializando con el resultado de la asignación de b = 0. Pero con b nos está ocurriendo lo mismo que en el ejemplo anterior, la estamos usando antes de declararla por lo tanto es un variable global
Hay muchos aspectos sobre los que podemos ir comentando particularidades de JavaScript así que estad atentos.

jueves, 12 de abril de 2012

Evento: Porque debería automatizar mis pruebas?


El próximo día 17 de Abril a las 19:00 tengo el placer de dar una charla con el título ¿Porque debería automatizar mis pruebas? dentro del marco de actividades del grupo WebDev Bilbao en el Centro de Innovación Social de Bilbao.

En la misma hablaremos, entre otras cosas, sobre:

  • Cuales son los aspectos más importantes a la hora de automatizar nuestras pruebas.
  • Que podemos aspirar a conseguir con dicha automatización.
  • Candidatos a la automatización.
  • Porque automatizar las pruebas es más que una técnica.
  • Terminología del mundo de las pruebas.
  • Economía de la automatización de pruebas.
  • ROI.
  • Características del buen test.
  • Problemas comunes.
  • Como organizar nuestros tests.
  • Métodos de diseño de tests.
  • Tipos de tests (que no solo existen test unitarios!!)
  • Estrategias de verificación.

Vamos, de todo un poco sobre un tema tan interesante como es el de la automatización de nuestras pruebas.

Os espero por ahí para hacer el evento lo más interesante posible.

lunes, 6 de febrero de 2012

Cambios y expectativas (Plain Concepts +1)

Es tiempo de cambios para mí. Dejo de trabajar en Panda Security para comenzar una nueva etapa en Plain Concepts.

Haciendo balance de mi paso por Panda Security, el resultado es francamente positivo. He aprendido mucho, trabajando en equipos formados por gente muy diferente (alemanes, cubanos, americanos…) lo cual me ha permitido evolucionar como profesional y como persona. Tópico, pero verdad…

Entonces, por que cambiar?

Pues porque es mucho lo que espero de mi nueva empresa:

  • Gestión ágil (de verdad), con todo lo que eso implica.
  • Proyectos interesantes, avanzados tecnológicamente y con requerimientos exigentes.
  • Compañeros motivados, capaces de compartir sus conocimientos y estar abiertos siempre a la mejora. Conozco hace tiempo a mucho de ellos de la comunidad, eventos y otro saraos. Son el tipo de gente con el que da gusto trabajar.
  • Conocer un montón de gente interesante de la que aprender, tanto dentro como fuera de la empresa. Trabajando duro para ser el peor, como comentaba Dawn Cannan en su articulo: Be the Worst en Agile Record)

Un sitio definitivamente donde poder trabajar con alta motivación, que me ayude a evolucionar aportando mi esfuerzo y plantee retos que sean beneficiosos para ambas partes.

Estoy seguro que esto y mucho más va a ser lo que voy a encontrar allí.

Estamos en contacto.