AngularJS – Experiencia de usuario asegurada

sábado, 29 de junio de 2013


La mejora en la experiencia de usuario en los sitios web, es un camino sin retorno.

Se busca constantemente darle dinamismo a los sitios, además de hacerlos visualmente más atractivos, se intenta que el usuario pueda bucear en la información, sin refrescos de la página ni aparentes demoras.

Esto es algo que se ha buscado desde siempre y de hecho hace mucho que se puede llevar a cabo, las nuevas tecnologías que fueron surgiendo lograron traer simplicidad, y re-utilización del código, ya no tenemos que preocuparnos en hacer llamadas asincrónicas complejas a través  de APIs nativas.

Hoy por hoy existen muchos Frameworks de FrontEnd que permiten simplificar las cosa.

Desde hace unos años en Tercer Planeta nos decidimos por AngularJS y este post es simplemente una invitación que les hacemos a meterse en el tema.

AngularJS es un Framework de FrontEnd / OpenSource desarrollado con JavaScript. Cada vez más popular en la comunidad, no por moda ni nada que se le parezca, el motivo del éxito es su fácil comprensión, desarrollo y por supuesto una notable mejora en la experiencia del usuario.

AngularJS

Ponemos la herramienta sobre la mesa, y les compartimos algunos links de interés para quien quiera empezar adentrarse en el tema:
http://angularjs.org/ - Descargas / Tutoriales y más.
http://www.youtube.com/user/angularjs - Videos y más información.

Batarang

Por último, queremos destacar además esta poderosa herramienta Batarang.
Un plugin para Chrome, que permite debugear AngularJS:
http://blog.angularjs.org/2012/07/introducing-angularjs-batarang.html

Hoy por hoy una herramienta obligada si se desea utilizar AngularJS.








Leer más...

Video en HTML5

jueves, 27 de junio de 2013


Hablar de video en HTML5 es hablar de una intensa lucha que se da entre pesos pesados de internet y de la singular batalla por la estandarización de un códec. En años pasados (2004/2005) la manera que tenian los administradores web de compartir videos en sus web era mediante el recordado Quicktime, Windows media player o los archivos .swf que popularizó Adobe.

Hoy en día, apelamos a Youtube o Vimeo para compartir videos y Steve Jobs para sus dispositivos jamás quiso flash así que se reabrió el debate por tener un estándar para manipular video desde los navegadores.

Pensemos en video como las imágenes. Pueden ser .jpg, .png, .gif, pero no dejan de ser una imágen y el navegador es el encargado de implementarlas a todas. Con el video pasa lo mismo.

Cómo se usa?

Para incluir un video con HTML5 usas el siguiente formato:


Además del ancho y el alto y tal como ocurre con la etiqueta <audio>, tenemos atributos adicionales:

  • Preload: Carga el video junto con la página. Opción recomendada solo si el video es contenido muy importante en nuestra página


Por el contrario, si es un información secundaria, ¿para que penalizar al usuario con espera si quizás no vea el video?. En este caso usaremos algo como esto:


donde le especificamos al navegador que no descargue información del video a menos que el usuario de Play.

  • Autoplay: Esta opción dará play al video automáticamente al terminar de descargarse la página. Lo implementamos de la siguiente manera:
  • Controls: Manipula la visibilidad de los controles para el video (Play, Pause, Seek bar y volúmen).

Compatibilidad

Como ocurre con el tag <audio>, necesitamos especificar varios sources para garantizar la reproducción del video en la mayor cantidad de navegadores. Podemos escribir un código similar a este:

De esta manera, con el primer <source> nos aseguramos que el video funcione en el mundo Apple y con la otra apoyamos una versión más liberal empujada por Google.

Con respecto a IE en sus versiones viejas está de más aclarar que no soporta el tag video, pero podemos contar con flash para solucionar nuestro problema: Incluyendo el código embed justo debajo del último <source>, encerrado también dentro del tag <video>

La documentación oficial del tag video está aquí



Existe un proyecto interesante para utilizar y cuanto menos mirar que es VideoJS. Si te vas a tomar en serio la cuestión de alojar los videos en tu sitio y no depender de terceros, este es tu proyecto. Es un proyecto libre y tiene skins para imitar los principales sitios de video de la web.







Leer más...

Iniciandonos en CSS3

En un principio, las páginas de internet sólo transmitían texto e imágenes y eran en blanco y negro o a lo sumo con muy pocos colores. Hoy no es de esta manera, la web evolucionó y el diseño gráfico no es la excepción. Vamos a profundizar un poquito en este tema: vamos a hablar de CSS

logo de css3
CSS es el lenguaje que se emplea para aplicar diseño visual a los elementos de nuestro documento .html. No es un lenguaje que presente una curva elevada de aprendizaje y posee una sintaxis sencilla. Las letras CSS hacen referencia a Cascade Style Sheets porque los estilos se van aplicando por orden de escritura desde el principio al final. Hoy día continúa en desarrollo pero podría decir que casi no existen limitaciones para diseñar y estilizar un sitio web


CSS: Solución a un gran problema

El .html nunca debe contener estilos. Para eso existen las hojas de estilo: la forma más adecuada de aplicar estilos es mediante ellas. Recordemos que el .html sólo debe contener la estructura semántica de nuestros documentos. Por lo tanto, aislar la presentación del mismo es ideal: permite paralelizar la semántica del diseño y que dos personas o más puedan trabajar cómodamente (Este caso no aplica para los correos electrónicos, pero es un caso aparte)

Por otro lado, al tener asilada la presentación de la semántica, permite que, teniendo una sola hoja de estilos, apliquemos estilos idénticos en diferentes páginas y en todo nuestro sitio muy fácilmente  Pensemos que aplicar un estilo antes era modificar cada hoja que lo usara: hoy modificamos un archivo externo y la solución es inmediata

¿Como empezamos a usar CSS?

  • Estilo en línea: aplicamos bajo el atributo style el estilo para ese elemento. No es una manera recomendada, estructurada y óptima de dar formato a nuestros sitios, pero sí sencilla y rápida. No se recomienda usar esta metodología. Como mencionabamos antes, esta regla no aplica para los correos electrónicos, por lo que si queremos aplicarles estilos debemos hacerlos mediante estilos en línea
  • Hoja de estilo interna: está incrustada dentro del <head>, marcada por la etiqueta <style>. De esta manera se separa la información de los estilos. Esta técnica tiene el mismo problema que los estilos en línea, deberiamos replicarlo en cada página
  • Hoja de estilo externa: es un archivo de extensión .css diferente al archivo donde se almacena el código HTML. Esta es la forma más recomendada porque permite separar el estilo de la estructura

¿Cómo escribimos código .CSS?

La sintaxis de CSS puede resumirse de la siguiente manera:
  • Selector
  • Propiedad y valor
ejemplo de un estilo css
El selector (en este caso: todas las etiquetas p) hace referencia a los elementos del DOM a los que se le aplicarán los estilos (color de fondo rojo). Estos elementos pueden ser seleccionados en función de su tipo, id, clase y posición, entre otros. CSS en su version actual incluye pseudo clases y pseudo elementos. Pseudo clases son :hover, :active, :visited, etc. Y pseudo elementos son :before, :after, -first-letter, first-line, etc

Propiedad y valor se refiere a que atributo de esos elementos será modificado y que valor se le establecerá. La lista de atributos CSS que pueden utilizarse puede encontrarse aquí

El mismo CSS funciona igual en todos los navegadores?

Hay muchas funcionalidades de CSS que no están disponibles en todos los navegadores y menos en todas sus versiones. Es ahí donde entran en juego los prefijos propietarios (-webkit-, -moz-, -o-, etc). Por suerte existen herramientas que nos permiten hacer compatibles nuestros códigos con todos los navegadores más usados

Para ser más específico hablemos de un caso en particular: múltiples columnas (column-count). Esta propiedad permite dividir y estilizar un texto en columnas

Vamos a can i use y buscamos la propiedad para ver su integración: link acá



La fila que nos interesa es: Current

Como vemos en el gráfico, todos los navegadores modernos y más usados ofrecen soporte para esta funcionalidad, pero algunos no de forma nativa, necesitan de un prefijo propietario (Señalado con una pequeña etiqueta de color amarillo). Este prefijo indica que es una propiedad en desarrollo o que quizás no forme parte del estándar y sea un experimento. Para usar esta propiedad y que funcione en todos los navegadores deberíamos usar un estilo similar a este:


Con -moz- le indicamos al motor de render Gecko que use la funcionalidad, y con -webkit- hacemos lo mismo pero para Webkit. En los demás navegadores, como IE desde su versión 10, la funcionalidad funciona sin ningún prefijo. Si seguimos mirando más arriba en esa misma columna, notamos que para las versiones 8 y 9 de internet explorer la propiedad no está presente. Si nuestro sitio debe ser compatible con estas versiones tendremos que lograr la funcionalidad de otra manera

Lo sé, es incómodo todo esto pero existen herramientas como prefix-free que nos facilitan este trabajo. Prefix free es un script que debemos importar ANTES de nuestros estilos y se encargará de agregar automáticamente los prefijos propietarios. Siguiendo el ejemplo anterior, bastaría con escribir algo como esto:

Y como si fuera poco, existe CSS3 PIE que logra que los features de CSS3 estén disponibles en IE6, 7, 8 Y 9! (Magia negra?)





Espero que esto sirva como un buen comienzo







Leer más...

Closures- Un primer enfoque

viernes, 14 de junio de 2013

Vamos a tocar un tema que estos últimos días a los integrantes de 3p nos tuvo algo ocupados: Closures en javascript.

"Un closure es un tipo especial de objeto que combina dos cosas: una función y el contexto en el que fué declarada". La definición no ayuda mucho a entender el concepto, así que vamos a plantear un ejemplo sencillo

En Javascript podemos definir funciones en cualquier momento, incluso dentro de otra función. Por ejemplo:


Ver ejemplo en JSFiddle

Dentro de la función sumar tenemos:
  • La variable total que posee la sumatoria resultante y será el resultado de la ejecución de la función
  • La función suma que agrega a total el número que recibe pro parámetro
  • Un ciclo for que recorre una serie de número de números y los suma
  • Retorno de la función: Se devuelve la sumatoria total
Lo importante del código anterior es que entendamos que una función puede convivir dentro de otra. Ahora, será más sencillo comprender que son. Vamos a un nuevo ejemplo donde usemos uno:

Ver ejemplo en JSFiddle

incrementar es un clousure porque, usando la definición que dimos arriba, incorpora una función (sumar) y su contexto (el totalizador i). Ambos, existian cuando se llamó a crearFuncion() para instanciar la variable incrementar









Leer más...

Metodologías de Trabajo - Kanban

viernes, 7 de junio de 2013


Después de varios años aplicando metodologías ágiles en nuestro trabajo, nos resulta muy enriquecedor compartir con nuestros clientes nuestra experiencia en el uso de las mismas.

En algunas reuniones que tuvimos con varios de ellos vimos cómo se entusiasmaban con la idea de empezar a implementar cambios pero se encontraban con las dudas y miedos lógicos de los equipos que quieren iniciarse en este campo. La complicación, en muchos casos, es tener que repartir las tareas diarias entre la resolución de incidentes de sus propios usuarios internos y el desarrollo planificado de mejoras o modificaciones en las aplicaciones.
Más allá de recomendar que en estos casos recurran "a su profesional de confianza" quien sabrá guiarlos en la adopción de nuevas metodologías, nos pareció interesante compartir un artículo publicado por Vikram Gupta en InfoQ, donde en un reportaje al Dr. Arne Roock - trainer y coach de Lean y Kanban (inglés) en it-agille de Alemania - twitter - nos presenta un "quick-start guide" sobre la implementación de Kanban.

Dejamos aquí un resumen del artículo en español y el link a la versión original - en inglés - del artículo Implementing Kanban in practice.

Decisión de cambiar

El punto inicial que el Dr. Roock destaca para los equipos que están evaluando empezar a implementar Kanban es que el equipo debe estar convencido y de acuerdo en la necesidad de cambiar. Agrego aquí que esa convicción es crucial para lograr cualquier cambio, independientemente de qué herramientas se estén evaluando. Además, según indica el Dr. Roock, el equipo debe acordar qué tipo de cambio quiere hacer
  • un cambio Revolucionario, es decir, algo radical que de vueltas todo "patas para arriba"
  • o un cambio "Evolucionario", algo gradual, duradero y natural, que es para lo cual Kanban está pensado.

Objetivos

En el reportaje al Dr. Roock éste aclara que para tomar Kanban como base de un cambio "evolucionario", existen 3 objetivos principales que deberían lograrse:
  • Predictibilidad y mejoras en las entregas
  • Visibilidad de las tareas a realizar, del trabajo completo
  • Feedback Interno: observar, discutir y mejorar
Con todo esto, el 1er logro de implementar Kanban es tener una visualización general del trabajo, lo cual permite ordenarlo y mejorarlo.

Primeras consecuencias del cambio

Según la experiencia que el entrevistado ha tenido, algo normal en los equipos que se están iniciando con Kanban es que al tener a la vista la dimensión total del trabajo puede aparecer como primer preocupación la cantidad real de tareas que están "En progreso" (Work in Progress), es decir, tareas sin terminar. Este es un punto importante a partir del cual se puede comenzar a administrar mejor el trabajo.
Otra cosa que suele suceder es que al mejorar en el punto anterior, las tareas se empiezan a acumular en la columna de "Testing", para lo cual no siempre la mejor solución es incorporar nuevos testers, reacción normal de los equipos con este problema. Tal vez mejorar la calidad del trabajo que llega a Test,  automatizar algunas tareas o hacer que algunos desarrolladores hagan ese trabajo pueden ser soluciones alternativas con mejores resultados.

Herramientas
La mayoría de los equpos que trabajan con Kanban tienen por lo menos algunas de estas prácticas:
  1. Daily stand-up meetings o "reuniones diarias"
  2. Retrospectivas
  3. Kaizen meetings
Además, el Dr. Roock recomienda llevar algún tipo de métricas para saber si se está yendo en el sentido correcto y se están logrando los objetivos.
Una de las herramientas que más destaca es la Pizarra (Kanban Board), que podemos ver en este ejemplo:

(imagen tomada de http://commons.wikimedia.org/wiki/File:Simple-kanban-board-.jpg)


 Ante la pregunta sobre cuáles deberían ser las columnas que formen parte de esa pizarra, el Dr. Roock dice que éstas DEBERIAN REFLEJAR LA FORMA REAL DE TRABAJO. Con lo cual, en el caso de equipos de desarrollo, por lo menos se necesitan dos, una para Desarrollo y otra para Testing.
El riesgo de tener mucha granularidad en las columnas (muchas columnas) hace que la pizarra deje de ser transparente. Para explicar esto el Dr. Roock refiere a la llamada regla de 3x3: "si se está parado a 3 metros de la pizarra, en 3 segundos debería verse fácilmente cómo va el trabajo". No se puede leer el detalle de cada tarea, pero se puede ver dónde se están apliando los papeles y dónde la gente se quedó sin cosas para hacer. Cuantas más columnas tenga la pizarra, esa visión general empieza a perderse.

La importancia de las Tareas En Progreso (WIP)

En scrum se manejan, en general, una cierta cantidad de historias que, si no se terminan en el sprint en curso pasan al siguiente, teniendo en cuenta el tiempo restante y la velocidad a la que se mueve el equipo. En Kanban esto es diferente, aunque el principio es el mismo. En Kanban se deben poner límites a los WIP - establecer una cantidad de tareas - por columnas, por swim lane o por persona. El truco está en balancear la demanda contra la capacidad, no se debe aceptar más trabajo del que se puede completar.

Cómo tratar las urgencias ("expedites")

Cualquier error que aparece en una aplicación que está en ambiente de Producción en Kanban es llamado expedite o urgencia. Si no se los atiende en forma inmediata el costo de dejarlos puede ser muy alto. En este caso una urgencia puede romper el límite establecido para los WIP. Este tipo de imprevistos debe resolverlo el equipo como tal y estar atento a la cantidad de urgencias que surgen para evaluar qué se puede hacer para achicar el costo de tener que afrontarlos.

Expansión de la práctica

Al momento de decidir la implementación de Kanban el Dr. Roock aconseja "empezar con las cosas sobre las que el el equipo tiene control" que en general están más relacionadas con temas de desarrollo. No es aconsejable involucrar en la pizarra tareas que corresponden o dependen de otros equipos. No hay que tratar de evangelizar, la mejor manera de expandir  la práctica, según el Dr. Roock, es lograr resultados y hacerlos visibles.
La idea primaria de Kanban es empezar de a poco con lo que se tiene, de a un equipo por vez, para después ir evolucionando.
Uno de los principios más importantes al empezar con esta práctica es respetar los roles actuales, los procesos y responsabilidades. Es decir, mantener los títulos, roles y responsabilidades, al menos al inicio. A medida que se va avanzando en la práctica y los miembros van ganando confianza en la forma de trabajo, se pueden introducir otros tipos de cambios.

Equipos distribuidos

Volviendo al tema de la pizarra como herramienta importante dentro de esta forma de trabajo, el Dr. Roock recomienda cómo se puede usar cuando tenemos equipos distribuidos. Si bien hay varias herramientas para Kanban en el mercado, él recomienda tratar de mantener la pizarra física presente la mayor cantidad de tiempo posible, aún estando en dos locaciones distintas. El mayor desafío es la sincrinización de los equipos, pero hoy en día hay muchos medios que ayudan a la comunicación a distancia, además de usar algún esquema de soporte ("buddy system") en cada región.
Me pareció muy interesante este esquema que sugiere el Dr. Roock. Se trata de tener un responsable en cada equipo que refleje los cambios de la pizarra que se dan en el otro equipo. Esto suena a hacer "doble trabajo", y lo es, pero por otro lado ayuda a mantener a los eqiupos comunicados no solamente para la tarea de mover los tickets.
La idea de la pizarra física ya no es tan sostenible en el caso de tener más de 2 equipos distribuidos y con grandes diferencias horarias. Aquí sí recomienda usar herramientas electrónicas además de aumentar el "ancho de banda" en la comunicación entre los miembres de todos los equipos . El objetivo principal deber ser la construcción de confianza, cosa que es más difícil de lograr a la distancia.
Buscar horarios comunes y nunca dejar de hacer las reuniones diarias, aunque sea con un solo miembro que represente a alguno de los equipos, son otras de las cosas que aconseja el entrevistado.

Consejo final

Según el Dr. Roock, lo que se trata de lograr con Kanban es entender el trabajo en sí y la manera en la que lo estamos haciendo. Este es el valor básico que tiene Kanban. SIn tener una idea clara de estos puntos es muy difícl mejorar. Con lo cual, no hay que tratar de aplicar Kanban "según los libros" sino, tratar de entender por qué son necesarios los límites a los WIP, por qué es necesaria la transparencia en el trabajo a hacer, entre otras cosas que nos permite ver Kanban.


Esperamos que este artículo sea de utilidad para aquellos que están empezando o evaluando la idea de un giro importante en la forma de llevar adelante el trabajo en equipo.

Para quienes quieran seguir entendiendo mejor Kanban, este otro artículo en español me pareció muy claro y merece ser leído Kanban como herramienta visual.







Leer más...