Strict Mode en Javascript

¿Que es Strict Mode?   ¿Para que sirve?

Strict Mode es una funcionalidad de ECMAScript 5 que sirve para hacer que una parte del programa funcione bajo un contexto estricto. Este contexto previene de que ciertas acciones sean tomadas y lanza excepciones al respecto. En otras palabras nos ayuda a cometer menos errores cuando escribimos código en javascript.

¿Como usar Strict Mode?

Para poder utilizarlo lo único que hace falta es escribir  'use strict' al principio del codigo (Ojo! Esto no  siempre necesitamos que sea así. Para más detalles leer mas abajo en ¿Donde declarar el contexto?):

'use strict';
// Codigo

Pequeño ejemplo:

foo = 5; // foo es una variable global
alert(foo);

Ver ejemplo en jsfiddle
El codigo de arriba se puede ejecutar sin inconvenientes, pero como muchos saben si no colocamos var al declarar la variable "foo" esta es interpretada como global y en un futuro puede ocasionarnos problemas.

Ahora ¿Qué pasa si colocamos 'use strict' al principio del programa?

'use strict';
foo = 5;
alert(foo);

Los invito a que lo comprueben en jsfiddle: Ejemplo cocinado, presionen run y vean que pasa... nada no? Como les dije al principio, usar strict mode evita que ciertas acciones sean tomadas y lanza exepciones al respecto. Si apretamos F12 en la pagina podemos observar que el navegador lanzo una exepción: "Uncaught ReferenceError: foo is not defined" (solo para chrome, el mensaje depende del motor de javascript que tenga el navegador).

¿Donde declarar el contexto?

Como mencionamos en otro parrafo no siempre necesitamos declarar el contexto al principio del codigo. Strict Mode solo se aplica a scripts enteros o a funciones. En otras palabras si activamos strict mode para todo un script después no hay forma de desactivarlo para una parte especifica del codigo. Como esto puede ser problematico (sobre todo cuando el codigo en el que lo usamos no fue escrito bajo el control de strict mode)  es recomendable que se use solamente por funciones. Para hacer esto solo debemos escribir la sentencia 'use strict' al principio de la función y antes de cualquier otra sentencia:

 
 (function doSomething(){
     // Esta funcion usa  strict mode     
     'use strict';
     foo = 5; 
     alert(foo);}());
 
 (function doSomethingElse(){
     // Esta funcion no usa  strict mode     
     foo = 5; 
     alert(foo);}());

¿Que restricciones aplica?

• Impide crear varaiables globales de forma implicita (como vimos más arriba).
• El uso de eval() no provoca un efecto colateral. Las variables que declaramos dentro de está solo son validas en ese contexto.
• arguments.caller, arguments.calee, Function.arguments y Function caller no se reconocen.
• La sentencia with() tampoco se reconoce.
• this  dentro de una funcion no hace mas referencia al objeto windows. Retorna null o undefined.
• Lanza un error al intentar borrar una propiedad no configurable.
• Impide que declaremos un objeto cuyas propiedades tengan el mismo nombre.

Finalmente

La sentencia 'use strict' corre en navegadores viejos (si bien no hace nada, ya que eso depende de la implementacion del motor de javascript).

Si estan interesados en mejorar su codigo javascript los invito a leer nuestro articulo Javascript escribiendo buen codigo.

Referencias:
Mozilla Strict Mode
John Resig ECMAScript 5 Strict Mode, JSON, and More
Raohmaru Use Strict

Twittear Seguir a @3p_ar

Leer más...

GIT, y ahora que hago?

Hace ya un tiempo que empezamos a trabajar con GIT y como suele pasar despues de todo cambio positivo, cuesta entender por qué no haciamos esto antes.

Claro, todo esto suena muy lindo, pero no fue tan fácil desde el principio. "Veamos de qué se trata" dijimos y nos encontramos con: repository, local repository, init, clone, stage, commit, pull, push, fetch, merge, rebase, squash, branch, check out, tag, cherry pick… Si, "ya estamos mareados" pensamos, y sólo conocíamos los nombres de estas, que son algunas de las acciones que se pueden hacer con GIT y efectivamente se usan casi todas en lo cotidiano de un equipo de trabajo.

Una vez tomada la decisión, no quedaba otra opción que aprender lo más rápido posible. Buscar información clara y sobre todo en castellano no fue sencillo. Toda la documentación estaba en inglés y por si fuera poco, parecía dedicada a un experto más que a alguien que intentaba aprender cosas básicas como nosotros. Si bien hoy se puede encontrar documentación bastante más clara, decidimos aportar nuestro granito de arena, redactando un breve comentario con las características más usadas.

Repositorio remoto y otro local

Un repositorio de git se puede pensar como una carpeta que contiene información de las modificaciones que se fueron haciendo en el contenido del mismo organizada en comits y ramas, generalmente este repositorio se genera en alguna plataforma online, para poder compartirla facilmente como GitHub, Bitbucket, etc. De ahora en más nos referiremos al mismo como repositorio origen.

Un repositorio local de git no es más que una carpeta en nuestra computadora donde almacenamos nuestro código y una carpeta .git que guarda toda la información del repositorio principal además de una referencia al repositorio origen. Tambien podemos generar un "repositorio origen" dentro de una carpeta en forma local y trabajar con el mismo. La configuración mas común es generar un repositorio en forma online como ya mencionamos y varias copias, distribuidas en los equipos que colaborarán con nuestro proyecto.

Init

Esta acción se utiliza para generar un nuevo repositorio. No es el comando más usado, ya que sólo la usaríamos en dos situaciones.

1. Vamos a crear en repositorio origen en nuestro equipo. 
2. Vamos a generar un repositorio local y luego agregar manualmente la referencia al repositorio origen.

El primer punto puede realizarse ejecutando 'git init --bare' aunque ya discutimos por qué no es lo más común. Mientras que el segundo que cuenta con dos pasos puede resumirse usando el comando que veremos a continuación.

Clone

Lo más común es que varias personas trabajen en un mismo proyecto, por lo que generalmente se crea un repositorio público, al que todos tengan acceso y un repositorio local en cada puesto de desarrollo. El primero se genera usando ‘git init --bare’ o en plataformas online como vimos en el punto 1 del bloque anterior. En el punto 2 hicimos referencia a este comando que copia el repositorio origen a los puestos que van a colaborar en el proyecto ‘git clone’. Este comando genera un repositorio local con una copia exacta del repositorio origen en una ubicación especificada.

El comando generico para esto es ‘git clone origen destino’, donde origen es el path o url del repositorio origen a referenciar y destino el path donde queremos almacenar nuestra copia.

Fetch y Pull

Ambos comandos son utilizados para actualizar nuestro repositorio local con los datos del repositorio origen. El primero Fetch ‘git fetch –all’ actualiza sólo la carpeta .git, con lo cual podemos saber qué cambios hubo sobre el repositorio origen, pero no podemos interactuar con ellos ya que nuestro entorno de trabajo no fue modificado. Es como tener una foto del estado actual. Mientras que con el segundo ‘git pull’ se actualiza todo el repositorio, tanto la carpeta .git como nuestro directorio de trabajo y todos los archivos contenidos por el mismo. Después de ejecutar este comando, no sólo conocemos el estado del repositorio remoto, sino que somos capaces de interactuar con todos los cambios realizados por cualquier colaborador en el repositorio principal.

Hasta este momento sabemos cómo generar un repositorio, mantenerlo actualizado y sincronizado con un repositorio origen o remoto. Supongamos ahora que hicimos una modificación al proyecto y queremos que los demás lo puedan ver. Para esto tenemos que seguir una serie de pasos que se comentan a continuación.

Stage y Commit

Lo primero es generar un paquete con nuestras modificaciones y agregar una descripción del trabajo realizado, todo esto se conoce como 'commit'.
Después de modificar uno o más archivos, los mismos se encuentran en un estado ‘Dirty’ o sucio y para que formen parte de un commit, tienen que pasar por una etapa de stage, cuando hacemos esto estamos generando una imagen de estos archivos y esta información se almacena en la carpeta .git. Supongamos que agregamos un archivo test.txt a nuestro directorio de trabajo, antes de generar un comit ejecutamos 'git add test.txt' con lo cual agregamos este archivo al area de stagging.

Todavía la historia de nuestro repositorio no se modificó, para esto debemos confirmar los cambios que fuimos sumando al area de stagging y agregar un mensaje. Esto se conoce como 'commit' y ejecutando 'git commit -m "mensage"' lo generamos.

Ahora si, después de confirmar los cambios y agregar el mensaje, podemos ver como la historia de nuestro repositorio, se modifica y aparece el nuevo commit.

Push

Lo que nos falta hacer es compartir nuestro trabajo con el resto de los participantes del proyecto y para esto nuestros commits deben publicarse al repositorio origen. Para lograrlo es que usamos el comando ‘push’. Esta es la única acción de las realizadas hasta el momento que modifica el contenido del repositorio remoto.
Simplemente ejecutando ’git commit origin master’ logramos que nuestros commits viajen hasta el repositorio origen, modificando la historia del proyecto que todos ven. Una vez hecho esto, el ciclo vuelve a comenzar.

Este es un acercamiento básico a GIT que esperemos ayude a clarificar algunas dudas, Si bien comentamos las acciones basicas que funcionarían bien en un proyecto con un solo desarrollador, el proceso puede complicarse al agregar participantes

Otras entradas de nuestro blog sobre este tema:

Git submodulos anidados


Puente entre TFS y Git

Obtener version de Git tag desde CCNET

Empezando en Git ...

Git, paquetes Nuget y caracteres de fin de linea

Twittear Seguir a @3p_ar

Leer más...

Javascript: Escribiendo buen código

Ya sea porque recién comenzamos o porque necesitamos garantizar la efectividad de nuestros javascript, es necesario conocer que herramientas tenemos al alcance de la mano que nos ayuden a escribir buen código: quizás hayan leído o escuchado acerca de JsLint y JsHint, hoy vamos a hablar de ellos

Sin entrar en mucho detalle, ambas son herramientas que nos van a permitir validar nuestro javascript y asegurarnos que cumpla con determinadas reglas. En el caso de JsLint es un poco restrictivo acerca de su configuración y JsHint es un fork del anterior muchisimo más pulido, flexible y hecho por y para desarrolladores.

Con respecto a las reglas, podemos decirle a los validadores que tengan en cuenta aspectos como los siguientes y nos alerte al respecto:

• Si tenemos variables que declaramos y no usamos
• Si no usamos algún parámetro en una función
• Comentarios del estilo TODO
• Existencia de sentencias de debugging (console.log)
• Comparaciones con == o != (No estríctas)
• Cuando no usamos { } para separar bloques if (Por más que tengan una sola línea)
• Si usamos funciones dentro de ciclos
• Etcétera

En el sitio de JsHint, hay un apartado partícular que nos enseña como incluirlo para que sean de utilidad en nuestros proyectos. Hay muchas implementaciones y se encuentra en los entornos de desarrollo más utilizados

Casos que analizamos

• Constructores

 var cat = new Object();
    cat.name = "Nacho";
    console.log(cat.name);

En este caso, las herramientas nos recomiendan que la notación literal de objetos es más adecuada

 var dog = {
        name: "Benji",
        getName: function () {
         return this.name;
  }
   };
    
    console.log(dog.getName());

Ventajas: Menos código, más claro a simple vista, menos repetitivo si debemos agregar propiedades y funcionalidad

• Comparaciones

var a = 1, b = 2;

if (a = b) { 
  console.log(1);
} 
else { 
  console.log(2);
}

Javascript no espera que ocurran asignaciones dentro de bloques condicionales. Es más probable que la verdadera interpretación deseada sea if (a == b) o if (a === b)

Ambas herramientas alertarán al respecto y es configurable bajo la característica: "About assignments inside if/for/..."

• Comparaciones de tipo al usar == y !=

  var gato = {edad:2};
   var perro = {edad:2};

   if(gato.edad == perro.edad){
    console.log("iguales");
   }
   else{
    console.log("diferentes");
   }

   // Muestra iguales

   perro.edad = "2"; // Convertimos el valor 2 en un string que tiene un 2

   if(gato.edad == perro.edad){
    console.log("iguales");
   }
   else{
    console.log("diferentes");
   }

   // Muestra "iguales". Porque Javascript internamente está haciendo una conversión de tipos              
   // para que ambos valores sean comparables. Entonces 2 será igual que "2"

   if(gato.edad === perro.edad){     // Comparamos estrictamente: Valor y tipo
    console.log("iguales");
   }
   else{
    console.log("diferentes");
   }

   // Muestra diferentes

   perro.edad = 2.0; // Asigno un valor con decimales

   if(gato.edad === perro.edad){
    console.log("iguales");
   }
   else{
    console.log("diferentes");
   }
   // Muestra iguales. Por qué? Porque Javascript no reconoce "subtipos", ambos son  
   // numéricos y por ende iguales
 

Ambas herramientas permiten configurar si nos alerta o no en caso de no usar comparaciones estrictas

• Cuidado con la coma

    var json = {
       hola: "hola",
       como: "como",
       estas: "estas",
       numero: 1,          // La última coma no es necesaria, pero generalmente no muestra error
   };

La coma ubicada en algunos lugares de nuestro código sin ningún propósito puede generar errores en algunos navegadores. JsLint alerta siempre en este caso

• ++ y --

JsLint posee la capacidad de no permitir dichos operadores argumentando que es una práctica que alienta astucia innecesaria y hace trabajar de más al compilador

   var num = 2;
   console.log(++num);     //3
   console.log(num++);     //3

El código anterior no valida, en JsHint si lo hace

Donde realmente creo que tenemos un problema es en los ciclos, por ejemplo, el siguiente código no es válido

   for (var i = 0; i < 10; i++) {
           console.log(i);
   }

Primero, porque especifica que las variables deben estar antes de bloques de código, quedando así

     var i;

   for (i = 0; i < 10; i++) {
       console.log(i);
   }

Y segundo por el ++ del incremento final. Esta regla no es muy útil creo, JsHint la conoce y no genera error.

• Salto de linea

¿Cual es la diferencia entre las siguientes funciones?

function sayHello(){
 return {
  a:'hola'
 }; 
}

function sayHelloAgain(){
 return
 {a:'hola'}; 
}

A simple vista parecería que son iguales, la diferencia reside simplemente en el salto de linea del return ¿Pero acaso esto podría ocasionar algún problema? Si recordamos que en javascript el salto de linea es interpretado como el fin de una sentencia podemos inferir que la función no va a retornar lo que esperamos. En otras palabras return va a ser interpretado como una sola sentencia y el resultado de hacer sayHelloAgain() va a ser undefined ¿Que macana no? Afortunadamente tanto JsLint como JsHint nos pueden ayudar a evitar este tipo de errores. En este caso en particular lanzando una advertencia por el salto de linea o también de ausencia del punto y coma (dependiendo que reglas hayamos elegido).

En resumen, dada las ambigüedades de javascript contar con una herramienta amiga que nos ayude a no caer en ciertos errores es de gran utilidad (sobre todo por los dolores de cabeza que nos ahorramos). Si desean probar algunas de las validaciones sin instalar nada pueden hacerlo desde las respectivas paginas oficiales  de JsLint y JsHint.

Ir a JsLint
Ir a JsHint


Twittear Seguir a @3p_ar

Leer más...

¿Se aplica "testing ágil" con metodologías ágiles?

Todos sabemos de qué estamos hablando cuando decimos “proyectos ágiles”. Ahora, ¿Cuándo hablamos de testing, decimos también “testing ágil” ?

Es sabido que ya sea que apliquemos metodologías de trabajo tradicionales o ágiles, los procesos de desarrollo de aplicaciones requieren tareas básicas, a grandes rasgos: análisis, construcción, pruebas, corrección de bugs, implementación. Pero uno de los puntos distintivos en las metodologías ágiles es la velocidad de respuesta frente a los cambios, característica no menor.

Las metodologías ágiles se caracterizan por la obtención de resultados hacia el cliente en el menor tiempo posible. Esto implica un cambio permanente en el software, y esto transforma el testing en ágil, lo que a su vez implica un cambio en la estrategia de testing y la vuelve fundamental ya que aporta uno de los valores primordiales en un proyecto de software ágil.

Más allá de las herramientas que se puedan aplicar para las tareas de testing y de gestión de los defectos, lo que quiero puntualizar en este artículo es la importancia que debe tomar el tester dentro de un equipo. 

Si bien es fundamental elegir las herramientas de apoyo a las tareas de testing desde el inicio del proyecto, tiendo a pensar que la mejor herramienta para un equipo ágil es el conocimiento, la confianza y el valor que tiene el aporte de cada uno. Lograr el fortalecimiento y la fluidez de las relaciones entre los integrantes del equipo, principalmente entre los desarrolladores y testers, es una de las claves para alcanzar con éxito los resultados esperados.

Tomo para ello algunos consejos que leí en este artículo . Cuando los desarrolladores y testers colisionan que me parecieron básicos pero muy interesantes, y que transcribo aquí porque pueden ser de utilidad:

• Dilucidar juntos los requisitos de los clientes
• Construir historias y pruebas unitarias juntos 
• Consensuar cuándo una tarea está lista para pasar a testing para evitar “desencuentros” entre desarrollo y prueba
• Definir entre todos claramente cuándo una tarea se considera como “Done”

Si bien puede sonar algo difícil de poner en práctica, en Tercer Planeta podemos dar fe que este tipo de acuerdos dentro del equipo hacen más fluida la forma de trabajo y con el tiempo se incorporan a un ritmo natural que favorece la relación entre los miembros.
 
Desde mi punto de vista, el "Testeo Ágil", está enteramente relacionado con el conocimiento y aprendizaje de la aplicación por todo el grupo, y fundamentalmente de la confianza que todos los integrantes del mismo le tengan al tester. Además de ser fundamental definir desde el comienzo y entre todos cuál va a ser la estrategia de testing a aplicar y elegir las herramientas que mejor se adapten a cada tipo de proyecto.

El test es una pata MUY importante en el desarrollo de software, vale la pena estar atentos a la evolución del mismo.

Otro artículo recomendado: ¿Como testear un proyecto ágil?

Twittear Seguir a @3p_ar

Leer más...

Team Development for Sitecore (TDS)

En la mayoría de los proyectos de IT estamos acostumbrados a trabajar en distintos ambientes, a pesar de tener infinidad de beneficios, esta forma de trabajo nos obliga a ocuparnos de un desarrollo sincronizado.
Hay dos cosas que necesitan ser sincronizadas en todos los entornos: código y datos. En el caso del código, lo solucionamos utilizando alguna herramienta de "Source Control "(GIT, TFS, etc).

La otra parte del problema es la sincronización de datos, en el caso de Sitecore no sólo nos referimos al contenido del sitio, sino que muchas de las cosas del código (.ASPX, .ASCX, .XSLT) están relacionadas como datos dentro del CMS (Layouts, Sublayouts, Renderings), una práctica común para estos proyectos, es crear paquetes Sitecore, seleccionando todos los items y luego generar un .ZIP.

A partir del Sitecore 6 se incluyo la Serializacion de Items (datos de Sitecore), esto nos permite exportar los datos a un archivo de texto y viceversa. Una vez que tenemos los items de Sitecore en el disco, nos da la posibilidad de incluirlos a un sistema de control de código fuente.
Ahi es donde aparece TDS (Team Development for Sitecore), plug-in para Visual Studio que permite serializar y deserializar items Sitecore para su proyecto directamente dentro de Visual Studio e interactuar con algún "Source Control", pudiendo aprovechar los beneficios que nos brinda: control de versiones, cambios realizados, etc.

Ademas, ahora cada desarrollador puede trabajar con una base de datos local conociendo sus cambios sobre una única base de datos en común, sin necesidad de invertir una increíble cantidad de tiempo en la generación de un paquete para compartir en el resto de los ambientes y poder tener una sincronizacion entre ellos. Esto servirá para centrarse en el código y no en las dependencias.

También nos facilita la comparación entre diferentes versiones de código y si algo que se ha hecho resulta ser un error, simplemente se puede volver a una versión anterior.

Es por eso que destacamos esta herramienta como fundamental y de gran ayuda para este tipo de proyectos, la cual nos ha facilitado mucho el trabajo desde comenzamos a implementarla.

Twittear Seguir a @3p_ar

Leer más...

Las redes sociales dentro de la empresa

Desde hace algunos años el boom de las redes sociales está llevando a las empresas a una nueva forma de comunicación con sus clientes. Esto obliga a, por un lado diseñar estrategias y planes que acompañen y apoyen las campañas de marketing establecidas, y por otro lado a re-pensar la estrategia de comunicación.

Pero qué impacto tienen estos canales en la comunicación interna de la empresa? El uso tradicional de mails, reuniones presenciales o a distancia, intranets, chat, etc. va cediendo terreno frente a los nuevos retos que presenta la necesidad de una comunicación más fluída y "horizontal".  La presencia del microblogging y la red social corporativa en general llega, en mi opinión, para complementar las carencias de los canales tradicionales y adaptarlos a una nueva realidad comunicacional.

Ahora bien, cuáles son las ventajas del uso de redes sociales internas ?

1. Su uso en la vida diaria es ampliamente conocido y difundido, no sólo por las nuevas generaciones. 
2. Son sencillas de usar. 
3. Permiten la comunicación instantánea entre los usuarios en cualquier momento y desde cualquier lugar. 
4. Mejoran la imagen interna de la compañía, fomentando la escucha activa entre todos los niveles jerárquicos.

El valor que los empleados le dan a esta forma de comunicación se basa principalmente en la credibilidad que estos canales despiertan dado que se perciben como más abiertos y francos que cualquiera de los tradicionales.

A mi entender la clave del éxito en la implementación de esta forma de comunicación reside no sólo en el alcance que se le quiera dar a la comunicación interna sino también en la plataforma que se decida utilizar. Este último punto es crucial para no sobre-saturar a los usuarios con demasiadas aplicaciones pudiendo crear confusión sobre cuál usar en cada caso.

Plataformas

Respecto de las herramientas para implementar redes sociales corporativas, algunas empresas optan por desarrollar sus propias redes (basadas fundamentalmente en los conceptos de twitter y facebook), otras se inclinan por herramientas de colaboración ofrecidas en el mercado. En cualquiera de los casos hay que considerar que no siempre es necesario reemplazar las herramientas existentes (como intranets, por ejemplo) sino que la mayoría de las veces lo más conveniente es incorporar los nuevos canales a los que ya estén en uso, precisamente para tomar las ventajas de cada plataforma.

Entre las herramientas más conocidas está Yammer, adquirida por Microsoft en 2012. Pero existen otras como SocialCast, SocialText o CominCorp también bastante difundidas.

Dentro del mundo del OpenSource han aparecido distintas soluciones pero no todas han sobrevivido, muchas de ellas ya no tienen continuidad. Algunas de las que al día de hoy permanecen activas son:

• Status-Net
• Gelato Tumblelog
• JaikuEngine
• ShareTronix
• P2Theme  (no es exactamente una herramienta de microblogging sino un theme de WordPress que transforma la versión standard de WordPress en un sitio de microblogging.
• EcoWaves
• Blurtit

Engagement

Más allá de esto, lo que vale rescatar es que, sin dudas, cualquier mejora en el modelo comunicacional acompañada por la implementación de redes sociales corporativas dará la oportunidad de aumentar la motivación, el compromiso y la productividad, reforzando así la cultura organizacional y la participación de una gran parte de los empleados.


Algunos artículos que nos parecen de interés en este tema:

Microblogging privado en la empresa

La mitad de las empresas usarán las redes sociales ...  

Twittear Seguir a @3p_ar

Leer más...