Ideas 3p

3P en la JSConf Uruguay 2016

noreply@blogger.com (Jonathan Siciliano) — Tue, 19 Apr 2016 18:05:00 +0000

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.

Un recorrido por TypeScript

noreply@blogger.com (Jonathan Siciliano) — Fri, 19 Feb 2016 20:26:00 +0000

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.js y ECMAScript 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.

Google Maps, o cómo no perder el rumbo

noreply@blogger.com (Jonathan Siciliano) — Tue, 24 Nov 2015 14:33:00 +0000

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.

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

noreply@blogger.com (Andrea Morales) — Fri, 26 Sep 2014 18:00:00 +0000

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:

CSS Mixins: LESS Elements, Preboot, LESS Mixins.
Grid: 960.gs, Frameless, Semantic.gs
Layout: Even.less
Varios: Twitter Bootstrap

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)

Seguir a @3p_ar

Entendiendo la Deuda técnica

noreply@blogger.com (Andrea Morales) — Mon, 22 Sep 2014 16:37:00 +0000

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

Seguir a @3p_ar

Desarrollos Sitecore® en Latinoamérica

noreply@blogger.com (Andrea Morales) — Fri, 19 Sep 2014 17:25:00 +0000

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

Seguir a @3p_ar

Trabajo en equipos distribuidos

noreply@blogger.com (Andrea Morales) — Wed, 23 Jul 2014 13:24:00 +0000

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

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 -,
a trabajar para clientes en el exterior - lo que implicó cambiar nuevamente algunos hábitos laborales -,
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:
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3wsAFqagSKNM1OtBnF9a2GJ48mFgQmuofIUnXBr0CWDMvLc898fb4q8bOMLZ4wgrO7opYdqhvE8IAJUKZKn2VGXl91UKq9hVqYVntXYV6pZWI6Hh3LI8lV4fi7MMESwC0et6jR9GYKrM/s200/distributed-teams.jpg
http://qablog.practitest.com/wp-content/uploads/2012/07/ID-10064353.jpg)

Seguir a @3p_ar

Documentación ágil

noreply@blogger.com (Andrea Morales) — Wed, 07 May 2014 20:39:00 +0000

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

Seguir a @3p_ar

Cuando la solución es el problema (cómo prevenir la sobre-ingeniería)

noreply@blogger.com (Andrea Morales) — Mon, 05 May 2014 18:44:00 +0000

Hace pocos días leí un artículo que me pareció muy útil y cierto sobre algo que podemos reconocer fácilmente como "pecado cometido" en nuestros propios proyectos: lo difícil que resulta determinar cuándo llegamos a un punto en que estamos haciendo sobre-ingeniería o agregando features que no siempre son imprescindibles.

La visión que tiene el autor - Aneesh Karven - y los consejos que da para reconocer y afrontar este problema son muy directos y pueden ser de gran ayuda para empezar a observarnos internamente.
Les comparto aquí un resumen en español del artículo (original en inglés):

Un primer punto a destacar de la nota es que el autor entiende que el problema de muchos profesionales del software es que tienen un "exceso de confianza en la herramienta que usan y les es familiar" (por eso lo relaciona con la Ley del Martillo) lo que hace que piensen que aquello que puede ser la "solución al problema" en realidad resulta ser una exacerbación del problema. Esto hace que se generen features y fixes que dañan más que lo tienen que curar debido a las consecuencias inesperedas que suelen provocarse.

Otra de las cosas que me pareció interesante es lo que Karven sugiere como solución a estos casos de sobre-ingeniería en los que se suele caer. Como punto de partida nos dice que es fundamental un cambio de mentalidad.

Y a partir de este cambio sugiere implementar estos 2 consejos prácticos:

Preguntarse 3 cosas

Cuestionarse varias cosas antes de escribir una sola línea de código. El autor recomienda tener en cuenta estas 3 preguntas de Baumer and Silverman (en su libro When the implication is not to Design)

Podría la tecnología ser reemplazada por un enfoque igualmente viable pero no tecnológico?
Una intervención tecnológica puede resultar en más problemas o daños que los que podría provocar la situación actual ?
Es la tecnología (en este caso) un sustituto "menor" de la solución real a aplicar?

Cambiar la cultura de la compañía

Según Karven los siguientes valores culturales pueden ser útiles para prevenir la expansión descontrolada de features:

Valorar el "no hacer algunas cosas" (o "no hacer cosas"): aquí sugiere instalar conversaciones dentro de la compañía sobre "MENOS ES MÁS". Considerar qué features se pueden eliminar para mejorar el producto Esta frase que Karven cita en su artículo me pareció muy apropiada: "La perfección es finalmente alcanzada no cuando ya no hay más para agregar sino cuando ya no hay más para sacar." (Antoine de Saint Exupéry)
Documentar los caminos NO explorados: para superar la mencionada Ley del Martillo nos sugiere documentar lo que NO SE ESTÁ HACIENDO y por qué no lo hacemos, o sea, tener bien visibles las soluciones NO TOMADAS.

Continuar creciendo

A lo que se refiere en este caso es a lograr un cambio de perspectiva. Practicar esto es "practicar la humildad y precisión". El software, la gente que lo usa y las situaciones que crea pueden ser más complejas de lo que podemos imaginar. Debemos esperar sorpresas y resultados no lineales de cada intervención."
Esta otra frase dentro del artículo expresa muy bien lo que nos quiere decir "mirar en todos los rincones antes de empezar a intervenir.".

Personalmente encontré en este artículo muchos puntos clave con los que podemos identificarnos quienes trabajamos en este ámbito desde hace tiempo y creo que la mayor dificultad está en poder entender claramente que un cambio de rumbo en estas prácticas (a veces no vistas como un problema) pueden mejorar muchísimo el resultado de nuestro trabajo. Es muy común pensar que cuanto más agreguemos y tengamos contemplado dentro de nuestro código, mejor va a ser para el cliente. Pero me pareció muy clara la visión totalmente opuesta que Karven expone sobre esta creencia.

Como dice mi maestro de pintura: "una obra no se termina, simplemente se abandona", lo difícil es tener claro cuál el punto justo para hacerlo.

Este es el artículo original en inglés When the solution is the problem - How to prevent over-engineering & useless features

En el mismo sentido de este artículo, este otro artículo del autor puede ser de utiilidad How to cut features and enjoy it

Seguir a @3p_ar

Responsive y Adaptive Design

noreply@blogger.com (Andrea Morales) — Thu, 27 Feb 2014 15:08:00 +0000

Cuando se habla de Responsive y Adaptive web design suelen tomarse como lo mismo.

Pero buceando en la web podemos encontrar 3 visiones diferentes sobre estos términos: los que piensan que son dos cosas muy distintas que no tienen puntos en común ("tengo que elegir entre uno u otro"), los que sostienen que el Responsive Web Design (RWD) es un subconjunto del Adaptive Web Design (AWD) y otros (tal vez los menos?) que consideran que en realidad son dos conceptos que se complementan.

En una definición general podemos encontrar que se habla de Responsive Design cuando se piensa un sitio donde el contenido pueda ser reacomodado según el dispositivo donde se visualiza (desktop, tablet, celular, etc.) enviando siempre la misma información.

Muy genéricamente también encontramos que el diseño Adaptive se define como el diseño pensado en base a los dispositivos donde se visualizará una aplicación, diseñando una versión para cada uno de ellos, haciendo que sea el servidor el que detecte qué dispositivo lo está invocando y enviando el diseño adecuado para el mismo.

Tal como mencionamos, algunas visiones consideran al RWD como parte del AWD, como un subconjunto del mismo. Muchas puntualizan que el Resposive design tiene como objetivo el layout únicamente.

Si bien los dos conceptos tienen en común que se focalizan en permitir que los sitios puedan ser vistos en dispositivos de distintos tamaños o resoluciones buscando dar una mejor experiencia a los usuarios, Adaptive design es algo más amplio e íntimamente relacionado con la mejora progresiva, cosa de la que el RWD tampoco está ajeno. Es por ello que hay quienes consideran que ambos conceptos se complementan. Personalmente me inclino más por esta visión.

El AWD es un concepto más abarcativo y, según la definición de su creador Aaron Gustafson, utiliza mucho de los componentes de la mejora progresiva (PE - Progressive Enhancement) que se focaliza en el uso de los métodos de diseño necesarios que apunten al usuario y no a los browsers, donde el RWD debería ser una parte, pero siempre teniendo en cuenta que el AWD es un "acercamiento más holístico del diseño web".

Desde el punto de vista de los usuarios de los sitios que desarrollamos, poco sabrán ellos sobre qué métodos fueron usados para crearlos. Sólo buscarán poder navegarlos de la forma más simple, rápida y clara desde cualquier "aparato" que se los permita y si no, simplemente los abandonarán. Es por eso que las herramientas y métodos que usemos en su creación deben llevarnos siempre a satisfacer de la mejor forma posible las necesidades de dichos usuarios.

Tomar lo mejor que cada uno nos brinda para lograr este objetivo puede ser una buena idea ...

Seguir a @3p_ar

Uso de texto en lugar de imágenes (icon fonts)

noreply@blogger.com (Andrea Morales) — Mon, 24 Feb 2014 16:59:00 +0000

Desde hace ya un par de años una de las prácticas instaladas en desarrollos web es el uso de fuentes tipográficas en lugar de íconos o pequeñas imágenes o incluso sprites css. O sea, se manejan los íconos como textos lo que permite cambiar sus propiedades usando CSS.

El uso de estos “icon fonts” (icon web fonts) presenta muchas ventajas respecto de otras técnicas de inserción de imágenes dado que disminuyen la carga del servidor y las peticiones HTTP, no son tan complejos de implementar como los sprites, son adaptables a distintos dispositivos (los íconos pueden verse pixelados al cambiar de tamaño), se puede cambiar fácilmente sus propiedades, entre otras.

Varios son los sitios donde podemos encontrar conjuntos de font-icons – gratuitos y pagos - y abarcan una enorme variedad de temas. Algunas de estas colecciones hemos aplicado en nuestro web site.

Recomendamos aquí muy buenos artículos donde pueden leer más detalles sobre su implementación y sitios desde donde descargar colecciones:

Ksesocss

CSS Tricks

Experiencias de desarrollo web

WordPress Mallorca

DisasterCode

CodigoAdicto
4R Soluciones

(imagen: htttp://commons.wikimedia.org/wiki/File:Early_writing_tablet_recording_the_allocation_of_beer.jpg)

Seguir a @3p_ar

Probando Pentaho VI: esquema de un cubo con Mondrian

noreply@blogger.com (Lucila Santos) — Fri, 14 Feb 2014 19:38:00 +0000

En un artículo anterior vimos que construir un esquema Mondrian adecuado es la base para cualquier análisis y visualización.

Comparto ahora algunas pruebas realizadas con Mondrian. Utilicé la documentación provista por Pentaho.

Esquema Mondrian

Un esquema define una base de datos multi dimensional. Contiene un modelo lógico. Este modelo a su vez debe mapear a un modelo físico.

El modelo lógico consiste en las estructuras usadas para escribir consultas en lenguaje MDX. Esta formado por cubos, jerarquías, niveles y miembros.
El modelo físico son las tablas de datos presentados previamente en el modelo lógico.

Los esquemas Mondrian son archivos de tipo xml. Se pueden editar manualmente, o bien por medio de la herramienta Workbench provista por Pentaho.

Workbench

Mondrian Schema Workbench es una aplicación que permite crear visualmente y testear esquemas Mondrian de cubos OLAP.

Creación del esquema de un cubo usando Workbench

1. Instalar Mondrian, que se puede bajar desde Source Forge
2. Descomprimir en el directorio donde se instalo el server de Pentaho.

3. Incluir el driver JDBC en el directorio 'Drivers': schema-workbench/drivers
4. Con el server de Pentaho activo, iniciar Workbench, (schema-workbench/workbench.bat ) obteniendo una pantalla del tipo

5. Conectarse a la base de datos, desde la opción 'options' del menú principal. Los parámetros para crear la conexión son los mismos que en el caso de la consola de usuario de Pentaho.

6. Este es un ejemplo de esquema de un cubo. Consulta la base en SQL 'AdventureWorksDW'. Tomando como tabla de 'hechos' o fact table FactInternetSales. La medida utilizada es 'SalesAmount'. Las dimensiones, dos básicas, son el tiempo (DimTime) y Región (tabla DimSalesTerritory).
Crear o editar los elementos en el esquema. Workbench valida los cambios contra las tablas del cubo y los nombres de las columnas.

En este caso, construimos la dimensión 'Region' contra la tabla 'DimSalesTerritory'.

7. Para ver el código XML que subyace detrás del esquema, seleccionar View/XML. Muestra el XML del elemento actual, pero no se puede editar este archivo directamente.

<Dimension type="StandardDimension" visible="true" foreignKey="SalesTerritoryKey" highCardinality="false" name="Region">
<Hierarchy name="Region" visible="true" hasAll="true" allMemberName="TODOS" primaryKey="SalesTerritoryKey">
<Table name="DimSalesTerritory" schema="dbo">
</Table>
<Level name="Region" visible="true" column="SalesTerritoryRegion" nameColumn="SalesTerritoryRegion" type="String" internalType="String" uniqueMembers="true" levelType="Regular" hideMemberIf="Never" caption="Region" captionColumn="SalesTerritoryRegion">
</Level>
</Hierarchy>
</Dimension>

8. Probar que la estructura sea correcta, para esto abrir el editor de MDX y conectarse. Si se hay algún error o campo mal indicado no se conecta y da error.

En ese caso muestra los resultados de la consulta MDX básica.

Resultaron de utilidad los artículos del blog Adventures with Open Source BI

Seguir a @3p_ar

Probando Pentaho V: instalando Pentaho 5 - Saiku Analytics

noreply@blogger.com (Lucila Santos) — Thu, 16 Jan 2014 15:54:00 +0000

La nueva versión de Pentaho BI-Server 5.0 está disponible.
Hay varias novedades, entre ellas una nueva interfase, mucho más moderna y amigable que la anterior
Por otro lado, la consola de usuario (Pentaho User Console) y la consola de adminstración están integradas, con lo cual no es necesario ahora configurar un server extra.
Se ha mejorado la instalación de plugins por medio de MarketPlace.

Instalamos entonces la nueva versión de Pentaho. El cambio que más nos gustó fue la presentación más moderna y austera, con una paleta de colores muy amigable. También el acceso fácil a todos los elementos.
Este es el detalle de los pasos básicos que seguimos para tener Pentaho 5 andando:

Instalación.
Conexiones a las bases de datos.
Creación de Data Sources y consultas MDX.
Presentaciones y gráficos.

-1- Instalación

La instalación fue simple, bajamos los archivos desde Pentaho Community (biserver-ce-5.0.1-stable)

-2- Conexiones

Las conexiones: basta instalar el driver adecuado en los directorios y crear la conexión en sí

Drivers: driver para acceso a SQL. jtds-1.3.0.jar en los directorios:

bi-server/data/lib
bi-server/tomcat/lib

Creación de una conexión. Desde la pantalla de Pentaho:

File /New/DataSource

SQL query, pantalla de selección de conexiones, agregar una nueva:

-3- Data Sources y consultas MDX.

Una diferencia importante en esta nueva versión de Pentaho es la posibilidad de configurar data sources. Se puede crear un data source a partir del esquema de un cubo creado con Mondrian. Basta tener el xml asociado al cubo. No es necesario publicarlo como en versiones anteriores de Pentaho.

Manage DataSources/ DataSource/ New Analysis

Seleccionar el archivo .xml correspondiente al esquema Mondrian generado por Workbench, y seleccionar el data source correcto.

El data source importado, cuya base es un cubo, se puede ver por medio de Jpivot y Saiku analytics. La creación de las consultas y gráficos es bastante intuitiva.
JPivot: permite, de una forma interactiva, analizar los datos del Data Warehouse a traves de una interfaz de tabla cruzada donde podemos navegar por las diferentes dimensiones definidas en el modelo dimensional.

Create New/ JPivot View permite seleccionar entre los cubos creados. En este caso, seleccionamos un cubo construido a partir de ventas de internet. Con solo dos dimensiones, región y tiempo. La consulta MDX relacionada es

select NON EMPTY [Region].[Region].Members ON COLUMNS,
NON EMPTY {Hierarchize({[Time].[Years].Members})} ON ROWS
from [InternetSalesRegionTime]

(de la base AdventureWorksDW)

-4- Visualizaciones

Para probar Saiku Analytics, fue necesario descargar el plug-in por medio de la opción 'MarketPlace' desde la consola de usuario de Pentaho.

Create New/ New Saiku Analytics permite armar consultas y generar gráficos.
Estas son las consultas al mismo cubo que abrí con JPivot y gráficos generados. Tomé para el ejemplo un caso sencillo, pero muy ilustrativo.

Consulta Ventas por Región y Tiempo

Ventas por región por año

Gráfico líneas ventas por región

Región en las columnas y años para las filas

Mismo gráfico detalle por mes.

A mi entender es clave partir de un esquema Mondrian adecuado. En un próximo artículo compartiré un par de consejos para crearlos.

Seguir a @3p_ar

Por qué los rituales son importantes en Agile

noreply@blogger.com (Andrea Morales) — Thu, 16 Jan 2014 13:57:00 +0000

Cuando leí este artículo de Len Lagestee sobre los rituales en Agile recordé una reunión de equipo que tuvimos hace algunos años donde revisábamos nuestra práctica de Scrum cuando recién empezábamos. Una de las conclusiones a las que llegamos en ese momento fue que los rituales de Scrum, en nuestro caso, son tan pocos y tan simples que no tiene sentido querer "darles una vuelta" o tratar de adaptarlos. Scrum es eso y cualquier cambio que se le quiera agregar lo convierte en otra cosa. Y lo mismo aplica a cualquier otro método ágil.

Con el tiempo y hablando con gente de otros equipos noté que eso que nosotros intentábamos (tal vez cierta resistencia inconciente?) es bastante común entre quienes empiezan con un cambio de metodología: queremos hacer una "adaptación libre" o una versión ajustada de la práctica. Es por eso que me pareció interesante resumir los conceptos de Len Lagestee sobre la importancia de respetar y mantener los rituales en de las metodologías ágiles.

Según Lagestee, una de las primeras dudas o quejas que despierta la práctica de metodologías ágiles es "la cantidad" de reuniones, dependiendo dle método las típicas son: planificación, daily stand-up, revisión del sprint o demostración, retrospectiva, revisión del backlog. El sólo hecho de pensar en tantas reuniones lleva a decir que "no habrá tiempo para trabajar". En estos casos es donde el autor subraya justamente la importancia de mantener estas prácticas: el tiempo que un equipo comparte junto, con un ritmo recurrente y consistente, es donde se fomentan las bases de los rituales de ese equipo.
En este punto Lagestee resalta una definición de wikipedia al respecto:

"los rituales hacen a la tradición de una comunidad"

http://milindageorge.files.wordpress.com/2013/03/scrum-team.png

Continúa diciendo Lagestee en su artículo que concretamente la importancia de los rituales está dada porque los mismos refuerzan las tradiciones de:

Reconocer el pasado: las retrospectivas permiten aprender de la experiencia pasada en un sano entorno de "comunidad". El equipo es el que aprende a corregir su propio rumbo.
Marcar nuevos comienzos: más allá de las conclusiones sacadas para el sprint pasado, la planificación de un nuevos sprint permite a la "comunidad" (es decir, al equipo) centrarse en lo que viene por delante.
Tomar decisiones: la reunión de planificación y el timeboxing establecen la tradición de las "decisiones" => "podemos como equipo completar estas historias en este sprint o no?"
Desatar movimiento: las reuniones diarias sirven para poner en movimiento al equipo, trabajando mancomunado desde el inicio del día. Según nuestra experiencia, la reunión diaria establece el espacio explícito donde sabemos que contamos con los otros para darnos una mano cuando estamos complicados con algo.
Crear conexiones: compartir las reuniones diarias asegura que todos los días haya un punto de conexión entre todo el equipo. Y cuando alguien no esta, se siente la ausencia. Len Lagestee compara esta práctica con el ritual de la cena en familia: es el momento en que todos se juntan para contar cómo les fue en el día. Puede parecer aburrido o sin sentido hacerlo con tanta frecuencia, pero la realidad es que cuando no se hace, sentimos que algo falta. En la experiencia particular de Tercer Planeta es casi imposible pensar en arrancar el día sin la reunión diaria.
Celebrar con los demás: las sesiones de revisión del sprint son los momentos donde el equipo puede reconocer y valorar realmente los logros del trabajo en conjunto.

Algo que aclara el autor es que es absolutamente normal al principio sentir que tenemos los días llenos de reuniones, pero al persisitir con el equipo en lograr un punto de verdadera comunidad, estas reuniones se vuelven más y más efectivas y se adoptan naturalmente porque se ven sus beneficios.

Desde nuestra experiencia podemos asegurar que esto es así, nos ha pasado de tener las mismas dudas mencionadas respecto de "tanto tiempo" destinado a reuniones pero hemos comprobado que el tiempo invertido en ellas deja ver sus frutos en la velocidad de producción y en la calidad del producto terminado, entre muchas otras ventajas que nos dan estos rituales.

Why the rituals of agile matter (por Len Lagestee)

Otro artículo que puede resultar también interesante: La importancia del respeto los rituales (en Agilmática)

Seguir a @3p_ar

Primeros pasos con Pure, un framework css modular, liviano y completo

noreply@blogger.com (Cristhian Duran) — Wed, 15 Jan 2014 20:14:00 +0000

Qué desarrollador hoy en día no implementa algún framework css como base al construir la maquetación de sus sitos/aplicaciones web? Todos deberíamos usar alguno ya que son muchísimas las ventajas que nos ofrecen.

Pero "primero es lo primero".....

A manera de repaso (o por si no conocés del tema) comentemos que un framework css es un conjunto de herramientas, style sheets y buenas prácticas que permiten al desarrollador olvidarse de estilos y funcionalidad que va a utilizar en muchos lados para centrarse en los elementos únicos de cada diseño en los que puede aportar valor.

Un framework css puede incluir solo archivos .css o bien algunos .js para complementar algún proceso como un diálogo modal.

El ejemplo más destacado en este ámbito es el famoso Twitter Bootstrap, un muy usado framework css, que tiene todo lo que el desarrollar necesita para construir aplicaciones totalmente funcionales sin mucho esfuerzo. Contiene estilos y funcionalidad para maquetación por medio de grillas, estilos para todos los elementos, formularios, slides de imágenes y formularios modales, entre otros.

Pero a veces nuestros proyectos no son lo suficientemente grandes como para necesitar semejante framework y fue en uno de esos momentos de duda cuando conocí a Pure.

Pure es un framework css muy pequeño, modular y que tiene todo lo necesario para un proyecto web de hoy en día. Está contruido sobre normalize.css. Sus características más destacadas (a mi criterio) son:

Es MUY liviano: Pesa apenas 4.4 kb.

Está construido en pequeños módulos: Uno para estilos generales, otro para construcción de grillas, botones, formularios y uno podría solo incluir el que le interese en su proyecto.

Es completo: No incluye ningún .js, ni construcción de elementos gráficos muy sofisticados como un slider pero aún así es lo suficientemente funcional como para construir un sitio de manera sencilla y que respete las buenas prácticas de maquetación.

Es responsive: Como todo buen framework css, piensa en los dispositivos móviles.

En el sitio web se pueden encontrar algunos ejemplos básicos construidos con Pure que muestran su poder y se puede descargar: blog, landing page, pricing table y otros.
La documentación del sitio es muy buena y sencilla de entender. Podría decir que no tiene curva de aprendizaje más que unos pocos minutos o un breve repaso sobre la documentación.

Que esperan para involucrar a Pure en sus proyectos?.

Seguir a @3p_ar

Open Data

noreply@blogger.com (Lucila Santos) — Fri, 13 Dec 2013 13:38:00 +0000

Uno de los temas de interés en Tercer Planeta es Open Data.

http://galecia.com/blogs/lori-ayre/open-data-movement-great-graphic

Las conferencias de las Octavas Jornadas de Data Mining nos impulsaron a investigar, explorar varios links y discernir sobre los alcances del mismo. Aquí un resumen:

¿Qué es Open Data?

Podríamos definir Open Data como la publicación sistemática de datos. Es una filosofía y práctica que propone que determinados datos estén disponibles de forma libre a todo el mundo, sin restricciones de copyright, patentes u otros mecanismos de control.

Open Data se relaciona con otros movimientos abiertos: open source (código y tecnología), open governance (decisiones y recursos) y open innovation (conocimiento). Estamos hablando de información de gestión, recursos compartidos, transparencia, colaboración y participación.
Surgen varios desafíos, entre ellos el entender a Open Data como un servicio público y entender que esta información es un derecho ciudadano. Sin olvidar las responsabilidades que este nuevo derecho implica.

http://www.flickr.com/photos/notbrucelee/5241176871/

Una de las primeras definiciones de open data fue publicada por la Unesco: directrices para políticas de acceso abierto:

"Mediante el Acceso Abierto, los investigadores y estudiantes de todo el mundo alcanzan cada vez más acceso al conocimiento, las publicaciones obtienen mayor visibilidad y número de lectores y el impacto potencial de la investigación es fortalecido [..] facilitan las oportunidades para el desarrollo económico y social equitativo, el dialogo inter cultural y tienen el potencial de estimular la innovación."

En 2007 el grupo de trabajo denominado Open Government Working Group reunido en Sebastopol
(California, EE.UU.) propuso estos 8 principios para la liberación del acceso a datos gubernamentales, los cuales se han convertido en la base de un estándar de facto.
Así, se denomina liberación del acceso a datos gubernamentales (open government data) a: la puesta en disponibilidad pública por parte de los estados de datos en forma digital a través de Internet de manera que permita y promueva su análisis y re utilización.

El acceso a datos gubernamentales se considera abierto si los datos son puestos a disposición del público cumpliendo con los siguientes principios:

Hay comentarios muy lúcidos respecto a la aplicación 'real' de estos principios, en el blog de Alejandro Barros.

¿Qué es consumo de datos?

La apertura de datos no es un fin por sí misma. El consumo de datos sí.
Entendamos que no basta con tener datos disponibles, es necesario poner manos a la obra para que se pueda sacar provecho de los mismos.

El consumo de Datos Públicos debería cumplir etapas:

1. Obtener los datos: implica el uso de datos publicados por distintas organizaciones
2. Asegurar el derecho a utilizar los datos: (tema de licencias, permisos)
3. Procesar los datos: (Analizar, entender, limpiar, relacionar de forma transparente, re producible)
4. Publicar
5. Hacerse cargo de lo realizado, en particular, posibilitar la reproducción y ser responsables de una retro alimentación a las fuentes

Data Journalism

De acuerdo con el interesante Data Journalism Handbook, podríamos decir que es Periodismo a partir de Datos. Ambos términos, 'data' y 'periodismo' son difíciles de definir.

Para muchos, 'data' es una colección de números, a lo sumo reunidos en una hoja de cálculo. Hasta ahora, este tipo de datos fueron los que los periodistas enfrentaron, pero hoy por hoy toda nuestra vida se podría definir con números, unos y ceros. Desde documentos hasta conexiones entre distintos usuarios, por ejemplo.

Qué diferencia al periodismo de datos del periodismo en general? Quizás las nuevas posibilidades que surgen al combinar el olfato por las noticias, con la habilidad para contar buenas historias y la magnitud de la información digital ahora disponible.

Data puede ser la fuente del periodismo de datos, puede ser la herramienta para contar una historia, o puede ser ambas. Debe ser tomado con el mismo escepticismo con el que se toma toda fuente, y como herramienta requiere tomar conciencia de la forma en que esta puede orientar y sesgar lo que se informa.

Las tecnologías de la información están cambiando la forma como se publica la información pública. El Periodismo de Datos es una nueva rama, y tiene un papel importante en la capacitación masiva de lectores que puedan comprender la información publicada.

En esta tarea es fundamental:

La recopilación y el asociación de diversas fuentes de datos no relacionados previamente.

El procesamiento de los datos que permita sintetizarlos (deductivamente) o generalizarlos (inductivamente) para explicitar conocimientos que no son accesibles directamente.

La visualización adecuada que permita que esta información “penetre” en el usuario de una manera física, sensorial y hasta irracional.

Armamos esta lista de portales de datos oficiales y de buenos ejemplos de consumo de datos:

Estados Unidos e Inglaterra son buenos ejemplos de publicación de datos como servicio público.
En Argentina, Datos Públicos, la sección de datos de La Nación, y en particular los Data Fest que congregan diseñadores, periodistas y programadores con el fin de presentar conjuntos de datos interesantes.
Es muy ameno también Chequeado, con una ingeniosa presentación de noticias usando datos.
En España, Datos propone reutilizar la información pública
Data Publica en Francia.
Google propone Public Data.

Hablando de Periodismo, varios de los premios 2013 corresponden a visualizaciones hechas a partir de datos públicos.

Finalmente, podemos profundizar estos temas, con la ayuda de Jornalism in the Age of Data y el Data Journalism Handbook mencionado previamente.

Seguir a @3p_ar

De JSON a objeto dinámico C#

noreply@blogger.com (Cristhian Duran) — Mon, 02 Dec 2013 12:47:00 +0000

La anterior semana me encontré con el reto de usar un JSON gigante, que tenía alrededor de 22.000 líneas de código, para simplemente ciclar por una de sus colecciones y extraer no más de 5 campos. Me pareció una locura intentar siquiera sumergirme en entender cómo estaba estructurado, qué colecciones tenía, etc.

Googleando bastante, encontré un Nuget que les puede facilitar mucho esta tarea: DynamicJson

DynamicJson es un Nuget, disponible a partir del framework .NET 4.0, que nos va a proporcionar una clase que transforma un JSON en un objeto dinámico con esta simple sintáxis:

 
    var myObj = DynamicJson.Parse(myJSON);

Como resultado, obtenemos un objeto iterable que respeta la estructura del JSON con todos sus valores y cuyo contenido es muchisimo más fácil de explorar, pasando de esto:

A esto:

Se nota la diferencia?

Este Nuget, además, nos proporciona algunos métodos para verificar existencia de algúna propiedad, eliminar elementos, serializador, deserializador y acceso a sus propiedades por medio de notación C#.

Espero que les sea de utilidad.

Seguir a @3p_ar

Octavas Jornadas de Data Mining

noreply@blogger.com (Lucila Santos) — Wed, 27 Nov 2013 17:57:00 +0000

El 26 de octubre pasado tuve la oportunidad de asistir a las Jornadas anuales que organiza la Maestría en Exploración de Datos y Descubrimiento del Conocimiento, en la Facultad de Ciencias Exactas, de la Universidad de Buenos Aires.

Logo Maestría (UBA)

El tema principal fue de especial interés, puesto que se enfocaba en Visualización, tema que venimos abordando en Tercer Planeta.

Algunas apreciaciones

Muy buena la presentación de Visual Analytics (SAS). Mediante esta herramienta es posible representar en forma gráfica grandes cantidades de información. Permite tener una vista general de los datos, aplicar zoom y filtrar, y mostrar detalles a demanda, teniendo en cuenta el mantra de visualización de Ben Shneiderman.
Se relacionó con visualización la conferencia sobre Técnicas de Visualización de Sistemas Complejos en Bio informática, donde se postuló la necesidad de superar la problemática de la cantidad y heterogeneidad de los datos.
La presentación de Claudio Delrieux (UNS) destacó las Problemáticas Actuales de la Visualización en Big Data: volumen, velocidad, variedad, verosimilitud y valor (las 5V).
Finalmente, Alejandro Baranek presentó sus trabajos en la conferencia “Visualización experimental en 3D”.

Otro tema de interés en las jornadas fueron la búsqueda de artículos científicos en la web y Open Data.

Djamel Abdelkader Zighed, invitado especial de la Universidad de Lyon, trató el problema de la complejidad en el proceso de búsqueda de artículos científicos en la web y su posterior análisis entre millones de referencias disponibles. Al respecto señaló que la dinámica de crecimiento de los datos abiertos en Internet, conocida como Open Data, y la ambigüedad existente en los nombres de los autores de los artículos, vuelve imprescindible implementar una metodología en minería de datos. Como ejemplo de ello, Zighed mencionó la herramienta Babel, que cuenta actualmente con interesantes resultados para refinar la información de las bibliotecas digitales.

La conferencia “Open Data: oportunidades y desafíos para el Estado, la sociedad y la industria”, permitió ubicarnos en la realidad actual del tema, siendo de particular interés los ocho principios de gobierno abierto, declarados por la UNESCO. No hay dudas de la oportunidad que se abre a partir de esta área.

Seguir a @3p_ar

Factores a considerar en la elección de un CMS

noreply@blogger.com (Andrea Morales) — Tue, 19 Nov 2013 16:41:00 +0000

Como hemos mencionado en otras oportunidades, llevamos una larga experiencia trabajando con los departamentos de RRHH, Comunicación y Marketing de empresas nacionales y en el exterior. Y a medida que fue pasando el tiempo hemos visto que la necesidad de organizar, centralizar y ordenar lo que se quiere exponer, tanto en el área interna como en el aspecto público, creció enormemente y a gran velocidad.

Evidentemente la tecnología ha acompañado y fomentado este crecimiento ganando una gran incidencia en los sectores antes mencionados y ayudando con muy variadas herramientas (ver artículo Incidencia de las TIC en la gestión del Capital Humano). Un ejemplo de las mismas son los CMS (Content Management System) es decir, sistemas para la administración de contenidos de sitios web, internos o públicos, que han tenido un gran crecimiento desde hace varios años.

Imagen: sictanet.org

Si bien existen en el mercado CMS de muy variadas características y precios, en determinado tipo de empresas hemos comprobado que las mejores opciones se encuentran entre CMS pagos (hay compañías que tienen una larga trayectoria en productos muy sólidos) o CMS hechos a medida. De hecho, venimos acompañando a organizaciones que mantienen una combinación de estos dos tipos de herramientas para su sitio público y para sus intranets.

Esto no quita, por supuesto, mencionar que existen varias opciones de CMS gratuitos, muchas muy buenas, pero más apropiados para objetivos y empresas con características diferentes a las que nos ocupan en este artículo.

Qué es un CMS?

A grandes rasgos un CMS consta de 2 partes:

Administración de contenidos: o sea, una aplicación a través de la cual los editores o encargados de contenidos ingresan las notas, artículos, archivos, etc. que quieren mostrar en el sitio, definen en qué categoría ubicarlos, en qué "zona" dentro del diseño definido, cuándo publicarlos, etc.. Un buen CMS debe incluir también un sistema de permisos confiable, permitir la modificación de ciertas configuraciones como así también la asignación de distintos roles a diferentes usuarios.
Presentación de contenidos: que es la aplicación encargada de mostrar los contenidos programados por los usuarios correspondientes desde la aplicación anterior para las distintas vistas, idiomas y dentro del diseño previamente definido.

Factores a considerar

Qué puntos se deben evaluar cuando se quiere cambiar o incorporar por primera vez un CMS?

Volatilidad de contenidos: Si bien son varios los factores que hacen a una compañía decidir invertir en un CMS, uno de los que más influye es la gran volatilidad de los contenidos a comunicar. Esto aplica tanto a intranets como a sitios públicos donde se necesita administrar de forma autónoma, rápida y verstátil los diferentes tipos de información (textos, imágenes, videos, sonido, archivos, etc.)).
Tamaño de organización y dispersión geográfica: Otro de los puntos a considerar es el tamaño de la organización y su dispersión geográfica. Para el caso de empresas que reparten sus sedes entre varios países e idiomas, el CMS a elegir deberá contar con determinadas características que, seguramente, no serán requeridos por otro tipo de empresas.
Variedad de datos y funcionalidades: Por otro lado, es necesario considerar el tipo y variedad de datos que la organización quiere manejar a través del sitio para poder seleccionar un CMS que sea capaz de administrar la complejidad de contenidos que la empresa requiere.
Seguridad: Por supuesto, la seguridad de la información es otro de los puntos críticos y prioritarios.
Escalabilidad: Es importante también visualizar el rumbo que tomarán los portales y pensar que la herramienta que se elija tenga una flexibilidad tal que permita escalabilidad en cuanto a diseño, contenidos y funcionalidades en general.
Integración: Otro tema a tener en cuenta es que el CMS elegido pueda integrarse fácilmente con otras aplicaciones utilizadas en la organización para intercambio de información.
Curva de aprendizaje: Un punto fundamental es que la curva de aprendizaje de utilización de la herramienta no sea muy alta. Una de las características primordiales es que el CMS elegido sea de fácil uso para que los responsables puedan utilizarlo sin dificultad, sin riesgo de cometer errores y sin oponer resistencia al mismo.
Soporte: algo fundamental a considerar es que el lenguaje utilizado para el desarrollo de una herramienta como esta sea ampliamente conocida, sólida y confiable.

Imagen: gestiondepymes

Para el caso de CMS más complejos, que permitan cubrir necesidades avanzadas o desde los cuales se deban administrar funcionalidades más sofisticadas, es necesario tener en cuenta que se debe contar con personal capacitado para la administración del mismo.
Para firmas de cierto tamaño y caracteristicas, obviamente será necesario disponer de un equipo interno o externo que se encargue del mantenimiento de determinados componentes de la herramienta, su integración con otras aplicaciones de la empresa y el control de la instalación e infraestructura de la misma.

Si bien puede no resultar simple encontrar un único producto que satisfaga 100% estas y otras necesidades, hay que tener en cuenta que las herramientas pagas suelen tener una enorme variedad de posibilidades, soporte técnico de muy buena calidad y comunidades que ayudan a difundir y optimizar el uso del producto. En estos casos la evaluación crucial está en determinar el retorno de inversión que se obtendrá versus el pago de licencias por la compra del producto, si ese fuera el caso.

Pensar en un CMS a medida nos permite contar con la posibilidad de adaptar las funcionalidades del mismo a las necesidades exactas de la organización, escalabilidad en la medida que se necesite y personalización de determinadas funcionalidades cuando sean requeridas. Esta opción no tiene por qué necesariamente estar siempre asociada a la idea de "quedar atado" a un solo proveedor, pago de abonos interminables o riesgo de no tener soporte. Una herramienta estabilizada y bien construida evita tener que lidiar con estos problemas.

En la experiencia que tenemos vemos que una buena combinación de usuarios expertos, usuarios de funcionalidades más básicas y un equipo de desarrollo y mantenimiento pequeño - interno o externo a la organización - da excelentes resultados en cuanto a velocidad de respuesta, calidad y eficiencia en el uso de este tipo de productos.

Seguir a @3p_ar

Scrum - Impedimentos

noreply@blogger.com (Andrea Morales) — Tue, 05 Nov 2013 14:02:00 +0000

Muchas veces nos ha pasado en nuestro trabajo encontrarnos con eventos o situaciones imprevistas que nos obligan a buscar soluciones creativas para continuar según lo planificado o que nos llevan a modificar directamente la planificación hecha, con el cambio de humor que esto implica dentro del equipo. Este tipo de situaciones o eventos son lo que llamamos impedimentos.

Cuando recién empezamos con Scrum nos resultaba muy difícil comprender qué hacer con estas cosas y cómo tratarlas. Algo que nos sirvió y que me parece fundamental es entender claramente de qué se trata y cómo identificarlos.

Entonces, qué es realmente un Impedimento? De las muchas definiciones que al respecto podemos encontrar, la que más me gusta es la que ve a los impedimentos como cualquier obstáculo que bloquea o demora el progreso del equipo. Es decir, cualquier situación que impide a una o más personas del equipo continuar con su tarea, con su correlativo impacto en el progreso del sprint en el que estén trabajando y/o en el backlog general.

Y algo que nos ayudó mucho a "aceptarlos como tales" fue comprender que no hay team que no se encuentre con trabas de cualquier tipo que impacten en los Sprint. Que todos los miembros del equipo entiendan esto suele ser "liberador" ....

Cómo detectarlos

Estas trabas o imprevistos surgen durante el trabajo diario y DEBEN ser comunicados al resto del equipo, en general durante las reuniones diarias. Pero, dado que uno de los roles más importantes del Scrum Master (SM) es el de eliminar los problemas para lograr la mayor eficiencia del team, es esperable también que sea él quien tenga la capacidad de estar muy atento a buscarlos y detectarlos.
Por otro lado existe una contrapartida a este rol del SM y es la responsabilidad que tiene el equipo de comunicarle, en cualquier momento, la aparición de toda situación que impida o retrase una tarea , para que ese problema pueda ser tratado adecuadamente.

Y, por supuesto, las retrospectivas son el mejor momento para exponer, identificar y categorizar todas las "molestias" surgidas durante el sprint.

En resumen, tanto las capacidades del SM como una fluida y abierta comunicación dentro del team son fundamentales para la detección, reconocimiento, tratamiento y resolución de los impedimentos.

Tipos de impedimentos

Una posible clasificación de los impedimentos se basa en el tratamiento que necesiten:

Impedimentos del equipo, que son los típicos problemas que pueden ser resueltos dentro del team, ya sea tomando medidas internas para evitar que se repitan, estableciendo cambios en la forma de trabajo, definiendo el uso de nuevas herramientas, etc.

Impedimentos de la organización, que son problemas que dependen de otros para ser resueltos como temas de infraestructura, demoras en los entregables de otros equipos, entre otros.

Ejemplos típicos de impedimentos:

Enfermedad de algún miembro del equipo
Operaciones de mantenimiento de hardware o software corporativo que afecten la continuidad de las tareas planificadas
Interacción con proveedores que no cumplen con los plazos o los servicios comprometidos. Este es, tal vez, uno de los impedimentos más preocupantes dado el poco margen de intervención que puede llegar a tener el SM para solucionarlo
Ausencias o poco compromiso del Product Owner que demora la toma de decisiones o aprobaciones. Particularme este caso lo hemos sufrido en algunos de nuestros proyectos y representa realmente un gran problema, la clave está en tratar de mantener un muy buen diálogo con el PO y hacerle notar la importancia de su presencia durante todo el proceso y las consecuencias que puede provocar su no involucramiento
Un backlog mal definido o con requerimientos que no estén listos o bien detallados para iniciar la planificación del sprint
Reuniones largas, innecesarias o que involucren a miembros del equipo que podrían no estar, restándoles tiempo para avanzar según lo planificado

Cómo tratarlos

La lista de puntos a seguir con los impedimentos debería recorrer los siguientes pasos:

Registrarlos
Piorizarlos
Hacerlos públicos
Actuar sobre su resolución
Informar de su resolución

Muchos de los impedimentos que pueden encontrarse en las tareas diarias suelen ser pequeños y de fácil y rápida resolución (pedir ayuda a otro miembro del team, un mail, una llamada telefónica al equipo de operaciones, etc.). Como muchos aconsejan, estos ítems pueden ser incluídos en el backlog y tratados dentro del mismo. Para el resto de los impedimentos se aconseja llevar un Backlog de Impedimentos.

Yendo en el mismo sentido, la Scrum Alliance nos da 5 tips para manejar la resolución de Impedimentos:

Hacerlos visibles, dejarlos escritos y a la vista de todo el equipo, cerca de la pizarra de tareas. Deben estar especialmente visibles durante la reunión diaria para que el SM pueda contar al equipo cuáles se fueron removiendo y junto con el equipo re-categorizar el resto.
Buscarlos, indagar, sobre todo en equipos que recién empiezan con la práctica el SM debe encargarse de detectarlos y sacarlos a la luz (por ejemplo, cuando las tareas quedan inmóviles en la pizarra por mucho tiempo, cuando hay más tareas "En Progreso" que desarolladores). Preguntar siempre qué haría que las tareas se resuelvan lo más rápido posible.
Limitar el número de Impedimentos, ya sea por tiempo o por cantidad. Por tiempo implica establecer un máximo de horas que se permite a un impedimento permanecer en la lista, por ejemplo "un impedimento puede existir por un máximo de 24 hs", pasado ese tiempo tiene que ser resuelto o enviado al próximo sprint. Por cantidad implica establecer un máximo de impedimentos abiertos por sprint para ser resueltos. El equipo decidirá qué hacer en el caso en que surja alguno nuevo en el medio. En el punto siguiente hacemos una salvedad a este tip.
Diferenciar entre impedimentos globales y locales. Esta categorización es importante para entender cuáles son los impedimentos que disminuyen la velocidad del equipo (globales) y cuáles los que bloquean la continuación de alguna tarea (locales o blockers). Esto nos remite al punto 3: ese tip sirve para los impedimentos de tipo global. A los impedimentos locales, que bloquean una o más tareas, la Scrum Alliance nos aconseja agregarlos a la pizarra del sprint con algo que los diferencie visualmente del resto de las historias para que sean enfrentados cuanto antes.
Ayudar al equipo a resolverlos. En la medida que se pueda, es aconsejable encontrar un equilibrio entre los impedimentos que toma para solucionar el SM y aquellos que puede solucionar el team por sí solo.Si bien una de las capacidades del SM es la de "limpiar" los impedimentos, es bueno dejar que el equipo pueda hacerse cargo de algunos de ellos.

Para finalizar, me quedo con una una frase que encontré respecto de este tema y me pareció muy buena: "No puedes eliminar los impedimentos pero tampoco deberías ignorarlos, o peor aún, aceptarlos como algo normal". (de Impediments Management and The Agile Triangle )

Más para leer:

Identificando Impedimentos

Impedimentos en Scrum

Top ten organizational impediments

Seguir a @3p_ar

Probando Pentaho IV: sparkline, dataBar y paleta de colores.

noreply@blogger.com (Lucila Santos) — Wed, 23 Oct 2013 14:24:00 +0000

Con este tablero de control queremos mostrar cómo probamos algunos componentes de Pentaho y CTools.

El gráfico muestra la variación de las ventas de Internet durante un período, por país.

Permite comparar el porcentaje de ventas por año y muestra tendencias por medio de sparklines.

La base de datos es AdventureWorksDW, de Microsoft SQL Server Database Product Samples

Internet Sales

Es una línea de tiempo en años con el total de ventas por país.
Componente usado: CCC Line Chart.

Propiedades relevantes del componente:

Data Source: ventas por territorio y por año.

 
SELECT   T.CalendarYear,st.SalesTerritorycountry ,SUM(S.SalesAmount) TotalSalesAmount 
FROM dbo.FactInternetSales S
INNER JOIN DimTime T ON S.OrderDateKey = T.TimeKey
INNER JOIN DimSalesTerritory st on S.SalesTerritoryKey = st.SalesTerritoryKey
GROUP BY T.CalendarYear,st.SalesTerritoryCountry
ORDER BY T.CalendarYear

CrossTabMode = FALSE.
SeriesInRows = TRUE.
PostFetch: definimos algunos extensionPoints y el formato de las marcas de cantidades.

 
function f(cdaData) {
    var newLine = this.chartDefinition;
    newLine.extensionPoints= [
        ["dot_fillStyle","#ffffff"],
        ["dot_shapeRadius","3"],
        ["dot_lineWidth","2"],
        ["line_lineWidth","2"],
   
        ["legendLabel_font","10px sans-serif"], 
        ["legend_font","12px sans-serif"],
        ["xAxisLabel_font","12px sans-serif"],
        ["yAxisLabel_font","10px sans-serif"],
        ["xAxisLabel_text",function(g){return (g.vars.tick)}]];
    newLine.yAxisTickFormatter= function(value){
            return (value / 1000).toFixed() + " K"; };
    newLine.showYScale= true;
    newLine.yAxisPosition= "left";
    newLine.colors=colorFill;
    newLine.xAxisFullGrid= true 
    newLine.yAxisFullGrid= true 
    newLine.xAxisEndLine= true 
    newLine.yAxisEndLine= true  
 this.chartDefinition= newLine;
}

Year Percentage

Es una tabla con las ventas por región y por año, con porcentaje correspondiente sobre el total para poder comparar la proporción de aumento en las ventas de un año a otro. El componente de Ctools usado es una tabla, con una columna de tipo 'dataBar'.

Propiedades relevantes del componente:

DataSource: busca el total de ventas por año y calcula el porcentaje que representa cada año respecto al periodo en estudio.

 
WITH TotalSales ( SumTotal)
AS(
SELECT  SUM(S.SalesAmount)
FROM dbo.FactInternetSales S
)
SELECT T.CalendarYear,SUM(S.SalesAmount) SalesAmount,
100 * SUM(S.SalesAmount)/ MAX(TotalSales.SumTotal)  SalesAmountPercentage,
100 * SUM(S.SalesAmount)/ MAX(TotalSales.SumTotal)  SalesAmountPercentage2
FROM dbo.FactInternetSales S
INNER JOIN DimTime T ON S.OrderDateKey = T.TimeKey
CROSS JOIN TotalSales
GROUP BY T.CalendarYear
ORDER BY T.CalendarYear

ColumnTypes: dataBar para SalesAmountPercentage

Country Trend

Esta tabla muestra la tendencia de variación de las ventas en un periodo de 4 años, usando sparklines.

A sparkline is a small intense, simple, word-sized graphic with typographic resolution. Sparklines mean that graphics are no longer cartoonish special occasions with captions and boxes, but rather sparkline graphic can be everywhere a word or number can be: embedded in a sentence, table, headline, map, spreadsheet, graphic

La columna correspondiente al sparkline debe ser una cadena separada por comas con los valores que formarán la tendencia.

DataSource: ventas por territorio y por año, totales por año en columnas y columna resumen de totales para conformar el sparkline.

 
 SELECT  SalesTerritoryCountry as Country ,
    CAST([2001]/1000 as CHAR(10)) + ','+CAST([2002]/1000 as CHAR(10))+ ','+CAST([2003]/1000 as CHAR(10))+ ','+CAST([2004]/1000 as CHAR(10)) as Trend
,[2001] , [2002]  ,[2003] ,[2004] 
FROM 
(SELECT st.SalesTerritoryCountry, CalendarYear,cast(S.SalesAmount  as int) as salesamount
FROM dbo.FactInternetSales S
INNER JOIN DimTime T ON S.OrderDateKey = T.TimeKey
INNER JOIN DimSalesTerritory st on S.SalesTerritoryKey = st.SalesTerritoryKey) p
PIVOT
(
sum(SalesAmount)   
    for CalendarYear in 
([2001] , [2002]  ,[2003] ,[2004]     )) as pvt order by SalesTerritoryCountry

Los Colores

Se intenta unificar e integrar los colores de los componentes, procurando usar un mismo color por país para los tres casos.

Fue necesario definir una paleta de colores: una lista de códigos rgb preseleccionados.

Buscamos en Protovis, que provee varias paletas de colores Colores Protovis.

En un 'resource' de tipo javascript asociado al dashboard se definieron las listas con colores ( para aplicar en los componentes y tablas) y un color general (para los encabezados y marcos de tablas).

rgbPasaHex se encarga de la conversión a RGB.

 
colorFill=pv.Colors.category19();
colores= colorFill.range();
var colorBase=rgbPasaHex(colores[9].color);

Colores en tabla Year Percentaje

En la propiedad PreExecution de la tabla, seteamos 'AddInOptions' para configurar el color del DataBar usando 'colorBase'

   this.setAddInOptions("colType","dataBar", function(val)  
    {
            return { startColor: colorBase, endColor: colorBase}
       
    });

Colores en la CCC Line Chart

Asignamos la paleta de colores en la propiedad postFetch de CCC Line Chart ( que mostramos previamente)

 
   
    newLine.colors=colorFill;
    this.chartDefinition= newLine;

Colores en la tabla Country Trend:

el nombre de cada país, tiene el mismo color que el sparkline y que la linea de tiempo correspondiente.

Para modificar los labels, se define un span con el color correspondiente en hexa.

Para los sparklines, se define el 'strokeStyle' a medida que se construye la tabla.

 
   function f() {
    var idx=-2;
  
    this.setAddInOptions("colType","formattedText",   
         {textFormat: function(v, st) { 
                 idx = idx+1;
          var colorHexa = rgbPasaHex(colorFill(idx).color);     
             return ""+v.toUpperCase()+" }
      });

   var idj = -2;
     this.setAddInOptions("colType","pvSparkline",function(val) {
        idj=idj+1;
        return {lineWidth:2,strokeStyle:colorFill(idj).color}});

   }

Colores en los encabezados y en los bordes de las tablas
Para manipular los colores de las tablas y los distintos elementos del documento, se usaron variables. En este caso, la variable global 'colorBase'. La asignación de color debe estar en el postExecution de cada una de las tablas.

 
function p(){
    var color=colorBase.toString();
    $("th").css( 'color' ,  color );
    $("td").css( 'border' ,  '1px dotted '+color );
    $(".tit").css("color",color); // definida una clase tit para los encabezados
  
}

Artículos relacionados:

Probando Pentaho I (Instalación de Pentaho Community)
Probando Pentaho II (Dashboard de ejemplo)
Probando Pentaho III (Introducción a Pentaho CTools)

Seguir a @3p_ar

Innovación conciente

noreply@blogger.com (Ricardo D. de Guzmán) — Tue, 10 Sep 2013 12:59:00 +0000

¿Cómo lograr un balance “perfecto” entre lo que nos suena más atractivo tecnológicamente hablando, y lo que resulta mejor para nuestro cliente?

Somos una empresa de Tecnología, nuestro equipo está formado por profesionales entusiastas, no sólo por lograr cumplir con los objetivos que plantea cualquier desarrollo de software, sino también por ofrecer un producto tecnológicamente de avanzada y moderno.

Para lograr nuestros objetivos se nos suelen plantear, entre otros, dos dilemas que podrían titularse así:

1- Tratar de ver más allá, nuestros clientes sabrán agradecerlo ¿Cómo recomendar y/o implementar una tecnología, sin haberla visto en real funcionamiento?
No siempre todo lo que se vende por ahí como lo mejor, resulta serlo y es muy importante recomendar implementaciones tecnológicas que sean acordes a la necesidad que buscamos satisfacer.

2- La mejor tecnología no es una en particular, es la que mejor se aplica a cada caso ¿Cómo lograr que nuestro entusiasmo tecnológico no le gane a nuestra conciencia profesional?.

(imagen tomada de http//wasanga.com/flormpecasique/files/2013/07/Proceso-de-Toma-de-Decisiones2.jpg?id=flormpecasique)

Nuestra experiencia en tantos años, nos permite volcar algunos tips que pueden ser útiles para lograr el objetivo principal, un producto de excelencia que cumpla con las necesidades planteadas en tiempo y forma, que permita seguir un ciclo de vida acorde a los tiempos en los que le toca vivir.

Tratar de ver más allá, nuestros clientes sabrán agradecerlo

Primer paso:

Lo más conveniente es Leer, Leer y Leer, en todo equipo siempre hay personas más predispuestas a saber interpretar por dónde viene la mano, es importante escucharlas y darles el lugar para poder llevar a cabo esa tarea.

Los foros de discusión son de mucha ayuda, se suelen volcar allí inquietudes sobre problemas reales con los que nos encontramos o nos vamos a encontrar.

Es muy útil saber elegir quienes son los gurúes a los que podemos seguir, buscar gente que sea responsable en lo que recomienda, y no dejarse llevar por charlatanes de turno.

Segundo paso

Aprender una nueva tecnología, es una inversión no solo personal sino también para el equipo y por consiguiente para la empresa, permitir esta inversión cada vez que sea posible nos va a dejar mejor parados para el futuro, se podría decir que es un poquito de hambre para hoy, pero es pan para mañana.

Prototipar las partes más complejas sin entrar en los detalles para luego tratar de someterlo a pruebas que lo pueden poner al límite.

Tener muy claro en todas estas pruebas que lo importante es ver si la tecnología nos sirve para lo que queremos hacer, tratar de mantenerse distantes.

Normalmente en los equipos están los perfiles más innovadores, y los más reaccionarios al cambio, buscar el equilibrio de ambos nos puede dar los mejores resultados, hay que saber escuchar todas las campanas.

La mejor tecnología no es una en particular, es la que mejor se aplica a cada caso

Cuando se elige una tecnología hay muchos factores en juego, menciono algunas de las preguntas que nos deberíamos hacer:

¿Qué impacto tiene la tecnología en la usabilidad del producto, si es que lo tiene?

¿Qué durabilidad en el tiempo pretendemos que tenga?

El mercado donde el producto va a vivir ¿le permitirá un soporte adecuado? en términos de posibilidades y costos. Etc. Etc…

Creo que la clave de todo esto es, ponerse en lugar del cliente en todo momento, y buscar la alternativa que realmente más le convenga a él.

Esto no siempre nos va a llevar al lugar más cómodo para nosotros, pero si nos va a permitir ganar la confianza del cliente, algo muy importante para poder llevar adelante una tarea tan compleja como apasionante, que es el desarrollo de software.

Probando Pentaho III: Introducción a Pentaho CTools

noreply@blogger.com (Lucila Santos) — Thu, 05 Sep 2013 16:58:00 +0000

Encontré un muy buen documento (Introducción...) que me ayudó a sintetizar todo lo leído y probado respecto la construcción de Dashboards con CTools. Comparto mi traducción y síntesis:

Pentaho CTools es un framework para crear y mantener dashboards en la versión Community de Pentaho business intelligence server (bi-server)
Una de sus características relevantes es la creación de dashboards interactivos, integrados con el bi-server. Todos los datos disponibles se pueden visualizar, aprovechando la configuración de seguridad del bi-server de Pentaho.

Está compuesto por:
1. Community Dashboards Framework (CDF)
2. Community Chart Components (CCC)
3. Community Data Access (CDA)
4. Community Dashboard Editor (CDE)

1. CDF: motor generador de dashboards. Estos dashboards están formados por COMPONENTES, conectados entre si.
Componente: es un objeto de javascript que encapsula otros objetos con propiedades y funcionalidades. Puede ser visual o no. Tienen interacción entre ellos, la más básica es que un componente puede re-dibujarse a partir del cambio de una variable.
Se puede customizar su comportamiento.

2. CCC: componentes gráficos que permiten la interacción del usuario, basados en Protovis y Raphaeljs

3. CDA: componente diseñado para recopilar, compaginar y distribuir información desde diferentes origenes.
Aunque CDF puede acceder a consultas SQL y MDX directamente, recomiendan el uso de CDA por asegurar accesos seguros, permitir joins de datos desde diferentes fuentes, exportar los datos de las queries fácilmente. También habilita la definición de las data sources y queries de SQL del lado del server. De esta manera, CDA disminuye el riesgo de inserción de código malicioso por medio de SQL injection (cuando la query esta almacenada del lado del cliente)

4. CDE: Editor que permite crear dashboards siguiendo estos pasos

Crear el layout o presentación de la página.
Especificar los data sources con la información a mostrar.
Crear los componentes visuales específicos. Conectarlos a los datos y ubicarlos en el layout.
Introducir más flexibilidad parametrizando los componentes y logrando interacción entre los mismos.

A continuación una descripción de las secciones de Layout, Components y Data Sources ...

Layout workspace

Formado por un área de estructura y otra de propiedades, relacionadas entre sí.

Layout Structure :
El layout mas simple esta formado por tres filas: Header, Contents y Footer.
Para modificar este layout, se pueden agregar columnas, filas, espacios, bloques de html, imágenes. Bloques de javascript.
Hay que tener en cuenta que las filas y columnas generadas están mapeadas a una estructura de <div> anidados, dentro de un archivo html generado en forma dinámica por el pentaho-CDE-plugin.

Properties:
Hay una lista de propiedades, describo las principales.
Nombre del elemento: se usa después para ubicar dentro del mismo los componentes gráficas.
Tamaños: toma blueprint css’ stylesheets. 'Width' se basa en las columnas de blueprint.
Se puede ajustar, pero es mejor que estos tamaños sean dados por el componente en si.
Si los tamaños sumados de todos las columnas exceden el ancho de la página, tomarán la fila siguiente. Por otro lado, con blueprint los 'Heigths' son definidos por las alturas de lo que contiene, por eso, si una columna está vacía, queda invisible porque su altura es de 0 px.
Seleccion de color: área de color y saturación, pueden ser configuradas por el selector de colores.

Data source workspace

Hay once tipos de datasources, de los cuales probamos SQL Queries y MDX queries.
Se puede seleccionar el acceso via JDBC ó JDNI.
Se recomienda acceder por JDNI en los casos en que se quiera acceder a mas de una tabla. Otra ventaja es que para setear JDNI se necesita solo el nombre de la datasource.
Dentro de las propiedades, se puede seleccionar un origen de datos creado anteriormente por Pentaho.
Al ingresar la consulta, se recomienda controlar la sintaxis de las consultas SQL o MDX en otro entorno. Un error en la consulta no se detecta fácilmente desde CDE.
También es útil probar la datasource creada por medio del Preview de CDA
Hay que guardar las modificaciones al datasource en cada cambio, y limpiar el cache de la CDA, entre una prueba/ corrección y prueba
Tener en cuenta que el cache del repositorio no es el mismo que el cache de la CDA.

Component workspace

El concepto de componente intenta simplificar la construcción de dashboards. Es un objeto de JavaScript que encapsula todas las propiedades y métodos.
Destacamos:

Genéricos: simple paramenter (javascript parameter), custom parameter(arrays, objetos, funciones), date parameter. Parametros con su inicialización, se usan para conectar los componentes entre si
Scripts: funciones de javascript
Otros. Usamos los botones, tablas.
Charts: los componentes para gráficos específicamente. Pie chart, line chart, bar chart
Selects: componentes usados para seleccionar valores. Permiten la interacción del usuario, desde text inputs hasta combos.
Custom: Raphael component: Raphaeljs es una librería para Scalable Vector Graphics (svg).

Propiedades de los componentes:
Cada tipo de componente tiene propiedades específicas, pero hay algunas comunes a todos que se pueden usar para controlar el ciclo de vida y comportamiento. Este cuadro resume el ciclo de vida de un componente y permite entender el sentido de las distintas propiedades.

- executeAtStart: una variable booleana o (función que devuelva booleano). Indica si el componente será ejecutado (renderizado) en el load del dashboard o no.
- Parameters: array de parámetros a pasar al componente, en general basados en el input del usuario. Permiten customizar (al data source que está detrás)
- Parameter: Parámetro de salida de la función
- Listeners: array de parámetros que disparan la ejecución y renderización del componente.
- PreExecution: función ejecutada antes de la inicializar o actualizar el componente. Si la función devuelve False, el componente no se actualiza.
- PostExecution: función que se ejecuta después del update del componente y se puede usar para indicar que la actualización terminó.
- PreChange: function(v), siendo v el nuevo valor del componente. Tiene sentido para componentes de tipo selector, para validar los inputs. Si esta función devuelve F no se ejecuta el evento 'fireChange'
- PostChange: se ejecuta después del cambio.
- Click action: Si la CCC charts es clickable ( Clickable = true), se ejecuta una función cuyo prototipo es:

function(s, c, v) { <body> }, cons = label of the seriesc = category label (value at the x-axis)v = value (value at the y-axis)

El uso más común de esta función es modificar el valor de un parámetro por medio de Dashboards.fireChange(param, value). Pero se pueden crear interacciones más complejas con un popup, por ejemplo. Que permitan que el usuario tome distintas acciones.

-Height - Width: usar solamente si al ubicar el componente dentro del layout no se ajusta a lo
que necesitamos.
-Datasource: la cda datasource definida antes.
-HtmlObject: es el id del html del layout, definido antes, que será reemplazado por el componente.
-Listeners: qué parámetros definidos previamente, disparan el cambio del componente
- Priority: por default 5, si es menor el componente se ejecuta primero. Se usa en los casos en que se quiere dar un orden de ejecución.
-Cross tab mode y series in rows
están relacionados con la estructura del dataset y con la información a mostrar.
Cross tab mode: si la consulta generada esta compuesta por series y categorías, en general si la consulta es MDX o una SQL con la clausula group by.
Series in rows: determina si las filas corresponden a las series o no.
If series in rows = false los datos deben venir como Serie, Category, Data. If series in rows =
true deben ser Category, Serie, Data.

Si crosstab mode = False los column headers (nombres) no son parte del dataset, por ende no serán visibles en el dashboard.

-Extension points:

Permiten setear el font family, font-size, text-orientation de los distintos componentes de texto del chart. Se forman como 'ItemTipo_propiedad', por ejemplo titleLabel_font.
Cuadro con ItemTipo más usados, propiedades y ejemplos de valores para las propiedades

Artículos relacionados:

Probando Pentaho I (Instalación de Pentaho Community)
Probando Pentaho II (Dashboard de ejemplo)

Seguir a @3p_ar

Incidencia de las TIC en la gestión del Capital Humano

noreply@blogger.com (Andrea Morales) — Thu, 05 Sep 2013 14:15:00 +0000

En estos últimos años venimos acompañando a los departamentos de RRHH de algunos de nuestros clientes, que buscaban incorporar tecnología en varios de sus procesos comunes (evaluaciones, comunicación, búsquedas internas, promociones, capacitaciones, outplacement, etc..)

Esto no se debe a un movimiento aislado sino a la influencia que las TIC (Tecnologías de la Información y Comunicación) vienen teniendo desde hace años en todas las áreas de la compañía, y particularmente destacable, en la gestión del Capital Humano.

Las TIC engloban a un sector de actividad donde se aplican en conjunto dos tipos de tecnologías: las TI (tecnologías de la Información) y las telecomunicaciones, con el objetivo de administrar y transformar la información, protegerla y recuperarla para analizarla desde distintos enfoques.

Para poder entender los efectos positivos que la aplicación de las TIC puede acarrear es necesario tener en claro que "tecnología" no es sinónimo de "producto" (un software en particular) sino de un concepto mucho más amplio. La implementación de la tecnología lleva a nuevas formas de colaboración, desarrollo de nuevos conocimientos, organización del trabajo, y en el caso del área de RRHH, exige nuevas capacidades de parte de sus responsables.

Justamente parte de esas nuevas capacidades implican, entre otras cosas, una evaluación estratégica de la tecnología a usar, teniendo claro que para el desarrollo de dichas capacidades es fundamental el apoyo de la alta dirección de las empresas.

En qué aspectos ayudan las TIC al sector de RRHH?

En la comunicación, por supuesto
En el diseño de puestos y roles
En la supervisión
En la detección de la duplicidad de trabajo
En la detección de tareas que se pueden tercerizar

Si bien, en muchos casos la tecnología, aún hoy, no se reconoce como un agente de éxito en el área de RRHH, es innegable el rol que cumple en la mejora de procesos de negocio, y como consecuencia, en la productividad.

Objetivos

El objetivo de las TIC como concepto global es el de agregar valor a la operación diaria. Cualquier estrategia de aplicación de tecnología de la información en la gestión del capital humano debe permitir a la organización, entre otras cosas:

Centralización y gestión de toda la información de la compañía y su análisis en tiempo real
Gestión y evaluación de desempeño
Mejora de la motivación de los empleados a través de una comunicación más abierta y fluida
Mejora de la información interna y del acceso a la misma, promoviendo la cultura corporativa
Que el área de RRHH pueda enfocar sus esfuerzos en decisiones estratégicas, al quedar liberados de otras cuestiones rutinarias que insumen tiempo y esfuerzo
Reducción de costos y tiempos con la automatización de procesos, eliminación del uso de papeles en muchas operaciones y la gestión del tiempo

Procesos como Audit Management o Knowledge Management, por ejemplo, son factibles de aplicación de tecnologías a través de diversas aplicaciones.

Encontramos también herramientas para e-recruitment (búsqueda de canidatos a través de la web corporativa, por ejemplo), e-learning, B2E (businees to employe), administración de Intranets (de código abierto, pagas o a medida).
Las redes sociales juegan un papel muy importante hoy en día en la comunicación interna de las empresas y distintos modelos de teletrabajo son también incorporados en búsqueda de reducción de costos, flexibilidad, retención de empleados, mejoras en productividad, entre otros beneficios.

El enorme valor que estas tecnologías ofrecen hace que estén presentes en casi todas - si no todas - las actividades sociales y económicas en cualquier tamaño de empresa. En el caso de la gestión de capital humano no hay que perder de vista que, más allá de aplicar y saber usar las herramientas necesarias de la mejor forma, las tecnologías deben incidir positivamente en la vida de las personas.

Artículo relacionado:
Las redes sociales dentro de la empresa

Seguir a @3p_ar

SCRUM, problemas en la reunión diaria: qué podemos hacer al respecto?

noreply@blogger.com (Anonymous) — Tue, 03 Sep 2013 15:14:00 +0000

Internamente muchas veces nos preguntamos si las reuniones diarias están cumpliendo el objetivo que realmente tienen y al leer blogs y foros sobre metodologías ágiles descubrí que muchos equipos tienen los mismos problemas que detectamos puertas adentro.

Revisar objetivos

Para comenzar es bueno recordar cuál es el objetivo y qué debe hacer cada miembro del equipo en una típica reunión diaria.

La reunión diaria tiene como fin el facilitar la transferencia de información y la colaboración entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros.

Cada miembro del equipo participa del trabajo que el resto está realizando (dependencias entre tareas, progreso y problemas) para luego de finalizar la reunión poder hacer las adaptaciones que permitan cumplir con las historias que el equipo comprometió para el sprint en curso.

Cada miembro del equipo debe responder las siguientes preguntas en un tiempo estipulado de como máximo 15 minutos:

¿Qué he hecho desde la última reunión diaria? ¿ Pude hacer todo lo que tenía planeado? ¿Cuál fue el problema?
¿Qué voy a hacer a partir de este momento?
¿Qué problemas tengo o voy a tener para cumplir con este sprint y en el proyecto?

Como apoyo a la reunión, el equipo cuenta con la lista de tareas del sprint (sprint backlog) donde se actualiza el estado y el esfuerzo pendiente para cada tarea.

Con esto se ponen en evidencia los beneficios y restricciones que tiene cada equipo en realizar sus tareas.

(Para quienes quieran profundizar recomendamos leer "Scrum y XP desde las trincheras")

¿Problemas? ¿Qué problemas?

Si bien la práctica descripta en el párrafo anterior puede ser muy clara y parecer muy simple, nos pasa que, con el correr del tiempo notamos que hay cosas que empiezan a fallar o a sacarnos del eje de lo que indican los libros. ¿Cuáles son esas cosas? Aquí listamos algunos ejemplos de situaciones que pueden presentarse en las reuniones diarias y que pueden ser tratadas durante la misma, así como también recomendaciones recopiladas entre experiencia propia y de otros:

1. Algún miembro del equipo se queda sin tareas dentro del sprint

Que él mismo elija qué cosas puede hacer para ayudar al equipo (test, documentación, scripts, etc.)
O decidir entre todos que ayude con otros tipos de tareas, por ejemplo que sea el cadete del grupo.

2. Falta tiempo para corregir código o hacer una corrección que no produce historias válidas dentro del sprint.

Bajar el rendimiento del equipo, para poder dedicarle el tiempo suficiente a las tareas de mejoras o correcciones, es decir, plantearse hacer menos historias para el sprint.

3. Ante un proyecto grande con muchos desarrolladores

Cuando la cantidad de personas en un proyecto es grande, se dispersa mucho la información, lo ideal es armar varios grupos más pequeños de entre 3 y 10 desarrolladores.
Si hay varios equipos en el mismo proyecto , lo más recomendado sería, un solo project owner (dueño del proyecto), sprint sincronizados para que las demos sean el mismo día, la planificación unificada para repartir las historias y luego cada equipo hace su propia planning poker. Hacer en diferentes horarios las reuniones diarias, para que el project owner esté en todas. La gran ventaja de esta experiencia es que cuando termina cada sprint los miembros del equipo pueden ser intercambiados, o reorganizados minimizando así las dudas y/o problemas.

4. Llegadas tarde a la reunión diaria

Elegir una hora buena para todos ( en la generalidad de los casos, se toma como horario de la reunión diaria, entre 15 y 30 minutos posteriores al horarios de inicio de la jornada).
Si los retrasos son habituales se puede "llenar la alcancía", "traer algo para compartir para todos". Ante la reincidencia eligen hacer que duela un poco más el bolsillo y así tratar de evitar llegar retrasado.
Llegar tarde se puede deber al desinterés, con lo cual es válido plantear como alternativa que el propio implicado en los sucesivos retrasos puede exponer sus propias explicaciones ante el grupo y/o alternativas de participación para aumentar su interés.
Contar o no qué paso en la reunión o a los que no estuvieron presentes, depende de dos puntos de vista, el interés de escribir en una breve "minuta" sobre lo hablado por el project owner y el otro punto de vista el interés del integrante retrasado en interiorizarse en lo sucedido en la reunión diaria.

5. Equipo distribuido geográficamente

Skype, o cualquier vía de comunicación on line conectado permanentemente, reunión diaria del equipo completo, comunicación lo más fluida posible (skype, cámaras web, mail, de ser necesario palomas mensajeras!!!)

En forma anecdótica podemos decir, que en Tercer Planeta, hemos intentado varias de estas recomendaciones, algunas con funcionamiento óptimo y otras en vías de mejoras seguras.

La más importante que hacemos es la de realizar una reunión diaria del grupo completo, ya sea que pertenezcan o no al mismo proyecto, contándonos en qué estamos cada uno y pidiendo todos los S.O.S. necesarios, esto permite que ninguno de los proyectos quede estancado, reconociendo que no todos sabemos todo. Además de poder contar con ayuda, podemos saber en qué estado está cada uno. A esta reunión diaria grupal general, muy cortita, le siguen las reuniones diarias específicas de cada proyecto en concreto (reuniones de avance).

Personalmente, la primer reunión diaria es la más saludable y a veces hasta la más esperada por todos, nos permite entender el estado de cada uno, estar al tanto de temas generales del equipo y temas más sociales. Es una manera de mantener la comunicación "viva", más allá de los detalles particulares que presente cada proyecto.

Seguir a @3p_ar