Ideas 3p

Lo que dejó Ágiles 2011

noreply@blogger.com (Nora Martinez) — Tue, 10 Jan 2012 15:21:00 +0000

Los días 11, 12 y 13 de Octubre de 2011 se realizó la 4ta Jornada Latinoamericana de Metodologías Ágiles en Buenos Aires. Los dos primeros días de la jornada se dedicaron a charlas, workshops y tutoriales, dejando el último día reservado a los Open Space. En el "Cierre oficial de las Jornadas" se realizó la correspondiente retrospectiva del evento e inmediatamente después se habilitó la fiesta para completar la finalización del evento.

A pesar que han pasado algunos meses, desde las jornadas hasta la publicación de este artículo, quiero compartir una breve reseña de algunas de las sesiones a las que asistí y las impresiones más destacadas que me llevé.

Keynote: Us, them and the problem with common agile practice

(Jeff Patton)

Remarcó la importancia ubicarnos en el lugar del usuario/cliente en cuanto a poder imaginarnoslo en un “mal día” para poder visualizarlo en un “buen día”. Esto nos ayuda a “sincronizar nuestros cerebros”, al intercambio de conocimiento acerca de los problemas actuales, futuros y lo que hay en el medio.

Consejo: construir el “Story map” en conjunto con el usuario/cliente para explorar el producto completo a través de la conversación con él, quien habla de su “vida laboral” en lugar de un producto de software.

Es importante armar “Cross functional team”

de esta forma, el trabajo se tratará de hacerlo NOSOTROS Y ELLOS.

Workshop: Design emergente e divida técnica: tomando decisoes conscientes

(Mariana Vivian Bravo, Hugo Corbucci)

Fue un workshop en el cual al principio se presentaron tres ideas relacionadas con "Deuda técnica" y luego se realizó un debate entre los asistentes.

Durante el debate uno de los participantes compartió una metáfora donde la deuda técnica está representada con lo que se deja sin lavar al cocinar. Se pueden lavar los utensillos y recipientes de cocina cuando no se utilizan más, o postergar el lavado hasta finalizar la preparación. La principal diferencia entre ambos es el esfuerzo asociado a realizar el "lavado de los platos": en el primer caso son pocos platos a lavar en varios momentos, en el segundo es una pila de platos -proporcional al nivel de dificultad de la preparación- al finalizar la misma.

Un interesante punto de vista para evaluar qué se puede y quiere hacer con las deudas técnicas.

Keynote: Agile, past and future

(James Shore)

Me pareció muy interesante y enriquecedor el Keynote que brindó James Shore. Develó algunos secretos para tener éxito en ágil:

Pasión por el trabajo ¿Cómo tener “El mejor trabajo de mi vida”?

Hacerse cargo del software que se está construyendo.
Hacer foco en la Mejora continua, no solo durante la retrospectiva. Importante –> qué se hace para progresar, cambir o resolver algo.
Calidad –> “es una cuestión de actitud”.
Habilidad –> ser bueno en lo que se hace pero no ser un “rock star”.
Disciplina.
Buen entorno, sin fricción, donde sea sencillo trabajar. Alegría.

Comunicación

Lograr que todas las personas tengan la misma idea, que entiendan lo mismo.
Hablar, comunicarse.
Estar atento a los temas que son sensibles, se necesita un equipo maduro para poder manejar estas situaciones.
Comenzar a compartir experiencias, a divertirse trabajando juntos para conseguir el objetivo.

Herramientas

Velocidad de iteración sólida y constante.
Pocos defectos. Test automatizados. Diseño continuo.
Tener rigor –> identificar un diseño pobre y corregirlo, mejorarlo.

El secreto con el que más me siento identificada, está relacionado con la pasión por el trabajo. Me alegró escucharlo y coincido plenamente con ese concepto, aunque creo que va mas allá de ser ágil o no. Creo que es fundamental que cada uno disfrute del trabajo que realiza y se sienta orgulloso del resultado.

Optimizing Organizational / Team collaboration & transparency even with distributed teams

(Michael DePaoli)

Modelo representativo del trabajo en equipo, en cuanto a las relaciones y la comunicación:

Enumero algunos conceptos que me parecieron destacados:

Cuanto mas alejado está el equipo, menos confianza y colaboración existe.
¿La cultura de la Compañía valora la Confianza e Integridad?
Todos deberían “Walk the talk”, hacer lo que dicen, especialmente el líder.
Desperdicio = cuando se pierde tiempo tratando de descubrir a quien culpar.
No temer a fallar, es una oportunidad para aprender.
Aprender –> es la clave.
El entorno físico afecta el comportamiento. Tener comodidad ayuda a la colaboración y transparencia.
Tener éxito o fracaso como un equipo.
Remover aquellas personas que “no juegan en equipo”.
Canales de comunicación vs. Efectividad.
Herramientas no técnicas: considerar el uso de la más poderosa herramienta que disponemos: tu cerebro.
Mejorar la calidad del mensaje. Crear un vocabulario común.
Con “Openness & Trust” la persona se encuentra mas receptiva al feedback.
Relationship Awareness theory –> es un modelo de auto-aprendizaje para entender e inferir eficiente y acertadamente el motivo detrás del comportamiento de otros. Ayuda a construtir relaciones personales y laborales mas efectivas. 4 Premisas:

El comportamiento está dirigido por la motivación de lograr la autoestima.
La motivación cambia en los conflictos.
Fortalezas, cuando son exageradas, pueden ser percibidas como debilidades (hay que conocer a la otra persona).
Claridad y validez para mejorar el auto-descubrimiento.

Motivational Value System –> mediante un sencillo test de personalidad se puede conocer cómo una persona se comporta frente a un conflicto, con el fin de brindarle herramientas para manejarlo en forma positiva. Manejar cómo responde uno ante un conflicto y conocer o intuir el comportamiento de otras personas conduce a resultados de beneficio mutuo y nos acerca a entender cómo nos comunicamos. Más información acerca de SDI-Personal strenghts trainig.

Conclusión

Desde lo personal, asistir a las jornadas y participar de ciertas charlas enriqueció y fortaleció mi valoración acerca de las metodologías ágiles, reafirmando su importancia para la conformación de un equipo de trabajo que trabaje en conjunto, colaborando unos con otros para alcanzar entre todos un objetivo en común. Fue inevitable hacer una introspección acerca del trabajo diario y detectar algunos puntos en los cuales se puede seguir mejorando, aquellos que hay que reforzar y cuales mantener.

Web Tests utilizando Selenium y SpecFlow

noreply@blogger.com (Matías Timossi) — Tue, 13 Dec 2011 16:27:00 +0000

En el desarrollo de aplicaciones cada vez es más indispensable el uso de herramientas que nos permitan automatizar nuestras pruebas. A continuación vamos a echarle un vistazo a dos herramientas que se usan para el desarrollo de tests orientados a bdd (desarrollo guiado por comportamiento),

Selenium WebDriver: Es una biblioteca que nos facilita la creación de test automatizados para aplicaciones web.

SpecFlow: Está herramienta sirve para escribir test utilizando el lenguaje Gherkin.

¿Y que es Gherkin?

Es un lenguaje común para crear test unitarios en texto plano usando el lenguaje de negocio de la misma forma que escribimos los criterios de aceptación de una historia de usuario. Esto quizás no parezca muy impresionante a simple vista, pero contar con esta declaratividad hace que los test sean fácilmente comprensibles para cualquier stakeholder, funcionando como puente conceptual entre usuarios y desarrolladores, y que finalmente sirva como documentación ejecutable de toda la funcionalidad.

Para entender un poco mejor de qué se trata vamos con un ejemplo:

Supongamos que necesitamos probar la funcionalidad de un abm para carga de usuarios,

podríamos escribir el test de la siguiente forma,

Scenario: Add new, modify and delete
    When add a User with description "Don Pepito"
    When change User description "Don Pepito" to "Don José"
    And search for User "Don"
    Then should read "Don José"
    But should not read "Don Pepito"

Una vez escrito el test lo podemos ejecutar y lo que va a pasar a continuación es que “mágicamente” (suponiendo que todo esté debidamente configurado) se va abrir una ventana con el navegador que hayamos preestablecido y automáticamente se ejecutarán las pruebas.

¿Y donde esta la magia?

Está en que SpecFlow nos permite que las frases que escribimos, y representan las acciones a realizar en la aplicación, están bindeados a métodos de test escritos utilizando WebDriver. Entonces, si por ejemplo quisiéramos navegar a través de una de estas frases nos vamos a encontrar con algo parecido a esto,

[When(@"add a Clown with description ""(.*)""")]
     public void WhenAddAClownWithDescription__(string description)
     {
         var ws = new CommonWebSteps();
         ws.WhenVisit("List.aspx/Option/Clowns");
         ws.WhenPressButton("Add Clown");
         ws.WhenFillWith("Description", description);
         ws.WhenPressButton("Save");
     }

Recapitulando un poco, teniendo definidos los métodos apropiados no se necesitan conocimientos en programación para escribir pruebas de aceptación (Por cierto, además contamos con IntelliSence =D) que podemos ejecutar las veces que sean necesarias en varios navegadores evitándonos tediosas jornadas de clics repetitivos a través de nuestra aplicación web. En otras palabras, es casi como tener una unidad R2D2 que hace el trabajo por nosotros!

Robots: en el futuro realizarían nuestro trabajo.

Links:

SpecFlow

Selenium

Etiquetas de Technorati: Web Test,BDD,WebDriver,SpecFlow,Selenium

Jornadas Data Mining

noreply@blogger.com (Lucila Santos) — Mon, 21 Nov 2011 17:03:00 +0000

El pasado 27 y 28 de octubre, en la Facultad de Ciencias Exactas de la UBA, se organizaron las sextas jornadas de Data Mining. Como estoy cursando algunas materias de la Maestría en DM&KD, fui invitada a participar de las conferencias y las capacitaciones que se ofrecieron.
A continuación presento un resumen de los paneles que me interesaron.

Ian Witten- Wikipedia
Ian Witten es profesor de Computer Science en la Universidad de Waikato, Nueva Zelanda.
Es un personaje muy interesante para la comunidad de mineros, ya que fue uno de los creadores de WEKA. (Conjunto de librerías JAVA para la extracción de conocimiento desde bases de datos y realizar tareas de dataminig. Es un software desarrollado en la Universidad de Waikato bajo licencia GPL lo cual ha impulsado que sea una de las suites más utilizadas en el área en los últimos años) .

Wikipedia es una mina de oro de información, no solo para muchos lectores, sino también para una creciente comunidad de investigadores que la reconocen como una fuente de excepcional escabilidad y utilidad. Wikipedia representa una gran inversión de tiempo y de opinión: un enorme tapiz de conceptos y relaciones en constante evolución. Muchos la vemos como poco confiable, sin embargo el nivel de precisión en sus conceptos es similar al de la Enciclopedia Británica. Ian presentó Wikipedia como una nueva forma de democratizar el conocimiento. El saber fue custodiado hasta el 1500 por la religión, luego paso a ser exclusividad de la academia, finalmente ahora, en la era digital, el saber estaría en manos de la gente.
Destacó también que Wikipedia posee una estructura de links muy rica, pues brinda através de sus artículos explicaciones, investigaciones y serendipity ( hallazgos afortunados e inesperados).
Habló de "wikificación": incrementar un documento de texto con los hipervínculos correspondientes a los artículos de Wikipedia - como si el documento fuera en sí mismo un artículo de Wikipedia. Wikipedia puede ser utilizado para determinar la relación semántica entre conceptos. "Wikificar" documentos es explotar los enlaces internos de Wikipedia para obtener información relacional y sus textos de anclaje como información léxica.
Es interesante destacar que Witten es precursor en la temática de bibliotecas digitales y es quien actualmente está a cargo del Laboratorio de Biblioteca Digital de la Universidad de Waikato, Nueva Zelanda. Allí se están desarrollando proyectos de interés. Entre ellos, el software Greenstone que ha ayudado a difundir la tecnología de bibliotecas digitales en todo el mundo, con especial énfasis en los países en desarrollo.

Curso de WEKA
Uno de los dos días de las jornadas fue dedicado a un curso práctico de Weka. A cargo de Ian Witten.
En el curso de Weka, se describieron conceptos fundamentales como overfitting y evaluación. Se mostraron algoritmos simples de aprendizaje automático, modelado estadístico, arboles de decisión, reglas de asociación, modelos lineales y clustering.

Morosidad
Hubo una charla acerca de riesgo de morosidad, donde se presentó un proyecto que trata con todos los riesgos relacionados al pago tardío. Administrar estos riesgos asociados a los clientes es un proceso continuo basado en la observación y análisis del comportamiento. Las consecuencias financieras de ser más eficientes en el proceso de cobranza impactan directamente en la facturación y la rentabilidad de la compañía, y también están vinculadas a la relación con los clientes.
Se explicaron conceptos de Payment Risk dentro de las áreas de prevención de pago tardío y optimización del proceso de cobranza.
Con esta solución se busca colaborar con las decisiones de aceptación de clientes y ajuste de límites de créditos. Se busca también reducir los costos en los procesos de recupero de deuda y minimizar los tiempos.

Social Network Analysis
Otro tema de interés fue la presentación de técnicas de SNA , aplicadas al desarrollo de modelos en la industria de telecomunicaciones.
Las personas que son afines entre sí -es decir, que pertenecen a determinado grupo social- comparten gustos, ideales y visiones.
Por lo tanto si un miembro de ese grupo adquiere determinado equipo o ringtone o juego o inclusive, abandona el servicio, es probable que los otros miembros de ese grupo también lo hagan.
El análisis de las redes sociales, determinadas por los llamados y mensajes de celular de una persona, permite identificar dichos grupos y los líderes de los mismos. En esta charla vimos cómo se utiliza el análisis de Redes Sociales en los modelos predictivos, y la mejora obtenida respecto a los modelos tradicionales que no utilizan dicha información.

Visualización
Finalmente alumnos de la maestría presentaron trabajos. Algunos alumnos participaron en el concurso organizado por VAST CHALLENGE 2011. Esta competencia es una de las iniciativas de la IEEE para impulsar la innovación de herramientas gráficas que resuelvan situaciones de la vida real. El desafío consistía en analizar conjuntos de datos y resolver problemas utilizando visualizaciones. En concreto, había que analizar secuencias de ataques a una red informática. Uno de los trabajos logró una mención especial por parte del comité evaluador del concurso. En la charla se presentó este trabajo: uso de mapas de calor y gráficos de coordenadas paralelas los cuales permitieron identificar eventos relevantes en los conjuntos de datos. Estos gráficos fueron desarrollados en Canvas y Processing.

Asp.Net MVC Pipeline

noreply@blogger.com (Benjamin Eidelman) — Thu, 29 Sep 2011 14:20:00 +0000

Allá por Marzo del año pasado en lo que llamamos WebCrucijadas 2010, hablamos un poco sobre Asp.Net MVC e intenté sintetizar el flujo de una aplicación Asp.Net MVC típica (en realidad es válido para casi cualquier framework web MVC).

Este diagrama (pseudo-diagrama de flujo) es una supersimplificación que sirve como material introductorio. Pero el motivo del post es compartir un diagrama (mucho más profesional :)) que twitteó @DanWahlin que muestra con detalle el pipeline de Asp.Net MVC (es decir, la parte izquierda del gráfico anterior).

El gráfico en PDF:
Asp.Net MVC Pipeline
y el artículo de Simone Chiaretta con una explicación muy buena de cada paso del flujo (en inglés):
An Introduction to ASP.NET MVC Extensibility

El artículo trata sobre la extensibilidad de la plataforma (que es destacable), de hecho el autor comienza afirmando "Si no estás extendiendo (Asp.Net MVC), no lo estás haciendo bien".
Sin embargo creo que conocer el pipeline es muy importante para arquitectos, programadores o cualquier otro perfil técnico.
De la misma forma que era vital entender el pipeline en WebForms para evitar darse la cabeza contra la pared, creo que es fundamental entender con cierta profundidad el pipeline de MVC para "moverse con soltura" en este nuevo framework.

En cuanto a la parte derecha del primer gráfico, afortunadamente se trata de un front-end html+css+js (¿todavía no existe un acrónimo ingenioso para este stack?) para el cual se aplican los mismos lineamientos de cualquier otra plataforma web moderna.

En un futuro, incluso podría tratarse de una aplicación "Metro" html+css+js (un acrónimo urgente!) nativa para Windows 8.

Bookmarklets: FireBug Lite y DOM Monster

noreply@blogger.com (Benjamin Eidelman) — Tue, 31 May 2011 15:34:00 +0000

2 Bookmarklets para la barra de favoritos del desarrollador web.

con bookmarklets la barra de favoritos puede ser tu Baticinturón

Firebug Lite

http://getfirebug.com/firebuglite

Firebug Lite es una versión de Firebug (herramientas de desarrollo para FireFox) escrita totalmente en javascript que puede ser cargada en cualquier browser, particularmente aquellos que no carecen de tales herramientas, por ej. IE6

Firebug Lite puede agregarse como bookmarklet:

y al hacer click en el bookmarklet:

Genial! Inspección de HTML, CSS y Javascript, edición en tiempo real de estilos, consola javascript. Lamentablemente la magia no existe y no es posible debuggear javascript, monitorear requests, y otras features que no son posibles sin una mayor integración con el browser.

Con la inspección de HTML y CSS es posible encontrar rápidamente esas inconsistencias tan divertidas en IE6 o IE7 como por ejemplo: En IE6 y 7 los divs vacíos no respetan el atributo height si tienen width

DOM Monster

http://mir.aculo.us/dom-monster/

otro Bookmarklet interesante (y totalmente diferente) es DOM Monster, al invocar el DOM Monster en cualquier página, éste ejecuta una serie de evaluaciones y muestra un reporte bastante interesante sobre posibles optimizaciones a HTML y Javascript.
Los creadores promocionan una trilogía de libros sobre la optimización de Javascript como complemento, pero DOM Monster es open source. Podemos inclusive "forkearlo" y agregar nuestras propias reglas, no es más que un gran archivo Javascript.

Si bien tienen algunos puntos en común con herramientas como PageSpeed o YSlow, DOM Monster hace un análisis estático (por eso puede funcionar como bookmarklet) y pone el foco en la estructura del HTML+ CSS y el código Javascript.

CUIDADO: La ejecución por primera vez de este tipo de herramientas puede herir sentimientos :)

buuuuuuuh!

Un reporte de ejemplo:

Dos modelos de aplicaciones web

noreply@blogger.com (Benjamin Eidelman) — Fri, 27 May 2011 19:04:00 +0000

Hace casi un mes se realizó (en Portland, OR, EEUU) la JSConf 2011, y estuve leyendo sobre algunas de las presentaciones, algunas muy interesantes, ya no es novedad que éste es un momento muy especial para el mundo Javascript.

NodeConf

Un poco al margen de esta nota es destacable que a continuación de la JSConf se realizó la NodeConf, cada una de 2 días de duración, una pauta de la importancia que está cobrando Node.js, lo cual también puede verse en el impresionante crecimiento en la cantidad de modulos desarrollados por terceros, más de 20 se agregaron en los últimos 9 días).

Dos estilos

Volviendo al JSConf, quiero compilar en este artículo uno de los temas que vi emerger en varios blogs de los asistentes, y es la aparición a lo largo de la conferencia de 2 estilos distinguibles de aplicaciones web, en lo que al cliente se refiere (no voy a hablar de Asp.Net, PHP, Node.js o Ruby on Rails, sino de HTML+CSS+JS).

Si bien no tienen nombres definidos voy a nombrar estos estilos por sus rasgos más representativos, voy a hablar de aplicaciones "Progressive Enhancement" (en adelante PE) y aplicaciones "MVC", "MVVM" o "MVVMC" (en adelante MVC), describiendo sus características quedará más claro a que me refiero.

Aplicaciones "Progressive Enhancement"

El termino "Progressive Enhancement" hace referencia a una práctica muy difundida en JavaScript en la que las páginas se descargan al cliente con funcionalidad básica, una vez completada la descarga mediante Javascript, se incrementa de forma progresiva la usabilidad, y en algún caso la funcionalidad a medida que se detecta soporte en el navegador para las tecnologías requeridas.

Un ejemplo simple: imaginemos una página en la que se le solicita al usuario ingresar su ubicación geográfica para ofrecerle algún servicio. Siguiendo el principio de "Progressive Enhancement" podría estar construída de esta manera:

La página llega al cliente con un simple textbox en el cual el usuario ingresa su dirección (calle y número), al hacer click en enviar el formulario se envía al server, en el server se traduce esa dirección en coordenadas geográficas invocando por ej. a la API de Google Maps. Luego se devuelve al cliente una página con la dirección normalizada a modo de confirmación.
En caso de detectar un cliente de escritorio o con suficiente resolución de pantalla se agrega a la página de confirmación un mapa (como imagen estática) con la ubicación encontrada señalada, ésta imagen puede generarse con la Static API de GMaps.
Si se detecta en el navegador soporte para Javascript, al completarse la descarga del formulario se agrega debajo del textbox un mapa interactivo de GMaps dónde el usuario puede seleccionar su ubicación haciendo click en el mapa.
Si luego de detectarse soporte para Javascript se detecta también soporte para geo-localización (HTML5) se utiliza este servicio para obtener la ubicación actual y mostrarla como valor default en el mapa.

El resultado es que el cliente obtiene la mejor experiencia posible en base a las capacidades del navegador/dispositivo que utiliza.

Típicamente se trata de páginas que en su mínima expresión se comportan como páginas con HTML (y CSS) que permite navegar, manipular o enviar contenido con los elementos disponibles del HTML estático (anchors y forms). Y van incrementando su usabilidad, responsividad e inclusive su funcionalidad, a medida que se detecta soporte para Javascript, manipulación del DOM, procesamiento de información del lado cliente, comunicación asincrónica con el server (AJAX) y otras técnicas soportadas por las APIs de HTML5 (como geolocalización, modo "offline" o base de datos local).

PE tiene el mismo objetivo que "Graceful Degradation" pero utiliza el camino reverso, con "Graceful Degradation" la página llega al cliente en su "máxima expresión" y se maneja de la manera más "agraciada" posible la falta de soporte del cliente presentando alternativas de menores requerimientos. A la larga la experiencia del usuario puede ser similar con ambos approaches, pero PE es a veces visto como una evolución de GD por hacer a un mejor diseño y uso eficiente de los recursos, pero ambos pueden ser convenientes según el escenario.

Finalmente cabe mencionar que PE o GD no sólo aplican a Javascript o APIs HTML5, también aplica a diferentes resoluciones de pantalla (como muestra el punto 2 del ejemplo), o al uso de estilos más sofisticados de CSS3 (gradientes, esquinas redondeadas, etc.). Dejo este tipo de PE/GD para otro momento ya que son transversales al tema de este artículo ya que aplican a tanto a las que llamé aplicaciones PE como MVC. Quedaría para otro artículo en que hablemos por ejemplo de el uso condicional de estilos usando modernizr.

La construcción de aplicaciones PE suele estar soportada por el uso extensivo de frameworks como jQuery, Prototype o MooTools (o una combinación de microframeworks). A la hora de implementar los diferentes items de "mejora" progresiva es importante respetar la buena práctica de "Feature detection over Browser Sniffing", es decir utilizar siempre la detección de soporte para una deteminada API en lugar de intentar detectar el nombre o versión del navegador (ya sea en base a window.navigator o a la existencia de cierta función). Existen algunas librerías para facilitar el uso de "Feature detection", modernizr es la más famosa (ahora se incluye por default en los proyectos Asp.Net Mvc 3).

En conclusión, todo esto no es en realidad ninguna sorpresa, todas las aplicaciones web que usamos a diario han migrado o están migrando a este estilo, el cual seguramente siga siendo predominante por mucho tiempo.

Aplicaciones MVC o MVVM

Por otro lado, existe otro estilo marcadamente diferente del anterior. Se trata de aplicaciones que implementan el patrón MVC (Model-View-Controller) o alguna variante MVVM (Model-View-ViewModel), MVVMC (Model-View-ViewModel-Controler) completamente del lado del cliente, el resultado es una arquitectura similar a la que permiten otras plataformas RIA, como Silverlight (véase Silverlight MVVM) o JavaFX pero con las ventajas de basarse únicamente en HTML+CSS+JS.

En estas aplicaciones toda la lógica de presentación se encuentra en el cliente, lo que permite utilizar como BackEnd nada más que una capa de servicios REST+JSON que se encargue de lógica de negocios, persistencia, y conectividad con otros servicios (agrego un diagrama de arquitectura más adelante).

Generalmente se trata de aplicaciones que se descargan como una única página html (single-page apps), que contiene el layout principal. Luego se realiza la carga e de algun framework JavaScript MVC (Backbone, Sproutcore, JavascriptMVC) o MVVM (Knockout.js, Batman.js).
Generalmente se encargan de coordinar el envío y recepción de datos via AJAX, y actualizar la UI (vistas) mediante el uso algún motor de templates para Javascript (jQuery.templates, EJS, mustache) o mediante la manipulación de bloques html decorados con metadata (clases css o atributos data-*), vistas "template-less".

Este última modalidad (template-less) es el caso de Batman.js, un framework MVVM cuya uso de "Convention over Configuration" le da una simplicidad increíble, les recomiendo ver alguno de los ejemplos que hay en la página oficial. Sólo les falta mejorar un poco el logo!

En general, estos frameworks permiten definir modelos de entidades, aplicar databinding bidireccional, y configurar algún manejo de persistencia (por ejemplo Batman.js permite seleccionar entre almacenamiento local (HTML5), websockets (lo que permite colaboración en tiempo real) o el uso de un adaptador para otras bases de datos).

Cada vez vemos más aplicación HTML con UI complejas (en su estructura y en su interactividad) el resultado suele ser un caótico rejunte de scripts (ya sea en files separados o embebidos) formada principalmente por una serie de métodos que manejan el input del usuario a traves eventos DOM: muchas líneas como éstas:

$('#refresh').click(function(e) {
...
});

$('.item-row').hover(function(e) {
...
});

$('#btn-send').click(function(e) {
$.ajax({...
success: function(data){
$('#item-list').empty()

.append(...)

.children('.item')
.css({color:'red'}).end()

.fadeIn(function(){

$('#progressbar').hide();

});

}
});
});

(Nótese la clásica "pirámide" con callback asincrónico incluído)

Afortunadamente este problema es muy antigüo y como suele suceder existe un patrón que lo resuelve muy bien. El problema es simplicar la construcción de interfaces de usuario inherentemente complejas y el patrón más conocido para atacarlo es MVC y lo hace mediante la aplicación de SoC (separación de responsabilidades). Con lo cual no debería sorprender el surgimiento de éstas librerías.

A diferencia de las anteriores éstas aplicaciones están pensadas para proveer una experiencia de usuario al nivel de las aplicaciones de escritorio, pero con todas las bondades de la web, portabilidad, actualizaciones, sandboxing, etc. (hasta acá el lema de cualquier plataforma RIA) pero con la simplicidad de desarrollar sobre los estándares HTML+CSS+JS, stack que hoy en día todo desarrollador y diseñador web se ve obligado a dominar.

Escenarios

Quizás sea demasiado pronto para identificar escenarios recomendados para uno y otro (al menos para mí) pero si se puede ir pensando en los trade-offs entre un estilo y el otro. Pero antes de empezar a hacer comparaciones es importante la siguiente consideración: no se trata de modelos excluyentes, ambos pueden convivir en una aplicación (inclusive en una misma página!), en vez de en 2 modelos alternativos podríamos pensar en un gradiente como este:

En un extremo del gradiente se ubican páginas de HTML estático, cuya única forma de interacción son links y formularios "planos", sin javascript. Salvo que se trate de un web site simple (en opuesto a una web application), tendremos en el server gran parte de la lógica de presentación y de navegación, y también prácticamente toda la lógica de negocios, la "responsividad" no es su fuerte y depende de la conexión.

En el otro extremo podemos ubicar las aplicaciones puramente MVC, en las que toda la lógica de presentación se maneja del lado cliente, así como una parte de la lógica de negocios, la responsividad es óptima y no depende de la conexión, inclusive pueden trabajar "offline" de forma esporádica o permanente.

Dónde están las aplicaciones "Progressive Enhancement"? Cómo se ve en el gráfico se "mueven" adaptativamente (según las capacidades de cada navegador) en un rango del gradiente, la granularidad y la amplitud del rango dependerá de como sean construídas en base a requerimientos.

Sobre el gradiente señale algunas de las variables (que encontré más significativas) que se crecen o decrecen con este gradiente, anticipándome a lo siguiente:

Trade-offs

Portabilidad

Esta es a primera vista una ventaja evidente del primer estilo, ya que a esto apunta PE. Las aplicaciones construídas de esta manera se adaptan dinámicamente a las capacidades del navegador o dispositivo cliente.
Sin embargo es probable que éste punto se vuelva cada vez menos decisivo con el tiempo.
Las aplicaciones MVC tienden a requerir motores Javascript más poderosos y dependiendo del caso algunos features de HTML5, sin embargo ambas cosas son cada vez más fáciles de encontrar en cualquier dispositivo moderno.
En computadores personales, el único escollo son las versiones de Internet Explorer, 6, 7 y 8, que desaparecen más lento de lo que quisiéramos: http://deathtoie6.com/. Sin embargo es posible actualizarse en todas las plataformas. En WinXP sólo puede llegarse hasta IE8, pero puede instalarse Chrome y otros navegadores en sus últimas versiones.
Todos las nuevas versiones de navegadores salen a competir con rimbombantes benchmarks de sus motores Javascript (IE9 es el último en incorporarse a esta especie de "guerra fría" y lo hizo con una comparación de IE9 vs Chrome (al estilo desafío Pecsi) en una de las Keynotes del MIX2011. Y en el keynote de Google I/O 2011 también hubo una demostración en este sentido).

En los dispositivos móviles de última generación (IPad, IPhone, Android, RIM, etc.) motores Javascript modernos y soporte para HTML5 es más fácil de encontrar que cualquier plugin de tecnologías RIA (Flash, Silverlight). Inclusive ya hay herramientas para construir aplicaciones usando HTML+CSS+JS que logran el mismo "look and feel" y acceden a las mismas APIs que las aplicaciones nativas en todas estas plataformas moviles (PhoneGap, AppCelerator Titanium) y con Android es probable que dento de poco podamos dispongamos de HTML5+CSS3+JS en TVs, heladeras y lavarropas :)

Por todo esto, las ventajas en portabilidad a la hora de implementar PE empiezan a desdibujarse.

SEO

Este es punto está claramente a favor de PE y probablemente siempre lo esté. Las aplicaciones MVC simplemente no son indexables al igual que las demás tecnologías RIA, salvo que se recurra a los mismos "trucos" que se utilizan hoy en día en otras RIA, que implican en mayor o menor medida duplicar, o generar un duplicado del contenido que sea indexable.
Si SEO es importante para nosotros necesitamos que nuestro sitio pueda moverse dignamente hasta el extremo izquierdo del gradiente, sin embargo hay que tener en cuenta lo siguiente: si nuestra aplicación es SEOdependiente, hay grandes chances de que estemos hablando del tipo de website que no se beneficia mucho de una arquitectura MVC, un sitio (o la parte de un sitio!) que presenta y permite navegar a través de contenidos no es un escenario muy tentador para MVC de todas formas.

Experiencia de Usuario

Si bien con PE buscamos mejorar hasta dónde sea posible la experiencia de usuario, claramente este punto lo ganan las aplicaciones MVC, en los que la experiencia es del nivel de las aplicaciones de escritorio. Claro que es posible "mejorar progresivamente" una página hasta que las diferencias desaparezcan, pero si lo hacemos es posible que nos acerquemos al problema del siguiente punto:

Servicios REST+JSON como BackEnd

Simplicidad

Si al construir el cliente web usando MVC transformamos nuestro BackEnd en un servicio REST+JSON

se mantiene toda la lógica de presentación en el cliente y se simplifican algunos problemas relacionados con la conservación de estado, como el manejo del sesiones, el ViewState, etc. el diseño del BackEnd se reduce a un caso trivial de SOA.

Interoperabilidad

Basándonos en un BackEnd REST+JSON podemos mantener el más alto nivel de interoperabilidad sin demasiado trabajo extra, ya que este tipo de servicio puede ser consumido fácilmente por otro tipo de aplicaciones (de escritorio (WPF), RIAs (Silverlight), procesos batch, un widget nativo para IPhone, etc, etc), y habilitando requests cross-origin (para los recursos/operaciones deseados) tenemos una API web pública que puede ser consumida desde otros sitios web.
Por lo general en aplicaciones web convencionales el agregado de una API pública implica duplicación de trabajo agreando un servicio de estas características.

Disponibilidad

Al eliminarse la dependencia del server para la renderización de contenido, mantenemos a tiro la posibilidad de implementar un modo offline que utilize datos locales (ej. HTML5 Isolated Storage, WebSQL)

Performance

Utilizando PE es posible ahorrar muchos requests, pero sobretodo se mejora la "performance percibida" (Responsividad). Pero utilizando MVC también se reduce el tráfico de red al mínimo, la separación entre datos (JSON) y HTML no sólo permite transmitir únicamente la información necesaria, sino que ahora el contenido estático (y por lo tanto cacheable en el cliente) además de imágenes, scripts (.js) y estilos (.css) también incluye el HTML (layouts y templates)

Escalabilidad

Además de la reducción de tráfico y el uso del cache cliente, se libera al server de la tarea de renderizar html, los clientes hacen trabajar al server sólo lo necesario (para solicitar datos que no se encuentran localmente, para persistirlos, para comunicarse con otros).

Separation of Concerns o Separación de Responsabilidades

Este es la característica esencial del patrón MVC con lo cual no es extraño que incluya este punto. Si bien el título es SoC podríamos hablar más ampliamente de simplicidad y elegancia del diseño tanto del modelo de programación como de la arquitectura.
Basta con mirar la claridad que se logra en los ejemplos que diferentes frameworks MVC presentan, cualquier programador que haya trabajado en aplicaciones cuya interfaz HTML adquiere cierta complejidad habrá sentido la necesidad de un modelo superador que simplifique el código escrito.
Además llevando el patrón MVC al cliente podemos eliminar la "impedancia" que produce la división de nuestra capa de presentación entre servidor y cliente.
Esta impedancia es la misma que Asp.Net WebForms busca disminuir abstrayendo la interacción con el usuario web en un modelo de programación que se asemeja al de una aplicación WinForms (de escritorio), sin embargo quiénes hayan tenido sus luchas con el ciclo de vida y el manejo del view state, entenderán que la impedancia no desaparece.

Para terminar de ilustrar la diferencia desde el punto de vista arquitectónico en este diagrama muestro como estos dos estilos de aplicación HTML (PE y MVC) pueden impactar en la arquitectura de las aplicaciones que las soportan:

Utilicé colores anaranjados para indicar componentes que son especificos de (es decir, deben ser desarrollados para) cada aplicación.

Estos diagramas no deben tomarse como la única combinación posible, sino de un ejemplo de la forma que tomará típicamente la arquitectura de la aplicación para soportar un caso u otro.

Madurez

Este es quizás el punto que más juega en contra de los frameworks Javascript MVC existentes, las aplicaciones PE son en realidad lo más cercano a una aplicación web tradicional, es un camino muy recorrido, y esto implica las ventajes usuales:

Experiencias previas, sin importar el problema que encaremos, seguramente encontraremos el camino muy allanado
Hay muchos profesionales preparados para trabajar de esta forma y también muchos dispuestos a ayudarnos en distintas comunidades online.
Herramientas, muchas y muy maduras

De todas formas:

Las aplicaciones MVC/MVVM adquieren masa crítica muy rápidamente, probablemente ésta se convierta en la plataforma RIA de facto, no por ser la mejor de todas, los estándares en que se basa, las marcas que lo soportan, lo hacen un caso típico de profecía autocumplida
No se trata de un entorno totalmente desconocido, se trata de HTML+CSS+JS, es en los frameworks existentes y librerías de funcionalidades aledañas (template engines, storage, etc.) dónde está la inmadurez
En cuanto entornos de desarrollo:

La evolución de herramientas de desarrollo en los navegadores ha hecho mucho más ameno desarrollar (y sobretodo debuguear) este tipo de aplicaciones
En la mayoría de las IDEs existentes existe un soporte razonable para escribir Javascript, Para VisualStudio 2010 existen algunas mejoras al respecto:

Intelissense con background compilation!
Adaptador de JsDoc para VisualStudio
Plugin para Outlining

Todo parece indicar que si bien las aplicaciones que llame "Progressive Enhancement" seguirán siendo las predominantes, empezaremos a ver una coexistencia entre ambos tipos de aplicaciones, y seguramente haya muchas novedades sobre frameworks Javascript MVC/MVVM/MVVM.

Si alguno tuvo alguna experiencia en el uso de Javascript MVC en proyectos reales me encantaría que la compartan,

Saludos

Coding Koan - La (no tan misteriosa) senda del programador Zen

noreply@blogger.com (Benjamin Eidelman) — Fri, 11 Feb 2011 14:06:00 +0000

Recientemente en una nota en Code&Beyond se hablabla sobre Koans para programadores.
Los Koans son una especie secuencias de ejercicios, pensados para guiar la meditación Zen.

http://www.codeandbeyond.org/2011/02/meditacion-programatica-koans.html

Algunas personas están trasladando este concepto a la programación, estos Koans para programadores son una batería de tests unitarios inicialmente fallidos,
Un software asiste al aprendiz (un framework de unit testing, más algun plugin o pieza de software específica) para hacer pasar los tests uno por uno.
Cada test obliga a aprender algo nuevo, es una forma de aprendizaje excelente.

"Me lo contaron y lo olvidé; lo vi y lo entendí; lo hice y lo aprendí". Confucio

Los hay sobre diversos temas, y sobre diferentes lenguajes de programación en la nota hay links para varios de ellos, me pareció interesante el de JavaScript. Es un lenguaje con mala fama, y parte de eso se debe a que es muy utilizado esporádicamente por desarrolladores web, y no siempre con atención a las "buenas prácticas".

JavaScript Koans

Existe todo un movimiento por tomar JavaScript "en serio", como una serie de buenas prácticas que suelen englobarse con el nombre de "Unobstrusive Javascript".
Esto combinado algunos proyectos recientes que hacen pensar que JavaScript sea quizás el único lenguaje necesario: V8, Node.js (que tiene ahora un versión para .Net , Node.Net), Rhino, etc.
(Esto es tema para otro post!)

https://github.com/liammclennan/JavaScript-Koans#readme

Primeros pasos

Se baja el zip (Download), y después de descomprimirlo al abrir jskoans.htm se ve lo siguiente:

Nota: como vemos este Koan usa QUnit, un framework de Unit Testing para JavaScript, es por ej. el utilizado por jQuery.

Siguiendo la sugerencia, abrimos 'topics/about_asserts.js' y hacemos algunas correciones:

Actualizamos la página ...

Exito!, vemos el resultado positivo de los tests modificados, y ahora que aprendimos lo básico sobre los Asserts, se nos presenta el próximo desafío ("About Equality"), el Koan continúa asi sucesivamente. Éste consta de 14 tópicos, algunos que a veces sorprenden como closures o prototypal inheritance.

Una forma muy efectiva y entretenida (después de todo, ambas cosas van de la mano) de aprender y enseñar. Además los koans por estar basados en Unit Tests son mucho más fáciles de mantener actualizados, lo que resulta un problema frecuente en materiales didácticos, al menos en esta industria.

Resolviendo un desafío en equipo

noreply@blogger.com (Nora Martinez) — Mon, 17 Jan 2011 15:05:00 +0000

En Noviembre pasado, Kinética Solutions nos hizo partícipe de una capacitación, sobre Test Driven Development (TDD), que brindó a su equipo de trabajo.

Esta capacitación se dividió en dos jornadas: la primera consistió en una charla introductoria del tema, la segunda fue un Workshop con el formato “Coding Dojo” para practicar un poco de Test Driven Development (TDD).

En este artículo les contaré la experiencia de los participantes de TercerPlaneta con el “Coding Dojo”.

¿Que es “Coding Dojo”?

Un Coding Dojo es una sesión de codificación centrada alrededor de un desafío de programación, de alcance pequeño. Todos los asistentes a esta sesión participan en la codificación para resolver el desafío planteado.

El objetivo es aprender, enseñar y mejorar nuestras habilidades de programación, compartiendo conocimiento y experiencia con otros desarrolladores de software, en un ambiente relajado.

La versión de Coding Dojo que propuso Kinetica Solutions es Randori, la misma consiste en utilizar una única computadora y un proyector. Los participantes de la sesión, en parejas, van utilizando la computadora durante una cantidad de tiempo fija y acotada, para codificar una porción de código de la solución. Una vez concluido el tiempo, dejan lugar a otra pareja de programadores para que continúen con el desafío.

Resolviendo el desafío

El desafío propuesto fue:

Llevar los puntos de un partido de tenis

sencillo, no?

Todos conocíamos cómo se llevan los puntos en un partido de tenis, con lo cual el primer paso para entender el alcance estaba dado, y así podíamos comenzar a resolver el problema

Para la dinámica del workshop se definieron 10 minutos para que la pareja de “piloto y co-piloto” se adueñen de la computadora y codifiquen un test (recordemos que estábamos haciendo TDD) y el código correspondiente para que pase el test.

Las parejas no se formaron al inicio del taller, sino que se iban formando a medida que comenzaba un nuevo período de tiempo. Rápidamente dos participantes, en forma voluntaria, se proponían para pasar a la computadora, y entre ellos decidían quien haría de piloto, haciéndose cargo del teclado y mouse, y por lo tanto el otro voluntario actuaría de co-piloto, aportando en el armado del código. Juntos decidían qué probar, mientras el resto del auditorio podía aportar ideas, pero siendo respetuosos ya que los “dueños” del código durante los 10 minutos de cada sesión, eran los “dueños temporales” de la computadora.

Una vez que se llegó a la mitad de la sesión, hicimos una Retrospectiva, con el objetivo de realizar los ajustes necesarios para completar el desafío en la siguiente mitad. Algunos cambios que surgieron fueron:

tener 2 minutos de “yapa” para terminar de desarrollar la idea;
la pareja que pasa a la computadora primero deja en claro para todos lo que va a hacer;
para la misma pareja, se intercambian los roles de piloto y co-piloto.

En la segunda mitad, se llevaron a cabo los cambios propuestos y se logró que todos conozcan mas y puedan participar mejor en la resolución del desafío planteado.

Moraleja

A pesar que no se completó la resolución del desafío planteado, sí se pudo cumplir con los objetivos del Coding Dojo: mejorar las habilidades de programación y hacerlo en un entorno distendido.

En particular, a los integrantes de Tercer Planeta, nos brindó la posibilidad de aprender un poco mas acerca de la dinámica detrás de TDD y participar en un workshop con el formato Coding Dojo.

Además, nos permitió compartir con nuestros colegas de Kinetica Solutions una actividad mas, la cual fue muy enriquecedora:

intercambiamos experiencias en la generación y uso de pruebas unitarias
hicimos pair programming con chicos de Kinetica
nos ayudó a hacer hincapié en tener claro qué codificar antes de “tirar” líneas de código
nos permitió interactuar con otros desarrolladores compartiendo un momento ameno, distendido y divertido
fue interesante codificar frente a un auditorio y recibir consejos, ayuda y opiniones
el espíritu que reinó durante el taller fue que todos, como un solo equipo, teníamos el objetivo de resolver el desafío.

¡Agradecemos la invitación y esperamos que se repita pronto!

Jornadas Anuales Versión 2010

noreply@blogger.com (Lucila Santos) — Wed, 24 Nov 2010 14:36:00 +0000

Acercándonos a diciembre, todos nos encontramos planificando reuniones y despedidas.
Nadie deja de celebrar de alguna manera el cierre del año. Fiestita, happy hour, eventos de todo tipo y color. También evaluaciones de objetivos, controles de desempeño.

Nuestra empresa no escapa a la tradicional costumbre, pero dándole un toque distintivo. No nos conformamos con un simple brindis ni con el animador de turno. Tampoco queremos terminar el año sin hacer una retrospectiva del mismo.
Por eso es ya una obligación escaparnos de la vorágine laboral hacia algún punto turístico. Playa o campo, lo importante es compartir un mini break con la gente de la oficina. Queremos hacer un preview de las vacaciones y simultáneamente repasar el trabajo de los últimos meses.

Con este espíritu nos encaminamos este año hacia La Posesiva, un antiguo casco de estancia en Capilla del Señor dedicado ahora al turismo. Lo primero que se nos propuso en la charla inicial al llegar fué detenernos un poco y disfrutar del lugar, como premio a un año difícil y de muchísimo trabajo.
Empanadas, asado, alguna jineteada, ping pong y por supuesto metegol! Todo esto para lograr concentrarnos en el tarea de descansar y divertirnos.

Todo este despliegue de tiempo libre suscita más de un resquemor. No deberíamos estar evaluando los objetivos de la empresa? Cuáles fueron los puntos débiles del trabajo del año? Cómo estuvimos en comunicación?
Mejoramos en la implementación de las nuevas tecnologías? Pues bien, este año la consigna fue 'no hablar' de todo esto. Simplemente descansar, olvidarnos de las presiones diarias y pasar un buen rato.

Después de todo un día sin 'hacer' nada, la llegada de Carola Herrscher una de nuestras coach de Nuevas Miradas, parecía el momento de corte para empezar a hablar de algo serio. Reunidos el viernes a la mañana, nos propuso jugar a 'El teléfono descompuesto'. Contar una historia a un integrante, y esté debe representársela a otro. Este último a su vez re actúa lo entendido para un tercero. Finalmente el que termina debe explicar con palabras el cuento original a toda la audiencia.

Después de divertirnos un rato comprobando nuestras dotes actorales,terminamos el juego, tratando de descubrir algún mensaje o metáfora. Pero esto fué tarea para cada uno. Caro simplemente condujo. No dijo nada ...

Segundo juego : las manos en la masa!
Arcilla. Una buena hora para desarrollar capacidades creativas. Por cierto muy enterradas o inexistentes en algunos, increíbles en otros. Pero faltaba lo mejor: romper todo lo hecho! Seguir el trabajo de otro! Volver a empezar otra obra! Finalmente ... la construcción de la casa entre todos. Cada uno armó algo, todos aportamos y nos dimos cuenta de lo difícil que es armar algo coherente sin ponernos de acuerdo y planificar antes ... En fin, nuevamente Caro dijo poco, pero todos nos divertimos y no nos dimos cuenta que habíamos pasado toda la mañana trabajando.

Mientras todos jugábamos, Andrea y José trabajaban intensamente. Dedicaron un buen rato de su tiempo para charlas individuales con cada uno. La idea de estos encuentros es hacer una especie de 'evaluación de desempeño'. Con su estilo directo y sencillo, nos ayudaron a ver los logros. Que por cierto no son pocos, hacia afuera y dentro de la empresa. Con tanta asertividad, lograron que cada uno se propusiera buenas metas para el 2011 ...

Conclusiones después de estos dos días?

Qué difícil es no hacer nada 'serio' y no hablar de nada filosófico!
Es raro no evaluar, corregir ni planificar. Pero qué importante es conocer a los otros desde otra óptica. Respetar este tiempo de silencio. Darnos cuenta que en la acción conjunta está el valor, y que el ver a otros de una manera distinta enriquece al grupo y a cada uno.

Después de un año de trabajo intenso con el tema de la comunicación, la integración y profundizando en distintas metodologías de trabajo este corte 'formalmente informal' fue más que positivo.

Que es repita!!!

Visitando Giran

noreply@blogger.com (Benjamin Eidelman) — Mon, 08 Nov 2010 19:03:00 +0000

A principios de este año fue lanzado internamente en Tercer Planeta, la iniciativa "PAI".
PAI no implica nuestra conversión a la religión Umbanda, sino que se trata de las siglas Profesionalismo, Apertura e Intercambio.
Sin entrar en demasiados detalles, cómo parte de esta iniciativa incurrimos en muy diversas acciones, por ejemplo:

Charlas de intercambio de "know-how", con grupos de desarrollo internos en nuestros clientes: http://blog.tercerplaneta.com/2010/09/intercambiando-experiencias.html

Asesorarnos por expertos a la hora de acompañar el crecimiento profesional de nuestro equipo: http://blog.tercerplaneta.com/2010/07/como-entendemos-el-crecimiento.html

Organizar un mini-ciclo de charla-debate en forma conjunta con Kinetica, a la cual invitamos algunos de nuestros clientes: http://blog.tercerplaneta.com/2010/08/debates-que-enriquecen.html

PAI Mercosur

La presentación de esta iniciativa en las oficinas de Tercer Planeta se realizó a principios de este año, mientras yo me encontraba trabajando de forma remota desde Vitória, Brasil, asi que asistí via Skype a este anuncio (empanadas acá, suco de manga allá), así fue que tuve la idea de coordinar algun tipo de intercambio con una empresa de la ciudad donde me encontraba, asi fue como buscando en algunos eventos de la comunidad ágil de la región encontré una empresa que se posicionó como referente en metodologías ágiles de Espirito Santo (estado del sudeste brasilero), Giran

Turismo Ágil

Me puse en contacto con la idea de hacer una visita similar a las que hemos hecho con otras empresas cercanas, con el fin de intercambiar algunas ideas, y muy cordialmente me invitaron a visitarlos, lo que finalmente pude concretar el mes pasado.

View Larger Map

Giran es una empresa muy joven (cumplieron un año recientemente) y nació como una empresa enfocada no sólo en la práctica, sino también en la enseñanza y mentoring de metodologías ágiles, especialmente SCRUM + XP. Por lo cual mi visita, como supuse, fue muy fecunda.

Por el lado tecnológico usan en sus proyectos (y enseñan) Java, PHP y Ruby on Rails.

El primer día que los visité se encontraban en medio de un sprint bi-semanal, con lo cual pude asistir, luego de
la charla técnica de la semana, a la reunión diaria y parte del desarrollo. Me recibieron muy amablemente y son muy divertidos :), por supuesto, no sólo es un equipo ágil de geeks, además son brasileros!.

Finalmente asistí a la retrospectiva de ese sprint, el cuál resulto ser un sprint con varios imprevistos, lo que hizo más interesante mi visita :)

Me llamó la atención la ausencia total de "roces" o comentarios CYA entre miembros del equipo (esperables en un sprint accidentado), y como todos los integrantes se mostraron muy involucrados en la mejora contínua del proceso SCRUM, admirable.

De la visita me quedo con una grata experiencia y varias ideas interesantes que observé, sin duda tenemos mucho por aprender y enseñarnos, queda la puerta abierta para futuros encuentros.

Con parte del equipo de Giran en sus oficinas

Trabajo en background

noreply@blogger.com (Matías Timossi) — Mon, 08 Nov 2010 17:19:00 +0000

Durante la construcción de una aplicación es habitual encontrarnos con procesos que son muy lentos y no dan feedback al usuario. A continuación les mostramos una de las formas de resolverlo utilizando un control que nos brinda .Net a partir de su versión 2.0: el BackgroundWorker.

Caso de Uso

Una de nuestras aplicaciones tiene una pantalla donde se muestran filtros para obtener un informe que finalmente se graba en un archivo con formato Excel. Anteriormente, cuando el usuario apretaba el botón para iniciar el proceso, la pantalla se quedaba congelada hasta que la búsqueda de datos terminaba. En ese lapso de tiempo no se podía saber que estaba pasando: si se debía seguir esperando, o todo había dejado de funcionar. Aún informando “el proceso puede demorar”, después de unos instantes la aplicación comenzaba a mostrarse con el alerta de “(No Responde)” y el usuario ya no sabía si seguir esperando, cancelar la ejecución de la aplicación, o en el peor de los casos reiniciar la computadora.

Por que la decisión de usar el BackgroundWorker

Al comprobar que la performance de la búsqueda ya había sido optimizada desde el motor de bases de datos, llegamos a la conclusión de que debíamos hacer algo para que la aplicación no quede inutilizable mientras se genera el reporte. Sabiendo que lo más importante del reporte es el resultado final, decidimos hacer todo el proceso de búsqueda de los datos en un segundo plano y así lograr que la aplicación siga funcionando sin inconvenientes, incluso para realizar otras tareas que necesiten utilizar al mismo tiempo la base de datos de la que estoy esperando la respuesta para el reporte inicialmente deseado.

A pesar que no es ampliamente configurable y adaptable a todo tipo de necesidades, como podría serlo una solución que maneje varios hilos de ejecución desarrollada manualmente, el BackgroundWorker tiene una serie de ventajas muy prácticas para nuestra necesidad en particular y nos evita, entre otras cosas, planear la solución ideal para el problema y escribir “bastante” código para manejar hilos de ejecución lo cual es sumamente delicado ya que debemos tener en cuenta el ciclo de vida de cada hilo (y no perder ninguno en el camino), la comunicación entre distintos hilos de ejecución, validar y manejar posibles errores, etc..

Todo esto sumado a que solo necesitamos realizar una única tarea indivisible, que consume mucho tiempo y no podríamos mejorar eso con más hilos de ejecución nos llevó a tomar la decisión de inclinarnos por el BackgroundWorker.

Manos a la obra

Veamos cómo en pocos pasos y sin mucho esfuerzo podemos obtener una aplicación que utilice varios hilos de ejecución.

Inicialmente nuestro código lucía así.

Lo primero que debemos hacer es agregar un control BackgroudWorker en el designer del form y configurar los eventos a usar. Básicamente en nuestro ejemplo utilizamos dos:

DoWork : Evento lanzado desde el código para realizar las tareas asincrónicas

RunWorkerCompleted : Evento lanzado por el control una vez finalizada la ejecución de las tareas asincrónicas.

Una vez hecho ésto lo único que resta hacer es reorganizar el código:

Si observan con atención al hacer clic en el botón invocamos al método RunWorkerAsync que se encarga del manejo de hilos y realización de tareas en background lanzando el evento DoWork.

Antes debemos verificar que el control no se encuentre trabajando actualmente, de esta forma evitamos un error.

En el evento DoWork indicamos cuáles son las tareas que se ejecutan asincrónicamente, en nuestro caso hacemos el llamado a la base de datos.

Vale aclarar que contamos con la opción de pasar como parámetro un objeto a través del RunWorkerAsync que es recibido dentro del DoWorkEventArgs. Esto puede ser de utilidad si necesitamos tener acceso al estado de objetos definidos en nuestro primer hilo de ejecución.

Finalmente en el evento RunWorkerCompleted colocamos todas las tareas que debemos realizar una vez que se ejecutaron todas las tareas asincrónicas. En nuestro ejemplo, como ya obtuvimos los datos debemos generar el reporte

Conclusión:

El BackgroundWorker nos brinda la posibilidad de que nuestras aplicaciones WinForms sean más “ágiles” y luzcan más “veloces“ en la realización de tareas que demandan demasiado tiempo, siendo además su implementación muy sencilla.

Intercambiando experiencias

noreply@blogger.com (Marcelo Waisbaum) — Tue, 14 Sep 2010 14:55:00 +0000

Parte del valor agregado de la empresa es su preocupación (o mejor dicho ocupación) por ensayar cosas nuevas, siempre probando las ultimas tecnologías y metodologías.

Uno de los objetivos que nos impusimos para este año es abrir Tercer Planeta al mundo. Es decir, intentar dar a conocer más lo que ocurre acá adentro (las prácticas que utilizamos, los experimentos técnicos y los problemas con los que nos enfrentamos) y al mismo tiempo poder aprender de las experiencias de otros grupos de desarrollo. Para esto nos propusimos varios hilos de acción, entre ellos escribir mas seguido en este blog.

Otro hilo, el que nos ocupa en este post, fue armar un encuentro de intercambio de experiencias con el equipo de desarrollo de uno de nuestros clientes.

La idea en este primer encuentro fue juntarnos para que cada equipo presente dos temas que consideraba que era interesante mostrarle al otro. Después de una previa coordinación de temas y logística, encaramos el encuentro con la participación de todos los desarrolladores de cada equipo.

Desarrollo

El encuentro arrancó con un “check in” donde contamos los objetivos del encuentro. Luego cada uno se presentó, esto es importante para desarrollar cualquier charla pero en este caso también fue la oportunidad de conocer la cara detrás de los mails!

Después expusimos intercalando una presentación por equipo.

Nuestro equipo presentó dos temas:

Un Sprint en 3p: Armamos una presentación donde contamos las metodologías que aplicamos en un sprint de un proyecto. En la misma mostramos la implementación que hacemos de las reuniones diarias, la planificación, el desarrollo, el uso de los pizarrones, la demo y la retrospectiva entre otras prácticas aplicadas.
BackgroundWorker: el uso del control, ventajas y desventajas y los problemas con los que nos enfrentamos al implementarlo. Este control facilita el manejo de distintos hilos de ejecución (próximamente tendremos un artículo del blog que profundice sobre este control)

El otro equipo de desarrollo presentó:

Controles customizables: Una muestra de los nuevos controles DevExpress (para mas informacion ver http://www.devexpress.com/) que utilizan y las ventajas para el usuario que traen. Estos controles brindan la posibilidad de que el usuario les cambie los colores, los cambie de lugar, etc., guardando esta configuración para poder tener siempre la aplicación como cada usuario prefiere verla.
SpreadsheetGear: El uso de las nuevas clases de SpreadsheetGear (para mas informacion ver http://www.spreadsheetgear.com/) usada para generar reporte en Excel. También nos mostraron algunos agregados que hicieron a estas clases para poder resolver algunos pedidos de los reportes.
Envío de mails: Formas de realizar el envío de mails desde una aplicación, los problemas con los que se encontraron y las configuraciones necesarias.

Todas las presentaciones contaron con momentos de debate y preguntas que sirvieron para enriquecer el intercambio. En esos momentos aprovechamos los conocimientos y experiencias de cada uno, que por suerte son muy diversos, para aportar a las presentaciones y hacer preguntas que ayuden a profundizar los temas planteados.

Al finalizar propusimos armar una retrospectiva en 3 columnas: Lo que me gusto de la charla, lo que me gustaría que pase en la próxima charla y lo que nos comprometemos a hacer para el próximo encuentro. La idea fue tomarnos diez minutos para pensar que cosas estuvieron buenas del encuentro y que cosas nos interesaría profundizar, por ejemplo: temas técnicos (como Silverlight o la velocidad en las páginas web) y otros relacionados con la dinámica de los encuentros. Al final votamos y pusimos objetivos puntuales para un próximo encuentro: proponer distintas metodologías que se pueden utilizar e intentar resolver entre todos algún problema técnico que tenga alguno de los dos equipos en un desarrollo.

En la retrospectiva tuvimos visiones bastante parecidas, varias de las cosas que salieron podríamos agruparlo en lo positivo que fue el conocer las metodologías de trabajo de cada equipo y, por otro lado, lo interesante de ver distintas miradas de un mismo problema.

Conclusión

Lo interesante del encuentro fue poder mostrar los problemas con los que nos enfrentamos y poder aprovechar las diferentes visiones para aportar soluciones.

Es muy interesante ver como trabajan los distintos equipos de desarrollo y como para un mismo problema se encuentran distintas soluciones.

Otro aspecto positivo de estos encuentros es que es muy motivante ya que ayuda a valorar el trabajo que uno hace cotidianamente y a ver otras cosas muy interesantes que uno en el trabajo del día a día no llega a poder profundizar.

También nos ayuda a conocernos más con el cliente y generar una relación de mayor confianza que mejora el trabajo diario.

Aprendiendo un poco más acerca de la Retrospectiva

noreply@blogger.com (Nora Martinez) — Mon, 06 Sep 2010 13:25:00 +0000

Recientemente leí el libro "Agile Retrospective" de Esther Derby y Lana Larsen. Me resultó interesante, sencillo de leer, lleno de conceptos claros y principalmente, con ideas y consejos para poner en práctica. Está fundamentalmente orientado hacia los que dirigen una retrospectiva, acercándoles herramientas y conocimiento para facilitar su labor.

Al libro lo podemos dividir en dos partes: la primera presenta las habilidades y consideraciones que tendría que tener aquella persona que lidere una retrospectiva; la segunda parte describe algunas actividades que se pueden llevar a cabo durante las diferentes etapas de una retrospectiva.

En este artículo dejo algunas anotaciones que me parecieron mas interesantes y útiles para remarcar, acerca de la primer parte.

Acerca de la retrospectiva
La retrospectiva es una reunión que se lleva a cabo cuando termina un hito (iteración, release, proyecto), en la cual participan los miembros del equipo. Su fin es lograr que los participantes hagan una revisión de lo que pasó, inspeccionen y adapten sus métodos de trabajo y su forma de trabajar como equipo para incrementar la calidad del producto y mejorar el trabajo y la calidad de vida de los miembros.

Algunos puntos importantes para remarcar acerca de esta reunión:

Tiene que aportar valor al equipo, así los participantes no piensan que es una pérdida de tiempo
Hay que definir su objetivo, para tener una meta a la cual llegar
Se tiene que establecer el tiempo de duración y respetarlo

Con respecto a quien lidere la retrospectiva, también citado como facilitador, se destaca:

Tiene que entender su rol y las funciones inherentes al mismo
Permanece neutral durante las discusiones
Maneja la dinámica del grupo, permitiendo que todos participen de igual forma

Acerca del equipo:

Identifican sus valores como equipo y los respetan
Establecen acuerdos de trabajo (reglas para la colaboración y la convivencia) y son responsables por hacer que todos los respeten
Entienden la importancia de su participación en pos de la mejora continua
Asumen un compromiso, al finalizar la retrospectiva, para cumplir con lo acordado

Estructura de una Retrospectiva
La retrospectiva puede dividirse en 5 fases o etapas:

Setear el estado
Recopilar datos
Profundizar
Decidir qué hacer
Finalizar la retrospectiva

Setear el estado
En esta fase el facilitador le presenta al equipo el objetivo de la retrospectiva y la agenda para poner en conocimiento cómo van a invertir el tiempo.

La información que se recolecte lo ayudará a trabajar con el equipo en la elección de un objetivo apropiado. Lo que observe le dará las pistas acerca de qué preguntas hacer y qué problemas podría enfrentar el equipo.

Un objetivo útil ayuda a contestar la pregunta: "¿Cuál será el valor que se obtenga en el tiempo que dure la reunión?" proporcionando una razón para que las personas inviertan su tiempo en la reunión. Si se define un objetivo amplio ayudará al equipo a que pueda reflexionar y pensar creativamente acerca de sus experiencias y descubrir los puntos de vista que sean importantes para los integrantes.

Evitar los objetivos que definan un resultado específico; por ejemplo, el objetivo "Determinar cómo persuadir a Recursos Humanos para eliminar las evaluaciones de desempeño", bloquea la consideración de otros canales de acción u otros problemas que el equipo esté enfrentando.

Algunos objetivos útiles:

Encontrar maneras de mejorar nuestras prácticas
Descubrir qué se hizo bien
Entender las razones detrás de los objetivos no alcanzados
Reconstruir relaciones dañadas

Se le puede solicitar al equipo que describa un objetivo.
En cuanto a la duración, es proporcional a la cantidad de personas que participan de la retrospectiva y al tiempo transcurrido desde la retrospectiva anterior. Otros factores que influyen son:

Complejidad, en cuanto al entorno tecnológico, relaciones entre los miembros del equipo o con departamentos externos, organización del equipo
Nivel de conflicto o controversia (planear mas tiempo para tratar temas complicados)

Si el tiempo es extenso, guardar tiempo para recreos entre las distintas etapas de la retrospectiva. También estar atento, durante el desarrollo de la misma, si el equipo necesita descansar unos minutos.

Recopilar datos
Una vez que se conoce el objetivo, se crea una imagen compartida de lo que sucedió en el tiempo que se está evaluando, con esta imagen común, se puede evitar que los participantes analicen según sus propias opiniones y creencias.
Armar la información y eventos en forma visual, para que las personas vean fácilmente patrones y conexiones. Los hechos son una parte de la información, y la otra mitad son los sentimientos, las emociones, éstas dicen lo que es importante para las personas de los hechos y hablan acerca del equipo.

Profundizar
Ahora es el momento de preguntar "¿Por qué?" y comenzar a pensar acerca de soluciones para hacer de forma diferente. Es un momento en que el equipo piensa en conjunto.
Considerar posibilidades adicionales, no quedarse con la primer solución que aparece. Buscar las causas y efectos, y pensar más analíticamente.

Decidir qué hacer
Elegir algunas de las soluciones (2 o 3, no tienen que ser muchas) y planear qué hacer.
Muchas veces el equipo tiene una lista larga de mejoras pero esto puede ser contraproducente ya que tener demasiadas iniciativas pueden abrumar y entorpecer la habilidad para cambiar. El facilitador tiene que ayudar al equipo a elegir los ítems a los que pueden comprometerse y que tengan un efecto positivo.
Una forma de planear los experimentos y los cambios es crear historias o ítems para que puedan ser incluidos en el próximo plan de trabajo de la iteración. Esta es una forma en que se asegure que las personas se comprometan a ejecutar las tareas; sin un compromiso individual, las personas asumen que "el equipo" hará la tarea, y entonces nadie la hace.

Finalizar la retrospectiva
Al completar el plan de acción, terminar en forma clara la reunión. Decidir cómo documentar la experiencia y el plan a seguir.
Lo que se aprende le pertenece al equipo y a sus miembros. El equipo necesita adueñarse de las enseñanzas que consigue.
Antes de finalizar, tomarse unos minutos para evaluar la retrospectiva que se llevó a cabo (sería una retrospectiva de la retrospectiva).

Beneficios de esta estructura

Entender los diferentes puntos de vista
Seguir un orden natural de pensamiento
Tomar una visión comprensiva de los métodos del equipo y sus prácticas
Permite que las discusiones vayan adonde se necesita
Queda una acción concreta y experimentos para realizar en la próxima iteración.

Dirigiendo Retrospectivas

No se necesita ser un facilitador experto para liderar una retrospectiva, pero sí necesita contar con algunas habilidades básicas. Estas habilidades se pueden aprender, para lo cual es necesario primero entender el rol, practicar y buscar feedback para ir haciendo los cambios necesarios.

Un facilitador de retrospectiva tiene como principal responsabilidad dirigir el proceso, es decir gestionar las actividades, la dinámica de grupo y el tiempo. Él permanecerá neutral durante las discusiones, aún si tiene opiniones firmes o si son temas que le preocupan, ya que si se involucra en las discusiones perderá total atención al proceso.

Los participantes se focalizan en el contenido, discusiones, desacuerdos (pero no desagradables) y toman decisiones; apuntan a un objetivo y manejan sus propios pensamientos, sentimientos y respuestas así contribuyen positivamente a las conversaciones y al resultado.

Si el facilitador, durante la retrospectiva, considera que tiene algo importante que ofrecer, puede contribuir en la discusión, pero antes debe ceder su rol a otro miembro. Una vez ofrecido su aporte, recuperará su rol.

Actividades
En cada una de las fases se puede realizar alguna actividad para crear acuerdos de trabajo, construir una línea de eventos en el tiempo, hacer una lluvia de ideas o priorización, entre otras . Las actividades ayudan al equipo a pensar en conjunto. Será necesario introducir y explicar cada actividad, monitorear su desarrollo y sacar conclusiones al finalizarla.

Puede ser de mucha utilidad armar un guión de la actividad y practicar las instrucciones para recordar qué decir. Tener presente, que como líder de la retrospectiva, es responsable de contestar todas las preguntas acerca de la actividad y monitorearla, centrándose en el nivel de ruido del grupo, mientras trabaja, para tener una pista si las personas necesitan mas tiempo o ya finalizaron.

El sacar conclusiones de cada actividad ayudará al equipo a examinar su experiencia y extraer diferentes puntos de vista.

Manejar la Dinámica del grupo
Está relacionado con la participación de las personas durante la reunión, asegurándose que las personas que tienen algo que decir tengan la oportunidad de decirlo y asegurarse que quien tiene demasiado para decir no domine la reunión.

Otra faceta tiene que ver con estar atento al lenguaje que utilizan los participantes de la retrospectiva. Si éste tiende a culpar a otros, como sucede con el "lenguaje de vos" ("Vos rompiste el build") y con las "etiquetas" ("Vos sos inmaduro"), ésto derivará en que algunos integrantes comiencen a estar a la defensiva. Estas actitudes hieren la retrospectiva, distrayendo la atención de los problemas reales.

El facilitador tiene como función fomentar el lenguaje "Yo", este lenguaje se centra en la experiencia y observación de la persona que habla, en lugar de etiquetar a las otras personas. Al escuchar culpas o críticas, el facilitador tiene que intervenir y redireccionar la discusión.

Otro punto importante en la dinámica de grupo está relacionado con la interacción y las emociones de los miembros del equipo. A pesar que el facilitador no es responsable de las emociones de otras personas, es responsable por mantener una reunión productiva. Esto significa que tiene que estar preparado para manejar situaciones e interacciones emocionales.

En la retrospectiva, lo primordial es la interacción del equipo como un todo, no de individualidades. Esto no significa que se tengan que ignorar las emociones individuales, al contrario, significa tratar con emociones en una forma que sea de ayuda y respeto al equipo y al individuo.

Manejar el tiempo
El facilitador de una retrospectiva tiene que responder a las necesidades del grupo y prestar atención al tiempo para respetar el tiempo fijo, presentado en la agenda de la retrospectiva, en la fase Setear el estado.

Si una discusión, al cumplirse el tiempo estipulado, aún no finalizó y sigue en su punto alto, el facilitador le preguntará al grupo qué desea hacer: continuar con la discusión o seguir a la siguiente fase o actividad. Ésta decisión queda en manos del equipo, no del facilitador. Generalmente, la respuesta es clara para todos; cuando no lo es, se propone limitar la discusión en curso a un tiempo fijo o revisarla luego o en otra retrospectiva.

Dado que el facilitador tiene como responsabilidad que se llegue al objetivo de la retrospectiva (identificar y planear experimentos y mejoras), tiene que estar preparado con actividades extra de diferente duración, en caso que se requiera cambiar por una mas corta.

Manejar al facilitador
Además de manejar las actividades, la dinámica del grupo y el tiempo, cada facilitador tiene que poder manejarse a él mismo.

Estar atento a la dinámica de equipo e interpersonal puede resultar abrumador. No existe una técnica para manejar la dinámica del grupo (aunque sirve tener algunas estrategias). La clave radica en entender y manejar su propio estado emocional y sus respuestas, para poder mantenerse centrado en su responsabilidad.

Cuando las emociones están en un nivel alto, el equipo necesita a alguien que esté fuera de la confusión; esa persona es el facilitador de la retrospectiva. Por lo tanto, tiene que mantener la calma y la claridad durante toda la reunión. Él mismo sabrá si necesita unos minutos de descanso para recobrar su serenidad o para oxigenarse y, de esta forma, pensar con claridad y bajar la ansiedad y tensión. Así, una vez que logre re-centrarse, podrá utilizar alguna estrategia para manejar al grupo y cumplir con su responsabilidad. Tiene que tener siempre presente que no es quien causa las emociones y no es responsable por hacer que todos estén felices y bien.

Es muy práctico que cada facilitador encuentre un tutor, en quien confie y a quien haya visto manejar las emociones en un grupo. Él lo ayudará a ganar confianza y aprender mas opciones para manejar situaciones emocionales. También le brindará el feedback que necesita para mejorar sus habilidades como facilitador.

Opinión personal
Después de haber estado en varias retrospectivas de diferentes equipos, como observadora o participante, leer el libro me ayudó a valorar la importancia del facilitador y de entender la dinámica del grupo. Si bien en las retrospectivas no había una persona que desempeñara ese rol, creo que todos los que participamos nos hicimos responsables de hacer cumplir sus funciones, como si ello fuera nuestro "acuerdo de trabajo" implícito.

El libro me parece de gran interés para aquellos que participan de retrospectiva, no solo para los que actúen de facilitadores. Creo que es útil para entender un poco mas acerca del concepto y de la filosofía detrás de la retrospectiva, y además acerca de la dinámica de la misma y de sus participantes y como cada uno, desde su lugar, puede aportar para darle a la retrospectiva la importancia que tiene.

Debates que enriquecen

noreply@blogger.com (Ricardo D. de Guzmán) — Mon, 23 Aug 2010 17:34:00 +0000

En marzo de este año junto con la gente de Kinética Solutions organizamos en el Club del Golf un evento para compartir experiencias con algunos de nuestros clientes y colegas.

Bajo el nombre WebCrucijadas 2010 y en medio de un “opíparo” desayuno mantuvimos un debate abierto y enriquecedor, tomando como eje principal el análisis de factores que afectan a la toma de decisiones en la implementación de proyectos Web.

Para ello se presentaron 2 casos ejemplo:

Desarrollos convencionales (custom) vs. Integración sobre plataformas existentes

En este primer ejemplo, se comparó el desarrollo convencional de aplicaciones web (soluciones custom, de punta a punta) con el uso de plataformas existentes.

Para eso, Adrián Eidelman de Kinética Solutions mostró su experiencia en la implementación de una solución web montada sobre Community Server, resaltando pros y contras de su utilización.

El modelo WebForms vs. el modelo MVC ASPNET

En el segundo ejemplo, se comparó el modelo clásico de desarrollo de aplicaciones ASPNET (WebForms, WebControls, etc.) con su “challenger” más reciente, el modelo MVC para aplicaciones Web.

Aquí Ricardo D. de Guzmán y Benjamín Eidelman, integrantes de Tercer Planeta destacaron las características conceptuales de cada uno de los dos modelos.

¿Qué nos llevo a hacerlo?

La idea principal del evento fue exponer y escuchar experiencias debatiendo sobre un tema frecuente para quienes nos dedicamos al desarrollo de software, como es el de tomar decisiones sobre este tipo de tecnologías al momento de encarar un proyecto nuevo.

Además buscamos agasajar a clientes y pares, con quienes llevamos recorridos varios años de trabajo conjunto, pero esta vez en un entorno distendido y lejos de las negociaciones propias de un proyecto en particular.

¿Qué nos dejo?

Nos beneficiamos con el aporte de todos los participantes aprovechando los diferentes puntos de vista que ofrecieron desde la diversidad de sus perfiles.

Como experiencia nos pareció muy enriquecedora y recomendable, esperamos poder organizar otra pronto.

Herramientas para trabajo distribuido

noreply@blogger.com (Matías Timossi) — Wed, 18 Aug 2010 14:34:00 +0000

En el artículo sobre trabajo distribuido comentamos que estamos aplicando ésta forma de trabajo desde el 2009. Por supuesto al principio la implementación supuso varios desafíos, entre los cuales estaban sostener una comunicación fluida en el equipo, mantener el código actualizado y además llevar a cabo las prácticas ágiles a las cuales estamos acostumbrados.
¿Cuáles serían las herramientas que nos facilitarían esta tarea? A continuación hago una breve reseña de las aplicaciones que utilizamos y cómo nos ayudaron:

Team Foundation Server

Es una herramienta de control de código que no presenta inconvenientes a la hora de trabajar tanto en la red local como desde una conexión de Internet.

También cuenta con un modo de trabajo offline que funciona muy bien si por una de esas casualidades nos quedamos sin conexión.

Team Foundation Server

Live Mesh

Es un sistema de sincronización de datos que nos permite mantener compartidos y actualizados los cambios que vamos realizando en archivos y carpetas de uso conjunto.

Principalmente nos ayudó a mantener actualizada nuestras bases de datos ya que cada uno poseía una copia local (solo de las que necesitaba) y era indispensable algún medio que nos permitiera aplicar los cambios realizados por otros miembros del equipo.

El procedimiento que seguimos fue el siguiente: Cuando realizábamos alguna modificación creábamos un script de actualización. Estos scripts se iban colocando numerados en una carpeta compartida de cada proyecto, donde además teníamos un documento con un registro de las actualizaciones que había corrido cada uno. Luego, para saber si necesitábamos actualizar la BD, sencillamente entrábamos a esta carpeta y verificábamos hasta que script habíamos corrido y de haber nuevos scripts a continuación de éste, ejecutábamos los que nos faltaban.

Pronto va a ser reemplazado por la nueva versión de Windows Live Sync.

Live Mesh

Scrumy

Esta aplicación web hace las veces de Task Board permitiéndonos realizar el seguimiento de nuestro sprint virtualmente. Realmente es muy fácil de usar y posee una versión gratuita con las funcionalidades necesarias. La única desventaja es que no podemos agregar La columna del medio.

Pizarra Virtual:

Scrumy

Google Docs:

La posibilidad de que varias personas puedan editar un documento al mismo tiempo convierte a esta aplicación en una excelente herramienta para trabajo distribuido.

En nuestro caso, nos sirvió muchísimo a la hora de hacer las retrospectivas de cada proyecto. Para hacerlo utilizábamos una planilla en la cual podíamos escribir todos, y que además tenía unas columnas adicionales para realizar la votación.

Retrospectiva en Docs:

Google Docs

Skype:

Si bien no hace falta ninguna presentación, debo decir que esta aplicación se ha vuelto fundamental en nuestras vidas a la hora de comunicarnos mediante voz, mensajería instantánea y video. Resulta de gran utilidad por ejemplo a la hora de realizar la reunión diaria.

Skype

Yuuguu:

Esta herramienta nos permite compartir escritorio con varias personas al mismo tiempo, e inclusive ceder el control de Mouse y teclado. Como punto interesante quiero añadir que la persona que se conecta a nuestra computadora puede hacerlo desde cualquier navegador sin instalar la aplicación.

Yuuguu

Seguramente habrá muchas más herramientas que se puedan explorar (sobre todo las que no son específicas para desarrollar) y que no conocemos. Lo importante es que cada equipo incorpore aquellas con las que se sienta más cómodo en cada caso. Para esto resulta muy valioso el conocer experiencias de otros en el tema. Cualquier intercambio en este sentido es siempre muy bienvenido !!

Etiquetas de Technorati: Herramientas para trabajo distribuido,trabajo distribuido,trabajo remoto,teletrabajo,compartir carpetas

Trabajo distribuido

noreply@blogger.com (Matías Timossi) — Tue, 10 Aug 2010 12:33:00 +0000

Durante el mes de Julio del año pasado tuvimos la oportunidad de empezar a experimentar con esta modalidad de trabajo. Si bien la idea rondaba desde hacía tiempo por nuestras cabezas, todavía no habíamos tenido motivos suficientes como para tomar el riesgo de enfrentarnos a este terreno desconocido.

Lo que verdaderamente nos dio el impulso final fue el brote de Gripe A que por ese entonces estaba en su punto más alto. Siendo que varios de nosotros (entre los cuales me incluyo) pertenecíamos al grupo de riesgo, surgía la necesidad de desarrollar medidas preventivas. Entonces, con el objetivo de abogar por nuestra salud, y de paso aprovechar la oportunidad para probar que tal nos iba trabajando de forma remota , tomamos la decisión de replegarnos todos con nuestros equipos hacia nuestros respectivos hogares. Sólo una persona quedó en la oficina haciendo un poco de auxiliar en caso de que surgiera cualquier necesidad.

Mi experiencia

Debo decir que al principio me costó algo la adaptación, sin embargo a los pocos días ya me sentía como “en casa”. Realmente la tecnología con la que contamos hoy en día nos otorga una gran flexibilidad a la hora de trabajar.

Enfocándonos en la calidad de vida, quiero decir que el hecho de evitar las complejidades que se nos presentan camino a la oficina (como el tráfico) es una experiencia más que grata. Esto sin mencionar el tiempo y dinero que nos ahorramos.

Durante todo el mes trabajando en mí en casa sufrí algunos desperfectos técnicos. Afortunadamente como contamos con un buen servicio técnico los pudimos solucionar rápidamente, por lo tanto les recomiendo tener este tipo de seguridad a su disposición.

Los Resultados

Luego de un mes trabajando fuera de la oficina hicimos una evaluación de cómo nos había ido. Los resultados en general fueron bastante positivos:

Pudimos mantener sincronizados código y bases de datos sin demasiado esfuerzo.
Comprobamos nuestra flexibilidad para trabajar en equipo .
Se notó una gran autonomía para administrar los tiempos individuales con responsabilidad.
Logramos sostener la productividad.
Ahorramos tiempo y dinero en viajes.

En cuanto a lo negativo, creo que una de las cosas más importantes a destacar es la pérdida de la comunicación cara a cara.

Pienso que uno de los ingredientes principales que nos permitió obtener buenos

resultados donde otros fallan, es que hace tiempo que venimos trabajando juntos.

El hecho de que nos conozcamos y que estemos acostumbrados al trabajo en equipo hace que tengamos un lenguaje común. Es mucho más fácil lograr la resolución de un problema cuando las partes involucradas hablan el mismo idioma.

Trabajo Distribuido Hoy

Ahora bien, si esta experiencia nos dio tan buenos resultados cabe preguntarse ¿Por qué no adoptar esta modalidad de trabajo siempre y trabajar todos desde nuestros hogares?

En una empresa como la nuestra, donde mantener el espíritu de equipo y la identidad son valores muy importantes, esto sería difícil. Sin embargo, vimos que podíamos aprovechar esta metodología para los casos en los que nos es más útil y necesario.

Por ejemplo, uno de nuestros compañeros dentro de unos días va a ser padre, y más alla del tiempo contemplado para ello, va a trabajar durante unas semanas desde su casa ya que creemos que es importante que este cerca de su familia. Lo mismo se da para otros casos personales donde un día a la semana o cada 2 ó 3 semanas alguno de nosotros hace trabajo remoto.

Mirando al futuro

Evidentemente esta modalidad está totalmente instalada entre quienes nos dedicamos al software, modificando la calidad de vida de quienes la practican. Me parece importante señalar que para aprovechar los beneficios de la misma y lograr que este cambio sea positivo, no debemos olvidar lo valioso de poder salir de nuestras computadoras y ensayar distintas soluciones entre varios frente una pizarra, experimentar las virtudes de programar de a dos (de la forma” tradicional”) o simplemente compartir una charla extra laboral mientras nos tomamos una taza de café.

Model View ViewModel

noreply@blogger.com (Benjamin Eidelman) — Mon, 26 Jul 2010 15:36:00 +0000

En un mail reciente de MSDN apareció un artículo que toca un tema de diseño interesante.
Y es el patrón Model-ViewModel-Model, en el artículo se hace referencia a su implementación en WPF/Silverlight, sin embargo es un tema con el que seguramente muchos se topen al incursionar en Asp.Net Mvc, y en realidad es imposible de esquivar en cualquier implementación de MVC, ya sea en Asp.Net, WinForms, Ruby o Haskell.

ViewModels

Cuando trabajamos con un modelo MVC, especialmente si elegimos algún mecanismo de DataBinding entre M y V (y en un sentido amplio de la palabra consideremos los templates (como las vistas de Asp.Net Mvc) como un caso particular de DataBinding), resulta inmediato que cualquier aplicación que escape de lo elemental necesita algun tipo de transformación entre un Modelo y su Vista, ahi es donde llegan al rescate los ViewModels.

Para hacerlo menos abstracto, pongamos un ejemplo, imaginemos que nuestros amigos de Facebook® quieren construir la pagina de perfil de un usuario:

Perfil de Usuario

supongamos también que utilizan MVC y construyen su "Model" de la siguiente forma:

Nota: el modelo real de Facebook® podría ser más complejo

La duda es como obtener los datos resaltados en amarillo en la captura de ejemplo

Antigüedad del mensaje de estado ("lunes pasado").
Ubicación ("Villa Devoto" en lugar de el GUID correspondiente)
Amigos en común (con el usuario logueado actualmente)

Para esto podemos "envolver" estas entidades del modelo con otras más emparentadas a la vista que queremos construir:

Estas clases extienden a las anteriores con campos calculados, listas filtradas, consolidaciones, u otro tipo de transformaciones sobre el modelo original.
Para ilustrar ésta sería una versión (muy naive) de la nueva propiedad "CommonFriends" en UserVM:

public IList<UserVM> CommonFriends        {            get            {                return this.Friends                    .Where(f => f.Friends                      .Any(ff => ff.UserID == User.CurrentUserID))                    .ToList();            }        }

Si usted ya estuvo agregando este tipo de campos calculados y transformaciones, y se sentía culpable por haber violado la prístina pureza de su modelo MVC

siéntase liberado de la culpa!, esto ya tiene nombre y se llama ViewModel!

Separación Model-ViewModel-Model

Por supuesto en esto podemos imaginar un gradiente de creciente complejidad:

Propiedades agregadas directamente a las entidades de nuestro modelo
Algunas clases nuevas y propiedades agregadas a entidades que descienden de las de nuestro modelo
Una capa de ViewModels que se interpone y separa completamente View de Model.

Volviendo un poco al principio, el artículo de MSDN trata sobre la última opción, implementada como assemblies separados para View, Model y ViewModel, en el que no existen referencias entre View y Model.

Véase este gráfico explicativo que tomé prestado de un artículo que resume muy bien el tema

Rápidamente puede verse el problema burocrático en que nos pone este enfoque, ya que implica tener para casi todas las clases del modelo, una equivalente en ViewModel, con wrappers para todas las propiedades visibles. Imagínense la flagrante violación al principio DRY que supone crear páginas y páginas de código como este:

public string Fullname        {            get            {                return InnerEntity.Fullname;            }            set            {                InnerEntity.Fullname = value;            }        }

Tiene que haber algo mejor!

Dynamic Proxies

Como dice la máxima "El mejor código es aquel que no se escribe", y el artículo al que hice referencia propone generar estos ViewModels como proxies dinámicos, implementar esos "gets" y "sets" automáticamente con el nuevo tipo dynamic en .Net 4.0, un poco de Reflection y unos atributos muy elegantes para declarar dependencias entre propiedades (ej: Edad <-depende de-> FechaDeNacimiento).

Existen también librerías muy famosas para la creación de proxies dinámicos (que funcionan con .Net 2.0), como por ejemplo las que son usadas en NHibernate (para crear proxies que soporten lazy loading):

que hacen fácil agregarle a estos proxies interceptores en getters y setters (u otros métodos) que implementen notificación de cambios, logging, autorización y otras cosas por el estilo.

Y finalmente...KISS! es importante recordar que puede resultar más que suficiente con mantener las clases en el modelo accesibles a las vistas, y las clases "ViewModel" mezcladas con el "Model", o separadas simplemente por namespace.

Sitecore, otra opción que ofrecer

noreply@blogger.com (Ricardo D. de Guzmán) — Wed, 07 Jul 2010 18:03:00 +0000

Algunas semanas atrás, uno de nuestros clientes más importantes, nos invitó a participar junto con otros proveedores de un curso intensivo de una semana sobre Sitecore.
Sitecore es un CMS que proporciona software de gestión de contenidos web y portales a organizaciones que requieran funciones empresariales, integración y escalabilidad a la hora de administrar sitios web.

Sitecore fue desarrollado en Dinamarca, y tiene su mayor mercado actualmente en Estados Unidos y Europa. Nuestro cliente vio interesante, la posibilidad de que sus proveedores de mayor confianza, se puedan instruir en esta herramienta para que en el futuro los acompañen en la integración de Sitecore con otras aplicaciones, puedan agregar nuevas funcionalidades o colaboren en la implementación de la herramienta.

Como en Tercer Planeta estamos acostumbrados a realizar nuestros propios desarrollos, la primera reacción a la invitación fue “y no sé, ¿te parece que tengamos que aprender Sitecore?”, pero rápidamente comprendimos que la mejor respuesta a esa pregunta con un , “claro que sí”, y hoy en día vemos los beneficios de haber participado en ese encuentro.

Más allá que nuestro fuerte esté en los desarrollos a medida, siempre es enriquecedor poder conocer cómo otros pueden encarar una determinada solución. En este caso puntual, Sitecore nos pareció un producto muy completo, que tiene cubiertas muchísimas funcionalidades, muchas de las cuales todavía no pudimos explorar, pero en las que sí pudimos indagar descubrimos que están resueltas de manera muy diferente al enfoque que le hubiéramos dado nosotros, simplemente porque fue pensado por otras personas, en otro contexto, con otra experiencia y otras costumbres.

Con lo cual la posibilidad de poder salir, tomar distancia de nuestros tareas diarias, y ver cómo piensan otros, nos resultó más que interesante.

El curso fue dictado por Craig Nelson, un instructor técnico especializado en Sitecore, que viajo especialmente desde Estados Unidos. Cada día estaba orientado a diferentes perfiles (Usuarios Finales, Diseñadores, Desarrolladores, etc.), constaba de partes teóricas y prácticas, las cuales resolvíamos en grupos, esta interacción con otros colegas fue también una experiencia que valió la pena.

Este curso nos sirvió para conocer una nueva herramienta, y fundamentalmente para ver otra forma de hacer las cosas, e independientemente del uso que la vayamos a dar en el futuro, hoy en día, sentimos que tenemos una posibilidad más, otra opción que ofrecer, o tener en cuenta, y eso creo que es lo más importante, para nosotros y para nuestros clientes.

Cómo entendemos el crecimiento

noreply@blogger.com (Andrea Morales) — Mon, 05 Jul 2010 18:00:00 +0000

Cuando en diciembre del 2009 nos reunimos con Jose a definir los objetivos del 2010 decidimos que teníamos que poner el foco en madurar.

Pero, qué significaba en ese momento “madurar” para nosotros ? Para el tamaño de organización que tenemos y por los lineamientos que seguimos, lo que buscábamos era lograr un crecimiento de la empresa pero no medido en este caso en cantidad de integrantes o en monto de facturación, sino en base al crecimiento profesional y desarrollo personal de todos los integrantes del equipo de Tercer Planeta.

Help, I need somebody!

Para quienes no somos especialistas en coaching y tenemos un perfil más técnico, el objetivo se presentaba como un gran desafío y sabíamos también que nos embarcábamos en un trabajo de largo plazo que implicaba grandes cambios individuales y en el grupo.

Estaba claro que para poder llevar a cabo esta tarea necesitábamos contactar a especialistas en el tema y fue así que acudimos a Pablo Fondevila y su empresa “Nuevas Miradas en Organizaciones”, quien junto con Carola Herrscher y Marisa Bergés se dedican al Coaching Ontológico . Con ellos empezamos a transitar este camino desde hace 6 meses.

Algunos caminos a seguir

Uno de los aspectos que comenzamos a abordar es tratar de lograr una convergencia entre la vida personal y la laboral ¿cómo pensar que con la cantidad de horas que compartimos en la oficina ambos entornos marchan cada uno por un “carril exclusivo” sin tocarse en ningún momento?
Es lógico entender que estas dos “vidas” se cruzan en varios puntos pero no nos resultaba tan lógico hacer visible y poner un esfuerzo claro y público en juntarlas y complementarlas.

Y para qué querríamos hacer esto? Una de las respuestas que encontramos a esta pregunta es que creemos que la realización de las personas debe ser algo integral, el desarrollo personal y profesional implica poder mostrar los logros, tomar nuevos compromisos, cerrar etapas, explorar nuevos caminos, descubrir y explotar nuestras habilidades.

Por otro lado, aceptar la influencia que las emociones tienen en nuestras vidas es fundamental para entender algunos comportamientos: por ejemplo, aclarar que estamos viviendo un momento difícil o que tenemos algo importante que resolver puede evitarnos conflictos de comunicación si encontramos un ámbito donde nos sintamos cómodos para declararlo y los demás entiendan el por qué de ciertas actitudes.

Entender cuán valioso es el esfuerzo de alguien por terminar una carrera o por emprender nuevos retos, por ejemplo, nos anima a fomentar ese tipo de logros, que sin duda, redundarán en valor para los objetivos de la empresa.

Cómo hacer entonces para acercar estos dos mundos y lograr que se retroalimenten ? O que el trabajo sea un medio más a través del cual alcanzar objetivos personales ?
Cómo hacer que la "vida de la oficina" no genere trabas en la vida privada ? O que la vida privada (logros, alegrías, tristezas) puedan ser, de alguna manera, compartidos, apoyados y comprendidos por la empresa?

Estas fueron algunas de las dudas que empezaron a surgir. Dudas que, gracias a las herramientas que nos van dando quienes nos acompañan (talleres, entrevistas individuales periódicas, consejos para la organización de eventos internos y externos, etc.), empezaron a disiparse.

Puede asombrarnos pensar que con pequeños cambios o con la creación de ámbitos de discusión de cosas simples y concretas, es absolutamente posible y realizable encarar el tema.

De la misma manera las charlas individuales para desarrollo personal nos están abriendo los ojos a nuevas posibilidades de solución de conflictos, de aprovechamiento de las capacidades de cada uno, de alineamiento con los objetivos y visión de la empresa, de comunicación, de roles, etc.

Esfuerzo vs. Beneficios

Según mi opinión, el mayor desafío en este emprendimiento está en saber incorporar y mantener estos valores. Lo cual implica un trabajo de replanteo individual, de delegación de tareas, de acompañamiento, de promoción de la creatividad, de generación de espacios de intercambio, entre otras cosas.

Creo que el entender que estos procesos implican pensar a largo plazo, esfuerzo y modificaciones en la mentalidad, en las costumbres, en las estructuras y en la mirada con que enfocamos las cosas, es una de las principales claves para obtener buenos resultados.

Ahora, sin dejar de lado un enfoque más “empresario”, qué beneficios veo en estos cambios en relación con la organización y la productividad ?

• Mayor compromiso de todos
• Mayor motivación
• Mejoramiento del ambiente laboral
• Mayor confianza entre los miembros del equipo
• Mejoras en la comunicación
• Hacer que los objetivos y la visión de la empresa sean sostenibles en el tiempo

Me animo a decir también que todo este “movimiento” trasciende los límites de la empresa y repercute en la relación con nuestros clientes, quienes, en definitiva, se benefician con los resultados que un equipo de trabajo motivado y “en sintonía” es capaz de producir.

Vale la pena?

Considero que para empresas como la nuestra, donde el capital humano es considerado uno de los puntos más importantes, la inversión en este tipo de emprendimientos está más que justificada y muestra sus frutos en muchas áreas.

Finalmente, creo que para “poner a rodar la maquinaria” en todo esto, el principal motor es ver y reconocer la importancia que tienen estas cuestiones en nuestra vida cotidiana, cualquiera sea el carril por el que marche.

¡Qué comience la sesión!

noreply@blogger.com (Nora Martinez) — Tue, 29 Jun 2010 19:33:00 +0000

Resulta común que durante el almuerzo o en esos 5' que lleva batir el café o preparar el mate surjan temas o ideas interesantes que son para "discutir entre todos", o al menos entre muchos; y, por lo general, se hace difícil buscar y encontrar el tiempo necesario para hacerlo, por lo que esas ideas quedan sin transmitir ni impulsar.
Esto nos sucedió a nosotros, hemos de reconocerlo. Pero encontramos la solución y, como era lógico, la misma surgió en esos momentos de "recreo laboral".
La propuesta fue tener reuniones cortas para charlar y debatir acerca de diferentes temas. Así surgió nuestro "Cabildo Abierto", pensado como un espacio en el que se pudieran plantear problemas o inquietudes, discutir soluciones, propuestas o acciones a tomar y llegar a alguna conclusión con una solución rápidamente aplicable.

El nombre elegido no fue al azar, ya que combina el nombre de la Avenida en la cual está nuestra oficina con el llamado a debate mediante la participación activa y sin límites de cualquier integrante de Tercer Planeta (3P) que quiera hacerlo.

¿En qué consiste?
El término Cabildo Abierto no es nuevo, surge en la época del Virreinato del Río de La Plata en la cual algunos pobladores se reunían para tratar diversos temas.

Nuestro Cabildo Abierto consiste en hacer sesiones para debatir temas propuestos por los integrantes de 3P. Cada uno, al tener un tema a tratar, anota un título representativo en una Wiki. Fue designada la figura de moderador quién es el encargado de seleccionar 2 o 3 temas propuestos para debatir en la siguiente sesión, estos temas pueden estar conectados o no; la particularidad de ellos es que el debate no debería llevar mas de 1 hora.

Una vez seleccionados los temas, se proponen días y horarios (es deseable mas de 2 opciones para elegir) y cada interesado en participar se anota según su conveniencia. Aquel día-horario que tenga mas participantes será el día elegido para sesionar. Es fundamental que aquella persona que propuso el tema asista a la sesión ya que es la encargada de presentar el tema, impulsar el debate y anotar las conclusiones.

Al comenzar la sesión, se expone cada tema, se lo discute y, al dar cierre al debate, se anotan las conclusiones propuestas en la Wiki. En caso de requerir un seguimiento, la persona que propuso el tema tendrá la responsabilidad de hacerlo.

Anotando temas
Los temas a proponer pueden ser muy variados, ellos surgen de la motivación personal de mejorar algo que vemos y sentimos puede ser mejorado o revisado. Por supuesto dado que cada persona tiene al respecto una visión distinta, un enfoque distinto, esto es lo que enriquecerá la gama de tipos de temas propuestos.

Se pueden proponer temas que traten asuntos relacionados con la metodología de trabajo o con cuestiones técnicas del desarrollo. También pueden sumarse aquellas cuestiones que tienen que ver con la convivencia o el espacio físico en el que nos encontramos. En definitiva, vale anotar cualquier tema que cada uno quiera tratar en una sesión de Cabildo Abierto.

Nosotros, en particular, hemos presentado diversos temas. Algunos de ellos fueron:

Cómo manejamos el Collate en SQLServer?
Timeboxing (como afecta la calidad, como tenerlo en cuenta en la planificación, como prever y manejar imprevistos, etc)
Equipar lo necesario para poder hacer reuniones remotas
Cómo mejorar nuestra relación con el cliente?
Cambiar las cortinas

por citar algunos títulos.

Conclusiones
Es importante saber que existe un epacio en el que se puede proponer y accionar esas propuestas. El Cabildo Abierto intenta ser eso precisamente: un espacio en el cual se planteen y canalicen las inquietudes de todos y se busquen las respuestas y soluciones en forma conjunta.

HTML5, un paso más cerca

noreply@blogger.com (Benjamin Eidelman) — Thu, 18 Mar 2010 16:16:00 +0000

Html5: Html para aplicaciones web

Desde hace mucho tiempo, oímos culpar de los problemas intrínsicos de las aplicaciones web, a la naturaleza “document-oriented” de la web. La web fue pensada originalmente como una red para compartir documentos “hipervinculados”, y no como plataforma de aplicaciones distribuídas. De hecho fue éste el argumento expuesto por Google en forma de historieta para lanzar Chrome.

Para subsanar esta brecha surgieron una gran variedad de tecnologías, como javascript, Java Applets, Ajax, Flash, y más recientemente Google Gears, Java FX y Silverlight con la intención de crear en los browsers lo que se conoce como Rich Clients, clientes que permitan una experiencia de usuario similar a la de una aplicación de escritorio, con todas la ventajas de la web.

Sin embargo en todo este tiempo, el “poder legislativo” de la web, la W3C, no se quedó de brazos cruzados, y como es de esperar, respondieron con un estándar, tomándose su tiempo. La respuesta de la W3C fue: HTML5

HTML5 traerá muchas novedades, pero lo importante, la idea que está detrás de la mayoría de ellas, es la creación de aplicaciones web “ricas” en nuestros browsers. Para muestra basta un botón:

Graficos vectoriales, animaciones y efectos visuales más avanzados
Almacenamiento local en el browser, no sólo como diccionarios, también en forma de bases de datos SQL, y otras facilidades para aplicaciones “offline/online”
WebWorkers, tareas asincrónicas, y un sistema de mensajería entre ellas.
Navegación Ajax
Streaming de audio y video
DOM Events, los elementos de un documento html, expondrán una serie eventos (ej: div.resize)
Drag & Drop
Tags semánticos asociados a aplicaciones como: <progress>, <meter>, <command>, <datalist>, <output>, y nuevos tipos de campos para formularios (<input>) como “datetime”, “range”, “search”, etc.
varios etc.

A esta altura, resulta evidente que tener soporte para todo esto, de forma nativa en HTML, se ve como una amenaza para todos los que proveen estos features actualmente mediante plugins, como Flash, Java FX, Silverlight y otros.

HTML5 todavía está en pañales, y se acerca lentamente, sin embargo la mayoría de los browsers ya soportan varios features de HTML5.

IE9, Podría Microsoft estar suicidando Silverlight?

Con la salida de IE8, Microsoft empezó a soportar algunos features de HTML5, sin embargo este era muy limitado, y con la ausencia del elemento <canvas> que permite la inclusión de gráficos vectoriales, se especuló sobre una estratégica defensa de Silverlight.

Sin embargo, con la llegada de IE9 están anunciando un soporte para HTML5 mucho más completo, tanto que publicaron una pagina para probar entre otras cosas el soporte HTML5 de IE9 (incluyendo animaciones y gráficos vectoriales con aceleración por hardware).

Y a esto se suma un nuevo engine Javascript, que pretende ponerse a tiro con el resto con benchmarkings prometedores. Esto me recuerda un comentario sobre el futuro de Javascript de Martín Salías.

Para los que trabajamos con .Net surgen ahora dudas existenciales sobre como afectará esto el futuro de Silverlight.

Sin duda la familiaridad del framework .Net, C#, y la integración con VisualStudio son la panacea para los desarrolladores que ya trabajamos con .Net, sin embargo, ¿Qué features realmente distintivos tendrá Silverlight para los usuarios?

Gráficos 3D, Out-of-browser y Smooth Streaming?

Quizás todavía sea solo futurología, pero la llegada de IE9 nos acerca bastante a la pregunta:

¿Cuál será el lugar que ocupará Silverlight (y otras RIU) con la llegada de HTML5?.

Profecía autocumplida: Google + Apple + Microsoft

Ya no hace falta decirlo, a esta altura, HTML5 será un caso evidente de profecía autocumplida, no sólo por tratarse de un estándar de la W3C, sino por contar con el apoyo de Google (además de incluir soporte en Chrome, decidió abandonar Google Gears, por considerarlo un subset de lo que HTML5 proveerá y creo una versión HTML5 de YouTube), Apple (soporte en Safari, que incluirá IPhones que actualmente no soportan Flash), y finalmente Microsoft con la llegada IE9.

Falta aún saber cuanto falta para que sea soportado completamente por los browsers más populares, y para que nuestras IDEs nos permitan aprovecharlo.

¿Y si jugamos a que hacemos software?

noreply@blogger.com (Benjamin Eidelman) — Mon, 30 Nov 2009 16:18:00 +0000

Desde hace un tiempo, estoy dando una mirada de vez en cuando a una revista online sobre metodologías ágiles en portugués. Visão Ágil, como tarea hogareña del curso portugués que estoy haciendo, y con la intención de leer un poco sobre este tema (como dice la poco ecológica metáfora: matar dos pájaros de un tiro).

La técnica del Tomate

En el blog de esta revista encontré recientemente un artículo sobre la “Técnica Pomodoro” de Manoel Pimentel. La Técnica Pomodoro se utiliza para la administración personal del tiempo, y está inspirada en ideas de las metodologías ágiles, como TimeBoxing y el uso de herramientas de “baja tecnología”, puntualmente: papel, lápiz y un timer de cocina.

Estos timers con forma de tomate (pomodoro en italiano) son los que dan nombre a la técnica

Si bien ese artículo tiene un mindmap que resume muy bien los puntos clave, lo que más destacaría es la simplicidad, el énfasis en mantener el foco, y la asignación rígida de tiempos (véase TimeBoxing) tanto a las tareas como a los intervalos de descanso entre éstas.

Con respecto a este último punto, el libro oficial que puede descargarse de http://www.pomodorotechnique.com destaca la importancia de estos intervalos para “asimilar lo aprendido y hacer algo bueno por tu salud”, como caminar, ejercicios de respiración o contar un chiste. Interrumpir este período de descanso con cualquier tarea que implique un esfuerzo mental, “bloqueara el constructivo proceso mental de integración necesario para estar alerta y listo para el proximo ciclo”. Una especie de build de integración que se ejecuta periódicamente en background en nuestro cerebro.

El último que se escondió arma el release!

Sin embargo lo que quería mencionar en este artículo (y por eso el título), es algo que me parece muy valioso y puede pasar desapercibido a primera vista. Es el espíritu lúdico que hay detrás de esta técnica (vi este punto escrito en el mindmap del artículo de Pimentel).

Una idea que tambien está implícita en varias técnicas utilizadas en metodologías ágiles.

Creo que en esta manera de encarar el trabajo (y cualquier otra cosa) hay mucho más jugo de lo que se cree habitualmente. Especialmente en ambientes que promueven la productividad y la creatividad.

No hay que confundirlo con una forma de hacer apología de la competencia (que casi nunca es sana), o de esquivar el bulto a las tareas tediosas. Se trata más bien de evitar que nuestro trabajo sea una letárgica marcha atrás de la recompensa monetaria de fin de mes (Dispositivo del burro y la zanahoria),

para empezar a disfrutar del día a día, transformándolo en un juego constructivo, hasta casi “sentir que no trabajamos”.

Sin duda el tema, da para mucho más que este artículo (y para autores más calificados!) pero la intención era traer a colación el tema, y tratar de poner en evidencia, o preguntar, ¿Cuántas cosas hacemos (o podemos hacer) en este sentido?

"La columna del medio"

noreply@blogger.com (Matías Timossi) — Fri, 13 Nov 2009 20:19:00 +0000

Aportando dinámica a la pizarra

En nuestro equipo de trabajo contamos con los ambientes de desarrollo (pruebas de unidad) y de QA (pruebas de integración).

Desde hace tiempo venimos aplicando prácticas de SCRUM. Con el uso de la pizarra notamos la necesidad de diferenciar las tareas cuyo desarrollo se encontraba en progreso de aquellas terminadas y a la espera de un pasaje al ambiente de QA.

Esto era debido a que cada vez que terminábamos una tarea la pasábamos a la columna de “Test”, ocasionando muchas veces confusiones ya que no teníamos manera de saber si las tareas que se encontraban en esta columna estaban contempladas dentro del último build.

Durante un tiempo intentamos hacer el pasaje de papelitos solamente cuando hacíamos el build al ambiente QA, pero para eso contábamos con nuestra memoria para saber que tareas estaban completas, lo que no siempre resultaba con éxito por que… seamos sinceros… esta no siempre nos era fiel =)

Entonces un día, durante la retrospectiva de uno de nuestros proyectos tuvimos la siguiente maravillosa idea para arribar a una solución:

Agregar una columna intermedia entre DESA (In progress) y QA (Test) que nos permitiera saber, de forma inmediata, cuáles eran las tareas que estaban listas pero que todavía no estaban disponibles para ser probadas en QA…

¿Como funciona?

Cada vez que el desarrollador termina alguna tarea, mueve el papelito correspondiente de “In Progress” a la columna “DESA/TEST”(la columna del medio) indicando de esta manera que el desarrollo ha finalizado y estará disponible en el próximo build para su prueba.

Si bien debo reconocer que en un principio tuve mis dudas acerca de si la nueva columna iba a servir de algo, el uso de la misma nos demostró gran efectividad.

Su implementación acarreó las siguientes mejoras:

Nos permitió tener una noción más precisa del avance del sprint, rompiendo con la sensación de un “avance estático” generado por la acumulación de tareas en la columna de desarrollo.
Da una idea más clara al desarrollador de qué tareas le falta completar y cuáles completó.
Brinda al tester la certeza de saber qué estará para probar.
Es mucho más fácil decidir en qué momento hacer un pasaje de ambiente.

Resultado final

Conclusiones

Por nuestra experiencia, la incorporación de esta nueva columna trae grandes beneficios a la dinámica del equipo, agilizando la comunicación. Los invitamos a probar esta alternativa y que compartan con nosotros sus experiencias.

Sobre Ratas, Elefantes y TimeBoxing

noreply@blogger.com (Benjamin Eidelman) — Wed, 08 Jul 2009 11:54:00 +0000

La semana pasada nos dispusimos a realizar un cronograma de entregas para las próximas semanas de uno de nuestros proyectos, así que me reuní con el resto del grupo involucrado, y empezamos una planificación, haciendo una revisión rápida de las historias de usuario prioritarias en nuestro backlog.

Acto seguido, ubicaríamos estas historias de usuario según sus “tamaños” , prioridades y dependencias, en hipotéticos sprints, manteniendo presente el concepto de TimeBoxing.

La bolsa de Gatos

La lista resultó ser bastante extensa, y estimar el esfuerzo requerido por cada ítem, se volvía un poco confuso. Eran demasiado heterogéneas (lo que comúnmente llamamos bolsa de gatos).

Era necesario dividir un poco las aguas y separar cosas como “cambiar el color de fondo del campo X” de “diseñar un generador de fusión en frío”.

Creo que lo más peligroso de esto es que camufladas en medio de la estampida de historias de usuario más pequeñas, podían pasar desapercibidas las más pesadas o de más difícil estimación.

Una metodología de planificación para toda la familia

Normalmente utilizamos para estimar el esfuerzo requerido de cada historia de usuario, cartas de Planning Poker (gracias a Mountain Goat) al comienzo de cada sprint, sin embargo esta planificación prolongada requería de una primera clasificación grosera.

Fue así que con el ánimo de innovar un poco y de hacer la reunión un poco más divertida inventamos (y ofrecemos sin patente alguna) un método de planificación que podría llamarse “El Arca de Noé”.

Es importante que participen todos los miembros del equipo (funcionales, desarrolladores, líder de proyecto, etc. con sus diferentes visiones) y consiste básicamente en 2 etapas:

1. Clasificación

En esta etapa se toma cada una de las historias de usuario, y luego de una breve descripción, y discusión sobre sus implicancias (aquí típicamente es el momento de que un desarrollador advierta sobre dificultades posibles, o calle para siempre :)). se procede a su clasificación.

Las tareas se ubicarán en 3 grandes categorías de acuerdo al esfuerzo que representa la tarea, para hacerlo más entretenido decidimos identificar estas categorías con especies animales:

Rata: Con este nombre identificamos historias de usuario más rápidas de resolver y que no requieren casi ningún análisis sobre la forma de implementarlas. Típicamente cambios estéticos, cambios de configuración, pseudo-duplicar un componente ya existente, etc.
Perro: En esta categoría van tareas que implican un cierto análisis y/o un trabajo más cuidadoso o extenso que las anteriores.
Elefante: Finalmente elefantes son las historias de usuario más pesadas, generalmente requieren un esfuerzo de diseño, o hay muchas dudas sobre la forma implementarlo, o implica un riesgo díficil de estimar.

Finalmente es importante entender que tanto el número de categorías (3), como los criterios para ubicar un historia de usuario en cada categoría, son parámetros que deben ajustarse con el tiempo a las particularidades de cada equipo.

2. Planificación

En esta etapa al igual que Noé con su Arca, es dónde tenemos que acomodar estos animales (o historias de usuario) en compartimientos finitos (o sprints).

Advertencia: Si la cantidad de sprints es limitada, es posible que algunas historias de usuario se pierdan en el diluvio universal.

Para esto tenemos que sopesar diferentes criterios:

Historias prioritarias para el cliente
Dependencias entre éstas
Recursos disponibles
Imprevisibilidad o riesgo de una tarea (generalmente es preferible comenzar estas tareas lo antes posible para en caso de necesidad ajustar el rumbo a tiempo)

y otros que puedan ser particulares del proyecto.

Aquí es dónde se aplican todas las metodologías de planificación que normalmente utilizamos.

Por supuesto que la medida de cuántos “elefantes” entran en cada sprint, además de depender de los recursos disponibles en ese sprint, es algo que los miembros del equipo irán refinando con el paso del tiempo.

El Resultado:

Conclusiones

Antes de empezar a dibujar Gantts, Cronogramas o un Análisis de Riesgo, se hace necesario hacer una primera pasada que identifique las historias de usuario clave. Esta variante simple resulta bastante divertida, lo cual en una larga planificación nunca está demás.

Eso sí, una consecuencia inmediata y un poco vergonzosa, son expresiones del tipo; “Yo 2 elefantes en esta semana no me puedo comer, mejor empiezo agarro un elefante y voy intercalando con algunas ratitas” o “Me parece que nos estás vendiendo perro por rata”

Quién se anima a compartir otras variantes de este tipo?

Como excluir archivos de configuración de Source Control

noreply@blogger.com (Ricardo D. de Guzmán) — Mon, 16 Feb 2009 12:36:00 +0000

Una pregunta que alguien se podría hacer al leer este artículo, es ¿porque voy a querer quitar los archivos de configuración del repositorio de código fuente?

El objetivo de los Repositorios de Código es justamente ese, resguardar el código, los archivos de configuración son necesarios al ejecutar la aplicación, y muchas veces al compilarla, tal es el caso del web.config, por este motivo necesitamos que sean parte del proyecto, pero tenerlos en el repositorio de código fuente nos puede traer algunos problemas.

Uno de los inconvenientes ocurre en los procesos de Deployment, ya que los archivos de configuración, ente otras cosas, almacenan información referida al ambiente donde corre la aplicación:

Desarrollo
Qa
Producción
etc

y el repositorio almacena versiones del código, independientemente de los ambientes en donde se instale.

En este sentido excluirlos, nos obliga a hacer un manejo especial con ellos en los diferentes pasajes de ambiente, que nos puede evitar errores. Por otro lado mientras estamos desarrollando, es bastante común hacer pruebas modificando los archivos de configuración, pruebas que nunca vamos a querer subir al repositorio de código (Ej.: apuntar la configuración a una Base de Datos local), si tenemos los archivos en el repositorio, es necesario hacer CECK OUT, para luego hacer UNDO PENDING CHANGES al finalizar la prueba. Esto, mas allá de ser una tarea tediosa para el desarrollador, es problemática si son muchos los que están trabajando al mismo tiempo.

Veamos cómo hacerlo

En este caso vamos a hacer un ejemplo utilizando como Repositorio de Código Fuente a Team Fundation Server.

En este ejemplo, voy a abrir la solución correspondiente al Sitio corporativo de Tercer Planeta http://www.tercerplaneta.com/, para excluir al web.config, cabe aclarar que esto se puede aplicar también, en una aplicación WinForms, excluyendo el app.config.

Al abrir la solución vemos la siguiente estructura de carpetas y archivos desde Solution Explorer de Visual Studio 2008.

El primer paso consta de hacer una copia del web.config, para luego renombrarlo como web.config.template. Este témplate nos sirve para almacenar la configuración que requiere la aplicación, en el también podríamos identificar de alguna manera, que cosas vamos a tener que modificar, cada vez que la aplicación se encuentre en un ambiente diferente.

Para esto nos paramos sobre el archivo web.config en el Solution Explorer, hacemos una copia del mismo y lo renombramos como lo dijimos anteriormente.

Luego de subir los cambios, pasamos a excluir el web.config de Source Control.

Para ello, seleccionando el web.config desde el Solution Explorer, debemos ir al punto de menú File / Source Control /Exclude web.config from Source Control como se ve a continuación.

Este último paso hace CHECK OUT del proyecto para marcar al web.config como archivo excluido.

Luego de guardar los cambios debemos eliminar definitivamente al web.config de Source Control, para esto en la solapa Source Control Explorer de Visual Studio 2008, debemos pararnos sobre el archivo web.config y hacer Click Derecho / Delete.

Si en este punto miramos la columna Pending Change, de la solapa Source Control Explorer vamos a ver que marca el archivo web.config como Delete y además hace cambios sobre los archivos del proyecto.

Como solo queremos quitarlo de Source Control y no del proyecto, lo que tenemos que hacer es desde el Source Control Explorer, deshacer los cambios sobre los archivos del proyecto.

Para eso los seleccionamos y hacemos UNDO PENDING CHANGES como se muestra a continuación.

Luego hacemos CHECK IN sobre el web.config , para podes borrarlo definitivamente.

Estos últimos dos pasos, hacen que el web.config desaparezca del árbol de Source Control, pero no lo excluye del proyecto web.

Si ahora observamos nuevamente el Solution Explorer vamos a ver que el web.config sigue apareciendo en la lista de archivos, pero ahora con dos iconos.

El icono rojo indica que el archivo está excluido de Source Control, mientras que el icono amarillo nos dice que no lo tenemos actualmente en el disco local.

El último paso consta de ir a nuestro disco local, hacer una copia del témplate que generamos en los pasos anteriores, y renombrarla como web.config, de esta manera en el Solution Explorer solo veríamos el icono rojo.

A partir de este momento el web.config, está localmente y nunca se va a pisar cuando hagamos Get Latest Version. Es importante aplicar los cambios al Témplate cuando se necesite hacer un cambio en el web.config, y avisar de esto al resto del equipo, para que lo actualice localmente.

De esta manera, cada puesto de trabajo pasa a tener su copia del web.config, que el desarrollador puede modificar cuando quiera, evitando hacer CHECK-OUT cada vez. Por otro lado, cada ambiente donde se instale la aplicación va a tener que tener su propio web.config, la forma de obtenerlo en este caso dependerá del mecanismo que utilicemos como publicación.