3P en la JSConf Uruguay 2016

martes, 19 de abril de 2016


Emoción. Esa es la sensación que nos invade mientras, en lo más profundo de nuestras mentes, presionamos el botón de rewind para revivir lo que fue nuestra experiencia en la JSConf Uruguay 2016. 3P estuvo presente en tierras orientales para formar parte de una de las mayores conferencias de JavaScript celebradas a nivel mundial y, como no podía ser de otra manera, ¡a continuación les contaremos qué tal estuvo!


Fueron dos días a pura intensidad. Dos días en los que fuimos huéspedes de una imponente, elegante y sofisticada construcción, como la es el Auditorio Antel. Dos días en los que incorporamos nuevos conocimientos, compartimos momentos gratos con gente como nosotros –apasionados de los unos y ceros– y, por supuesto, llenamos nuestros estómagos hasta donde el cinturón lo permitió.

Día uno

El responsable de la primera charla fue un compatriota, Alejandro Oviedo, quien realizó una interesante retrospectiva sobre la historia de JavaScript. Al mejor estilo DeLorean, nos trasladó al pasado, para recordarnos cómo eran las cosas 20 años atrás, y cómo en tiempos de Mocha (A.K.A. ECMAScript 1) uno podía toparse con cuestiones que hoy resultarían casi inconcebibles (¿cada vez que se disparaba un error de JavaScript se abría un pop-up? ¡No puede ser cierto!).

Luego, fue el turno de Ruth John, quien nos hizo dar cuenta de lo equivocados que estábamos con respecto al MIDI, brindándonos un pantallazo de lo que actualmente somos capaces de hacer con el hardware adecuado y ciertas APIs como la nueva Web MIDI API.

Comprendimos, entonces, que se trata de algo mucho más grande que un audio de baja calidad; es, en verdad, un protocolo de datos, con el que se pueden hacer cosas muy interesantes y divertidas. ¡Mención especial a las pegadizas animaciones y tracks con las que esta talentosa MIDI evangelist (como ella misma se autoproclama) nos deleitó durante su presentación!

"You don't need permission to be awesome".
David Neal, por su parte, supo cautivar nuestra atención con su charla sobre Electron, un poderoso framework que, básicamente, nos permite construir aplicaciones desktop empleando HTML, CSS y JavaScript. ¡Y lo mejor de todo, es que hablamos de aplicaciones ciento por ciento multiplataforma!

Tal fue nuestro interés por Electron, que al día siguiente participamos de un workshop, encabezado también por Neal, en el que pudimos dar nuestros primeros pasos con esta ambiciosa tecnología. Dicho sea de paso, los invitamos a pegarle un vistazo a éste repositorio, donde podrán encontrar diferentes ejemplos sobre Electron y más.


Otra de las grandes charlas que disfrutamos el viernes 15 (y la favorita de quién les escribe) fue la que brindó Soledad Penadés, sobre MediaCapture API y la capacidad de los browsers modernos para capturar y procesar audio y sonido. No sólo fue una presentación amena y didáctica, sino también muy divertida, gracias a los ejemplos y comentarios de color que Soledad supo brindar a cada momento.

Día dos

El día siguiente tampoco se quedó atrás, con aportes como la charla que brindó Guy Bedford sobre JSPM, un package manager ideado para trabajar con ES6, y la presentación de Juan Caicedo sobre ELM y cómo sacar provecho de los beneficios de la programación funcional.


Hubo también un espacio para las denominadas Lightning Talks, en las que los más intrépidos podían proponer un tema para exponer y, si resultaban elegidos, recibían el honor de poder realizar una pequeña presentación de cinco minutos.

Tampoco podemos dejar de hacer mención a la presentación de Alan Souza sobre SVG y la accesibilidad. Una charla que nos dejó un sabor a reflexión, recordándonos que el poder de la web está en su universalidad, y en la importancia de que todas las personas puedan acceder a la información independientemente de cualquier discapacidad.


Finalmente, ya sobre el cierre, Myles Borins y Rod Vagg hablaron largo y tendido sobre Node.js, permitiéndonos conocer más en profundidad sobre el funcionamiento de los distintos releases y el proyecto Node.js en sí (donde nos enteramos, además, que muy pronto será lanzada la versión 6).

Para ir cerrando

Difícilmente hayamos conseguido resumir todo lo que aconteció durante el 15 y 16 de abril en la JsConf Uruguay 2016. De hecho, quedaron cosas por mencionar: charlas, comidas, la fiesta de despedida, y más. 

No obstante, lo que queda claro, es que la experiencia ha sido más que positiva. Y es que, sin ninguna duda, presenciamos una gran conferencia, con grandes charlas y una bella ciudad haciendo de anfitriona.


Leer más...

Un recorrido por TypeScript

viernes, 19 de febrero de 2016


TypeScript representa la visión de Microsoft sobre JavaScript: un superset open source de uno de los lenguajes de programación más utilizados actualmente, al que le añade características que lo hacen aún más jugoso, como tipado estático, objetos basados en clases y capacidades de compilación y depuración en Visual Studio. Lo suficiente como para que ocupemos esta entrada hablando de él.

Con más de tres años en el mercado, TypeScript ha sabido ganarse un lugar en la comunidad de desarrolladores, especialmente en aquellos con largo recorrido dentro del ecosistema .NET. Incluso, causó cierto revuelo cuando, hace ya un año, se anunció que sería adoptado por AngularJS 2, la nueva versión del conocido framework.

En nuestro caso, llevamos un tiempo interactuando con TypeScript, en parte como consecuencia de un viaje aún más grande que decidimos emprender hacia tierras de Node.jsECMAScript 6. Nuestras impresiones fueron positivas, a punto tal que, en algunos de nuestros proyectos, hemos procedido a su implementación.

Todo suena muy bien, pero, ¿cómo funciona TypeScript? Echemos un vistazo a continuación.

Conceptos generales

El primer punto a destacar es que, cuando trabajamos con TypeScript, lo hacemos sobre un archivo con extensión .ts. Éste, luego de la compilación, se transforma en un .js, que será lo que finalmente terminaremos cargando en nuestra página.

El proceso de compilación se realiza directamente desde Visual Studio (siempre y cuando contemos con la versión 2013 Update 2 o superior), o bien de forma manual, a través del comando:
    tsc script.ts
Resulta interesante apreciar cómo el código generado es fácilmente legible. Además, la compilación nos genera source maps, algo que, sin dudas, supone un valor agregado importante al momento de hacer debugging.

Lo segundo por mencionar, es que al tratarse de un lenguaje tipado, nos permite definir clases, interfaces, y añadir información de tipos a los métodos. Esto es algo que podemos observar en la imagen que nos acompaña a la izquierda, donde se especifica que message debe ser del tipo string. Esto es algo sumamente interesante, ya que nos permite efectuar validaciones y detectar errores de manera inmediata, sin tener que pasar por la ejecución.



Así mismo, esto nos lleva a otro aspecto positivo, que es la posibilidad de tener toda esta información al alcance de la vista, a través de la ayuda que nos proporciona Intellisense.


El tercer punto importante, es que TypeScript es una extensión de JavaScript; esto significa, por un lado, que bajo ningún concepto estamos obligados a utilizar su sintaxis, pero, también, nos garantiza la total compatibilidad para con cualquier código ya existente escrito en JS.

Modularizando

TypeScript nos permite organizar nuestro código de dos maneras: utilizando el estándar CommonJS, o bien AMD (Asynchronous Module Definition).

Como en Node, en TypeScript tenemos las palabras reservadas export e import para exponer y acceder a los elementos de un determinado componente de nuestra aplicación.


Del mismo modo, también podemos importar librerías externas como jQuery, haciendo uso de lo que se conocen como typings. Siendo reconocibles por su extensión d.ts, estos ficheros de definición se utilizan para poder hacer referencia a dichos paquetes.

Aquí es importante hacer un paréntesis para mencionar Typings, un manager que nos simplifica enormemente el manejo de estas definiciones. Su instalación se realiza desde npm, y para más información sobre su uso, les encomendamos pegarle un vistazo al poderoso readme de su repositorio.

¿Cómo seguir?

Habiéndonos propuesto poder dar una respuesta a las preguntas fundamentales, como qué es TypeScript y cuáles son sus características principales, el primer paso ya está dado. Ahora, ya teniendo una idea más formada de lo que se esconde detrás de su nombre, el paso siguiente, y casi inevitable, es acudir a las fuentes: su vasta documentación. Una lectura ciertamente interesante, que nos permitirá aprender y comprenderlo en profundidad.
Leer más...

Google Maps, o cómo no perder el rumbo

martes, 24 de noviembre de 2015



Si en nuestro diccionario buscáramos la palabra mapa, uno de los primeros resultados en aparecer debiera ser Google Maps. Difícilmente podamos llevar la cuenta de la cantidad de veces que acudimos a este fantástico servicio de Google, ya sea para obtener una dirección, observar una calle, o, por qué no, disfrutar de un momento de recreación, visitando lugares increíbles situados a miles de kilómetros de donde estamos.

Recientemente, estuvimos trabajando en un proyecto web que nos planteaba la necesidad de contar con un mapa –en verdad, más de uno–. Y, como podrán sospechar tras leer estas primeras líneas, nuestra elección recayó sobre la API de Google Maps. Detrás de esto surge una pequeña historia; historia que, como cualquier otra, merece ser contada, y eso es, precisamente, lo que haremos a continuación:

Lo que precisábamos, básicamente, era una herramienta que nos permitiera desplegar un mapa con un importante número de puntos (localizaciones) en él; puntos a los que, de aquí en adelante, llamaremos markers (o marcadores). Inicialmente, la idea era que dicho mapa fuera estático –es decir, una imagen, sin zoom ni ninguna otra capacidad de interacción por parte del usuario–.  Los mapas estáticos de Google Maps parecían ser la opción ideal, sobre todo porque cumplían a rajatabla con esto último. Fue así como decidimos proceder a su implementación.


Desgraciadamente, no demoramos en darnos cuenta que procesar semejante cantidad de información (cientos y cientos de markers) sería una labor imposible, dadas las limitaciones técnicas presentes en este tipo de mapas, ideados para propósitos mucho más simples.

La vuelta al punto inicial fue abrupta e inevitable. Decidimos, entonces, tomarnos un momento para analizar más exhaustivamente qué otras opciones teníamos, y detectar cuál de ellas podía ser la más acertada. Frente a nuestros ojos comenzaron a desfilar diferentes servicios dedicados a la creación de mapas: ArcGIS, Mapbox, OpenStreetMap y Google Maps –en su vertiente tradicional, esto es, los mapas dinámicos que habitualmente utilizamos–.

No fue fácil tomar una decisión, fundamentalmente porque cada uno de estos nombres tenía con qué ganarse nuestra atención. Sin embargo, terminamos, una vez más, decantándonos por Google Maps. ¿La razón? Su documentación. Un aspecto para nada menor que, en este caso, fue determinante al momento de inclinar la aguja de nuestra balanza, considerando sus ricas explicaciones y ejemplos.

Manos a la obra

Hasta aquí, todo muy lindo, pero, ¿qué hay de la implementación de nuestro mapa? Lo primero por hacer es, naturalmente, cargar la API de Google Maps a través del tag script. En su última versión (3), la dirección es:

    https://maps.googleapis.com/maps/api/js?v=3.exp&sensor=false

A continuación, es necesario asignar un contenedor (div) a nuestro mapa. Dicho elemento debe contar, simplemente, con un height y un width definidos por nosotros, dejando el resto en manos de la API de Google Maps.


El siguiente paso, es definir la ubicación del mismo, algo que, como cabría suponer, se establece a partir de una determinada latitud y longitud. En nuestro caso particular, esto abrió un pequeño rompecabezas que, para ser honestos, no fue tan sencillo de resolver. El por qué, se debe al hecho de que, inicialmente, habíamos especificado un par de coordenadas fijas, con la finalidad de que el mapa apuntara a Norteamérica. Es bueno hacer un paréntesis aquí, señalando que, hasta este momento, los markers que necesitábamos mostrar en el mapa eran, en su totalidad, pertenecientes al hemisferio norte. Sin embargo, a poco de avanzar con la implementación, se sumó el requisito de poder contar, también, con markers situados en América del Sur.


Esto, como imaginarán, implicaba volver a cambiar el par de coordenadas que, previamente, habíamos definido para nuestro mapa. Algo poco práctico y, sobre todo, ineficiente, considerando que, tal vez, en un futuro, pudiera requerirse un cambio de un impacto aún mayor, como, por ejemplo, mostrar markers de otro continente.

Ante semejante panorama, nos vimos obligados a pensar en una solución más elegante o, al menos, efectiva. La respuesta a lo que buscábamos llegó a través de algo mágico llamado fitbounds.



Fitbounds es un método de Google Maps que, básicamente, nos permite posicionar un mapa y establecer su nivel de zoom tomando como referencia los markers que contiene. De esta manera, evitamos tener que asignarle un par de coordenadas fijas y, al mismo tiempo, nos aseguramos que todos los puntos que deben mostrarse lo harán.

Hablando de markers, es importante señalar que, esencialmente, son localizaciones (con su correspondiente latitud y longitud) representadas por un ícono o pin, y que, en cuyo interior, pueden contener una descripción como, por ejemplo, un texto o enlace web.

En nuestro proyecto, la información que recibíamos para poder crear estos markers provenía de Sitecore. Por esta razón, debimos implementar un método que nos facilitara y, mejor aún, agilizara el transporte de los datos. No obstante, esto mismo podría hacerse desde un simple JSON ya que, para la construcción de un marker, se requiere tan sólo un par de coordenadas.



Un último requisito que, posteriormente, se sumó a nuestro proyecto, fue el de tener la posibilidad de mostrar y ocultar determinados tipos de markers -agrupados a través de especialidades-. Para solucionar esto, debimos implementar un método que nos permitiera filtrar la lista según la opción seleccionada, estableciendo como null aquellos puntos a ignorar.


A lo largo de estas líneas, hemos intentando reunir algunos de los conceptos más importantes que formaron parte de nuestra experiencia con Google Maps. Esperemos que hayan disfrutado del viaje y, ahora, con un poco de suerte (o un teléfono con GPS), no pierdan el rumbo.
Leer más...

CSS - Por qué usar pre-procesadores: Less / Sass (conceptos básicos)

viernes, 26 de septiembre de 2014

CSS (Cascading Style Sheets) es el lenguaje utilizado para detallar los estilos y formatos de webpages basadas en contenidos creados en documentos HTML.

CSS es muy simplista, accesible y esencial para quienes hacen diseños web pero también es bastante limitado.

El problema con CSS es que cuando el proyecto empieza a hacerse más complejo es cuando saltan a la luz las limitaciones que este lenguaje presenta respecto de las necesidades de desarrollo cada vez más sofisticadas - para las cuales no fue pensado -. Si bien se fueron haciendo cambios en los features de CSS con nuevas versiones y propiedades, todavía le falta mucho para poder satisfacer los requerimientos actuales del diseño web. Esto lleva a que las hojas de estilo se hagan cada vez más repetitivas y difíciles de mantener.

Para cubrir estas necesidades aparecieron los pre-procesadores de CSS que posibilitan el desarrollo de código más ordenado, optimizado y de fácil mantenimiento.

Estos pre-procesadores no ocupan el lugar de CSS sino que ayudan en el ahorro de tiempo de desarrollo, en la creación de documentos más prolijos y en facilitar el uso de características avanzadas de estilos.

Dos de los pre-procesadores más conocidos y utilizados son LESS (Less CSS) y SASS (Syntactically Awesome Stylesheets), cuyas características comunes son:

  • permiten una mejor organización del código
  • ofrecen el uso de variables
  • implementan el uso de mixins
  • permiten reutilizar código
  • tienen funciones nativas para llevar a cabo funciones de uso común
  • dan la posibilidad de ocultar comentarios
  • permiten incluir archivos
  • habilitan el uso de namespaces

Algunas de las virtudes que resaltan quienes prefieren Less

Extensiones

Si bien Sass cuenta con una librería (Compass) conteniendo muchísimas extensiones, Less también puede usar diversas extensiones que, a diferencia de Compass que agrupa todas en un único repositorio, están dispersas y construídas por distintos desarrolladores.
Algunas extensiones disponibles para Less:

Por su simplicidad Less es ideal para quienes ya saben de CSS pero necesitan ponerse rápidamente prácticos en el uso de un pre-procesador que les ayude en sus tareas. La curva de aprendizaje puede ser un poco menos pronunciada con Less que con Sass, aunque en este punto están muy parejos.

Para algunos el sitio oficial de Less es más fácil de usar y es más vistoso que el de Sass, aunque este último ha mejorado mucho la estética y usabilidad de su sitio.

Puntos que resaltan quienes prefieren Sass

Anidamiento

Tanto Less como Sass permiten anidamiento, lo que es útil para evitar escribir selectores repetidamente. Pero Sass va un poco más allá permitiendo también el anidamiento de propiedades individuales.

Mixins y herencia de selectores

Ambos pre-procesadores ofrecen el uso de "mixins" y sólo difieren en la manera de definirlos (en Less con la directiva "@" y en Sass con class selector).

Los mixins en ambos casos se usan para incluir propiedades de un conjunto de reglas en otro. Pero Sass agrega la capacidad de herencia de selectores.

La herencia permite a los selectores heredar las propiedades de otros selectores, Sass soporta esta capacidad naturalmente mientras Less no puede hacerlo.

Documentación

En el sitio de Sass la documentación es mucha, muy comprensible y extensa. La presentación de información es muy sencilla, al estilo Wikipedia.

Por otro lado Less también ofrece buena documentación pero puede parecer más simple y directa, con mucho uso de ejemplos. En cuanto a la documentación puede parecer un poco más atractiva en cuanto a su presentación.


Consideraciones en general

Mas allá de que estas tecnologías nos ofrecen ciertas ventajas a la hora de desarrollar, por otro lado, la organización de nuestros estilos es tan o más importante que las ventajas en sí. Al final del día, que nuestro css logre ser mantenido y comprendido por todos los integrantes de nuestro equipo también es un objetivo a cumplir. Particularmente, nos estamos sumergiendo en la implementación de una guía de estilos

El hecho de que Less haya sido elegido por Bootstrap hizo que muchos se inclinaran por este pre-procesador, pensando en el "aval" que esto le daba. Sin duda le ha dado más y mejor prensa.

Por su lado Sass tiene el soporte de Google que por supuesto representa también un respaldo importante.

Sobre Sass hay varios pre-conceptos que suponen cosas como que es necesario tener un manejo avanzado de Ruby o usar líneas de comando "truculentas"  o cambiar radicalmente la forma de escribir las hojas de estilo. Nada de eso es cierto.

En general al recorrer la web se encuentra más coincidencia en que Sass es más robusto y cubre más necesidades que Less (o al menos de mejor forma).

Particularmente creo que el uso de uno u otro depende de las necesidades de cada desarrollo y las circunstancias en que tengamos que usarlo o la urgencia por empezar a aplicar un pre-procesador como estos.
Algunos de los puntos que es importante tener en cuenta a la hora de elegir:
  • Evaluar el rendimiento de cada uno para servir a los distintos tipos de necesidades del proyecto
  • Tener clara la guía de estilos y las necesidades del front end
  • Evaluar la curva de aprendizaje
  • Tener conocimientos previos de CSS
  • Recurrir a la documentación ofrecida por ambos

Links donde encontrar más información


Sobre comparaciones ambos pre-procesadores estos dos links me parecieron muy interesantes:


Para quienes quieran empezar a ver Less:  

Sobre Sass y Compass: Introducción a Saas y Compass  (en español)














Leer más...

Entendiendo la Deuda técnica

lunes, 22 de septiembre de 2014

Más de una vez nos ha pasado de estar en la encrucijada de tener que decidir si resolvemos una funcionalidad de la forma más rápida pero no tan ordenada o elegante - aún sabiendo que en algún momento habrá que modificarlo , o hacerlo más ordenado y prolijo pero sabiendo que llevará más tiempo en terminarse.

Cualquiera de las dos opciones tiene sus consecuencias pero podríamos decir que en muchas oportunidades la urgencia del cliente tiene mucho peso y terminamos decidiendo por el camino más corto.

Ese tipo de soluciones - que trasladan al futuro cambios que pueden ser más costosos que haberlos implementado en el momento -  pueden considerarse deudas técnicas y las mismas pueden resultar en altas tasas de defectos, baja velocidad de respuesta, baja calidad del producto, baja productividad, problemas de mantenimiento, entre otros. Y no debemos olvidar los costos en el presupuesto.

Las deudas técnicas pueden estar relacionadas con distintos aspectos del desarrollo: algunas pueden ser debido al código (código repetido, complejo, difícil de entender y mantener, etc.), al entorno de desarrollo, la plataforma usada, el diseño, testing automatizado y demás.

Ward Cunningham utilizó una metáfora comparando este tipo de problemas del desarrollo de software con una deuda financiera. Es decir, queremos pagar la deuda con sus intereses en el futuro o pagamos el costo completo en el presente?

Esta metáfora también "justifica" que en determinadas circunstancias la elección de la solución rápida puede ser la adecuada cuando, por ejemplo, se quiere aprovechar una oportunidad de mercado, lo que en el desarrollo de software podríamos traducir como llegar a una fecha límite.

Creo que el mayor dilema en estos casos es saber cómo administrar las deudas técnicas y tratar de determinar a qué tipo de deuda nos estamos enfrentando para tener idea de la gravedad de la misma.

Algo que puede ser útil para esto es el Cuadrante de la deuda técnia creado por Martin Fowler.

Este cuadrante podría usarse para decir qué tipos de deudas son aceptables o no y usar esta información para establecer tácticas que nos permitan prevenir conductas o patrones inaceptables.

Fowler dice que, en realidad, la gran elección no es si tener o no deudas ténicas, sino que la decisión está en tomar Deudas Prudentes o Deudas Imprudentes. Además de determinar si son Deliberadas o Inadvertidas.

Una deuda Prudente y Deliberada se da cuando el equipo sabe que está incurriendo en esa deuda y supone una evaluación del costo futuro vs. el costo actual. Este tipo de deuda se considera "positiva" y su administración se hace más simple.

Las deudas Prudentes pero Inadvertidas suelen darse en casi todos los proyectos, dado que a medida que se va desarrollando los miembros del equipo van haciendo un aprendizaje que les permite darse cuenta que hay cosas que podrían haberse hecho mejor. Mucho más se da este fenómeno si el equipo cuenta con miembros menos experimentados. En estos casos lo importante es "pesar" si vale la pena corregir lo ya hecho o qué cosas puntuales sí deberían modificarse, según el impacto que puedan acarrear.
Para Fowler este tipo de deudas son inevitables y desde el inicio del proyecto todos deberían estar advertidos de su posible aparición.

Las deudas imprudentes suelen ser tomadas por equipos que desconocen las prácticas de diseño dado que no tienen la capacidad de evaluar cuál será el costo futuro.

Una deuda imprudente y advertida puede ser un caso muy peligroso. Se da cuando el equipo, aún teniendo conocimientos de buenas prácticas, decide que escribiendo un código más limpio no puede cumplir con los tiempos requeridos. Son muchos los factores que pueden llevar a tomar esta decisión:

      • mala gestión, 
      • presiones innecesarias, 
      • problemas en el equipo interno, etc..

Acumular este tipo de deudas implica que la calidad del producto va a ser muy baja.

Por otro lado, el creer que escribir un código desprolijo es más rápido que hacer un código limpio es un error.
La aplicación de las buenas prácticas tienden justamente a que el desarrollo sea, a la larga, más rápido y el código mucho más confiable.

Las deudas imprudentes no deberían ser, además, inadvertidas porque la acumulación de las mismas llevaría al fracaso del proyecto. En general este tipo de deudas salen a la luz por inexperiencia o falta de conocimientos del equipo o de los responsables.
Ocurre en general cuando los desarrolladores no tienen noción de las implicancias de cambiar una parte del código. Este tipo de deudas deben ser administradas con mucho cuidado.

Srinath Ramakrishnan en su artículo Managing Technical Debt sugiere la utilización de herramientas como pair programming, code reviews, integración continua, testing automatizado, etc.:

"La clave para administrar deudas técnicas es estar constantemente vigilante, evitar usar atajos en el código, usar diseños de aplicaciones lo más simple posible, hacer refactoring frecuente. "


Artículos de interés:

Managing Technical Debt
When code is considered Technical Debt
Technical Debt
Deuda Técnica
Uso de técnicas agile para pagar la deuda técnica
La mala calidad del software al final se paga










Leer más...

Desarrollos Sitecore® en Latinoamérica

viernes, 19 de septiembre de 2014

Tal como contamos en nuestro sitio, una de las áreas de negocio a la que venimos abocándonos desde algunos años es el desarrollo de aplicaciones sobre la plataforma Sitecore®, lo que nos convirtió en uno de los pocos equipos de desarrollo en Sudamérica en dedicarse a la misma.

Dado que Sitecore® es, en su concepción más básica, una herramienta pensada para la construcción de sitios web corporativos e intranets, nuestro trabajo como desarrolladores consiste en la implementación de la plataforma, configuración de la arquitectura necesaria, integración de la misma con servicios externos y soporte sobre actualizaciones, entre otras tareas, de forma que los equipos del cliente puedan encargarse de la administración de los contenidos y estrategias de marketing.

Qué es Sitecore® 

Si bien Sitecore® nació como un software de gestión de contenidos, al día de hoy su punto más fuerte radica en las ventajas que ofrece al área de marketing, y se ha constituido como una de las más sólidas herramientas empresariales para la construcción de aplicaciones web, intranets y software de Automatización de Marketing. Por lo cual, y según su propia definición, Sitecore® es "una plataforma de gestión de la experiencia de usuarios".

Con más de 10 años de posicionamiento en el mercado (su primera versión apareció por 2001), la empresa multinacional danesa que lo creó cuenta hoy con oficinas en lugares como Australia, Suecia, Canadá, Alemania, , Reino Unido, y Estados Unidos entre otros.

Los usos de Sitecore® son variados pero siempre enfocados a la administración de la experiencia de usuarios y funcionalidades de marketing. Con el paso de los años ha ido unificando la actividad de múltiples canales abarcando desde el armado de campañas, seguimiento de la actividad de los usuarios (con la incorporación de los web performance for marketers, por ejemplo) hasta mediciones de performance.

Novedades de la plataforma

En la reciente presentación de los features de la próxima versión "Sitecore® 8 - #SYMNA" en Las Vegas (Sitecore® Symposium 2014) se destacó que el objetivo principal de los cambios incorporados en la herramienta está puesto en el "customer engagement".

En dicho simposio se mostró a Sitecore® 8 como una plataforma con la capacidad de implementar analíticas como base de una "máquina de marketing" personalizada, integrada con múltiples canales. Se agrega la posibilidad de trabajar con segmentación dinámica de audiencias y con testing automatizado que permite optimizar las estrategias de captación de clientes.

Además de una interfaz de usuario más simplificada, la nueva versión avanza sobre una tecnología de marketing altamente focalizada en el target de los clientes a los que apunte cada compañía que la implemente.

En cuanto a la "parte de atrás" de la herramienta, podemos decir que está desarrollada en .NET y permite integración con una infinidad de servicios y plataformas de diverso tipo.

Dada esta característica, otro de los anuncios importantes es que están trabajando en forma conjunta con Microsoft® con la finalidad de dotar a la plataforma de algoritmos de "machine learning" que agregan un valor importantísimo a uno de los objetivos de la herramienta que es el de lograr "enviar el aviso específico a la persona adecuada en el momento justo", es decir, captar nuevos clientes y lograr retenerlos fieles al producto que cada empresa ofrece.

Artículos de interés:

Sitecore Documentation
Sitecore, gestor de contenidos
Sitecore simplifies marketing with newest upgrade, Sitecore 8
Sitecore simplifica el marketing con su última versión, Sitecore 8
Sitecore Experience Platform


Leer más...

Trabajo en equipos distribuidos

miércoles, 23 de julio de 2014

Nuestra experiencia en trabajar en equipos distribuidos en distintos lugares físicos fue dándose gradualmente:

  1. pasamos de trabajar en dos oficinas separadas - por una cuestión de calidad de vida de algunas de las personas que tenían mucho tiempo de viaje -,
  2. a trabajar para clientes en el exterior - lo que implicó cambiar nuevamente algunos hábitos laborales -,
  3. hasta ser parte de un grupo de equipos de desarrollo ubicados en puntos distantes del planeta.

En este camino que llevamos recorrido hemos tenido que aprender a adaptarnos y compartir experiencias para poder llevar adelante los proyectos manteniendo el uso de metodologías ágiles.

Siguiendo consejos de quienes ya habían pasado por estos menesteres y aportando nuestro propio conocimiento y sentido común, resumimos en este artículo algunos de los puntos que nos parecen más importantes para considerar en estos casos.

Algunos puntos relevantes

Si bien en las metodologías ágiles la comunicación tiene un rol fundamental, encontramos por allí quienes aconsejan también darle tanta o más importancia a la estructuración del proyecto y la gente que va a formar parte de los distintos equipos. Ese trabajo previo debe llevar a que cada miembro tenga claro el contexto, los objetivos y los roles. En nuestra experiencia esto resultó fundamental.

Considerar algunas características culturales y tratar de unificar criterios de colaboración no sólo entre equipos sino también dentro de cada uno de ellos. Algunos de esos criterios son:
  • Definir metas estándar de distinto tipo (por ejemplo, respecto de la calidad del software, armado de prototipos, criterios de aceptación o del significado de "done", etc.)
  • Definir la frecuencia de control para cada meta, para evitar desvíos o minimizarlos
  • Definir cuándo y cómo se van a realizar las Stand up meetings, quiénes van a estar presentes y cómo se van a cargar las horas insumidas por cada equipo 
  • Definir qué herramientas se van a usar, cómo y en qué casos. Es importante entender que no existe una única herramienta que sirva para todos los fines. Si bien es necesario tratar de minimizar la cantidad de éstas para evitar duplicación de trabajo, tampoco tenemos que forzar que una sola h pueda cubrir todas las necesidades. En este punto puede servir detenerse a pensar:
    • qué necesitamos
    • qué herramientas ya tenemos (o usan los distintos equipos para cubrir esas necesidades)
    • qué herramientas nuevas necesitamos incorporar, qué uso se le va a dar y verificar que no entre en conflicto con alguna de las pre-existentes
  • Invertir en el entrenamiento de todos los equipos para el uso de herramientas, estándares en la codificación, metodologías, etc. permitirá ahorrar tiempo y errores a lo largo del proceso. Y puede ser un buen terreno de intercambio de conocimientos entre los equipos

Otros aspectos a tener en cuenta

Para lograr los objetivos cuando los equipos se encuentran físicamente distribuidos y deben ensamblarse es necesario contar con un rol de alguien que sirva como guía, gerente, scrum master, coordinador o la etiqueta que quiera ponérsele para que se encargue de aunar los criterios de trabajo, la relación con el cliente y la comunicación entre teams. Y por sobre todas las cosas debe asegurarse que los equipos puedan reaccionar rápidamente a los cambios que se presenten.

En otro aspecto, en metodologías ágiles son bienvenidas las habilidades diversas dentro del equipo. Al trabajar con equipos de diferentes culturas y niveles de conocimiento hay que ser muy cuidadosos y optimizar el uso de las distintas capacidades dentro de cada uno de  los equipos y entre los equipos dado que muchas veces pueden darse colisiones. El rol del "administrador" en estos casos es fundamental.


Por supuesto, uno de los aspectos importantes en esta forma de trabajo está referido a la creación y mantenimiento de canales de comunicación que permitan suplantar de la mejor manera los beneficios de la comunicación "presencial" o cara a cara. Pero además es necesario equilibrar la comunicación escrita con la oral para evitar el uso exagerado de una sola de las dos.

En el mismo sentido anterior, el uso de las Historias de Usuario puede tener un apartado especial. Cuando los equipos son tan diversos es posible que la adminstración de las historias requiera un detalle más exhaustivo de lo que un equipo independiente está acostumbrado a usar.
En nuestra experiencia hemos necesitado que las historias o estén complementadas con otra forma de documentación o que sea necesario el uso de una herramienta un poco diferente a la tradicional pizarra para poder llevarlas adelante. Sobre todo, porque hay que tener en cuenta que dados los distintos husos horarios y la integración con tareas hechas por otros equipos, las historias deben considerarse como lugar de conversación y de tracking de necesidades o consultas con otros miembros.
En este sentido una herramienta que nos ha sido muy útil es Assembla.

Respecto de la integración de código, Github es altamente recomendable (How Github works)
Y por supuesto Skype, GoogleDocs y Join.me son también de gran ayuda.

Más artículos de interés:

Distributed Agile: 8 ways to get more from your distributed teams
3 Surprising Reasons Distributed Teams Work Better
Fully Distributed Teams: are they viable?
The Secret Ingredients of a Successful Distributed Team

De nuestro blog:

Trabajo distribuido
Herramientas para trabajo distribuido
Reuniones diarias


(Fuentes de las imágenes:
http://2.bp.blogspot.com/-jUVasDg67s8/Ui6s1sF-MeI/AAAAAAAABho/S7Kv8NZ_yuY/s200/distributed-teams.jpg
http://qablog.practitest.com/wp-content/uploads/2012/07/ID-10064353.jpg) 


        







Leer más...

Documentación ágil

miércoles, 7 de mayo de 2014

En cuántos proyectos nos ha pasado que no encontramos la forma ideal de crear y mantener una documentación que resulte realmente útil?

Cuántas veces tuvimos que recurrir a una documentación para ver "cómo se había definido algo" o "cómo se había resuelto" y no lo encontramos o lo encontramos desactualizado?

(fuente www.freevector.com)
Particularmente me siento muy frustrada cuando pasan estas cosas porque me doy cuenta de lo difícil que nos resulta determinar en qué medida documentar y cómo sostener esto en el tiempo.

En este artículo de Jens Schauber encontré algunos comentarios y tips que me parecen muy útiles para ordenar la idea de la práctica de la documentación durante los proyectos.

Comparto un resumen de lo que dice el autor:

El concepto que me pareció más interesante es la visión que nos da sobre la documentación y que expresa al final de su artículo:
La documentación no debe ser un objetivo por sí misma. Es una herramienta para el entendimiento común y sólo debería ser creada cuando realmente aporta valor a nuestro trabajo. No debemos confundir la herramienta con el propósito que debe tener.
  • Cuando creamos documentación es necesario clarificar el propósito, debemos preguntarnos qué problema esperamos resolver con eso, qué problema trata de resolver esa documentación y resolver ese problema en la misma documentación.
  • Y no sólo eso, cuando se crea una documentación hay que pensar y tener claro desde el principio cómo hacer para mantenerla actualizada. Algo que sugiere Schauber es incluir esa tarea como parte de la definición de "Done! o agendar tiempo a intervalos regulares para dedicar a la misma. 
  • Debemos elegir formas de documentar que sean fáciles de matener: una wiki puede ser una buena idea, documentar en el código puede ser aún mejor.
  • Y algo para tener en claro según el autor: 
"lo que decididamente no sirve es tener largos procesos de aprobación de la documentación, que hará que nadie quiera actualizarlos a menos que sea obligado a hacerlo ...."

Territorios y mapas

Creo que a partir de lo anterior podemos entender mejor algunos de los tips que nos da, haciendo una analogía entre la documentación y los mapas.

Según el autor, una de las utilidades de la documentación es la de servir como guía a los nuevos. Para quienes llevan tiempo trabajando en un proyecto es fácil identificar cuáles son los puntos más importantes, riesgosos o complejos. Alguien nuevo seguramente se encuentre perdido en un territorio desconocido. Tener un "mapa" de ese terreno ayudará a que el nuevo integrante pueda ubicarse y detectar sin mucho esfuerzo los puntos estratégicos, aún cuando ese mapa no esté del todo actualizado.

Por otro lado, aún cuando se conozca bien el territorio, no siempre es fácil determinar la mejor forma de moverse entre dos puntos. Un mapa puede ayudar a darnos una visión más clara y rápida de ese problema.

A veces podemos encontrar en ese territorio "features" que no se sabe muy bien para qué estan.  Poner anotaciones en el mapa ayuda a detectar fácilmente si esos features deben quedar (y por qué) o simplemente son basura que espera ser removida.

Por último, Schauber nos dice que la documentación debe ser usada,
la documentación que no se usa es inútil

Usar la documentación sirve para notar los problemas y, a partir de eso, abordarlos.

Además, la documentación debe ser fácilmente accesible y comunicada al resto: desde imprimir y pegar en las paredes de la oficina las actualizaciones o definiciones más importantes, hasta poner un link en algún lugar al que los involucrados tengan acceso (servers, intranets, etc.)  o enviar mail, usar RSS feeds, etc., debemos buscar la forma de hacer llegar a todos las notificaciones de cambio si queremos que realmente tenga sentido el tiempo que utilizamos en mantener una documentación medianamente actualizada.


Artículo de Jens Schauber (en inglés): The purpose of documentation



        










Leer más...