miércoles, 2 de abril de 2014

PSP en tres minutos


Se encuentra con un cliente, es la tercera reunión, y éste pregunta: ¿Y qué es PSP?

Hace una pausa y medita para luego concluir que el plan de la reunión es defectuoso y que estrategia de comunicación hasta el momento ha fallado.

Toma nota mental y continúa la junta.

Una vez aclarada la duda del interlocutor, toma nota mental del tiempo transcurrido empleado en solucionarla.

Con estos datos se pueden modificar los planes y diseñar estrategias más efectivas de comunicación con los clientes.

Pero...
La memoria es selectiva. Muchas de esas notas se olvidan o cambian de prioridad según el contexto o el tiempo transcurrido.


La propuesta de PSP radica en emplear métodos formales para registrar esos datos, compararlos y luego tomar decisiones.

Para ello, al detectar el fallo:

Registra el evento de acuerdo a una clasificación estándar, incluye una pequeña descripción, inicia un cronómetro e inicia la reparación.

Una vez aclarado el problema, registra el tiempo efectivo empleado en la solución.

Un análisis estadístico de frecuencias determinará los problemas más comunes y el tiempo promedio que toma arreglarlos. Esto permitirá priorizar el esfuerzo en corregir los errores más costosos; los que en conjunto quitan más tiempo.

Pero...
Al modificar el proceso ¿Cómo determinar el efecto de las mejoras?


Además de estandarizar el registro de fallos, el proceso también debe ser monitoreado. Para ello, PSP divide el proceso de desarrollo de software en etapas, cada una de las cuales tiene sus propios indicadores de calidad.

Así, al hacer un ajuste y luego recopilar nueva información se tendrá una idea clara del impacto, positivo o negativo, sobre el proceso en general.


Para terminar, vale la pena aclarar que el método PSP, propuesto por Watts Humphrey para alcanzar los objetivos anteriores, es sumamente invasivo. Interviene activamente en cada etapa y rige gran parte del proceso, todo con el fin de obtener medidas precisas y confiables, indispensables para el análisis posterior. He ahí la razón de su complejidad.




lunes, 31 de marzo de 2014

Json to Dom with jQuery

jQuery plugin to fill in DOM nodes with JSON. Simpler and more flexible than most templating / binding engines:
https://github.com/gescript/json-to-dom


domingo, 9 de marzo de 2014

Versionar Base de Datos y versionar los datos de la DB


En #AgileOpenBogotá (estuvo buenísimo!) mientras Adrián Moya nos contaba sobre los métodos y herramientas automatizadas para operaciones basadas en las técnicas ágiles tales como TDD, BDD, ATDD, Integración Continua...etc. Surgió una duda sobre los problemas de versionado de la base de datos.

En el caso expuesto como problemático, la base de datos cambiaba con el tiempo, de tal manera que en poco tiempo los datos eran incompatibles entre versiones. El escenario se hacía más complejo al tener, obligatoriamente, que mantener diferentes versiones de la base de datos de manera concurrente.

El caso puntual: cuando es el cliente quién decide (o no) actualizar. Por ejemplo: un juego en línea descargado desde una tienda para dispositivos móviles, tabletas o pc's.

O un caso adicional: cuando la ley exige la integridad de esos datos (como en contabilidad) pero esa misma ley es cambiante en cuanto a métodos, fórmulas o restricciones; como por ejemplo una reforma tributaria. O simplemente la base de datos es muy grande.

Para hacerse una imagen del problema, piense en el software como una fábrica de televisores donde cada rutina es una máquina ensambladora. Cuando un televisor recién ensamblado presenta un defecto se puede encontrar la máquina que está fallando para ser reparada o reemplazada (trazabilidad interna) y el televisor se repara o desecha. Si el televisor está fuera de la fábrica; usando trazabilidad normal o inversa se obtiene el mismo resultado, depende de quién haya encontrado el defecto, ya sea el fabricante o el cliente.

Este ejemplo surge de las vacas locas donde la carne infectada debía ser retirada del comercio y la información de trazabilidad permitía encontrar el rancho de donde provenía.

Versionamos el software según sus partes o remiendos, pero no versionamos los datos.

Ese fenómeno puede bautizarse como las vacas locas del sofware. Tenemos software que consume productos de software. Pensar que en algún momento los datos se integrarán y las máquinas enloquecerán no es ficción, ocurre en las bolsas de valores a velocidades inimaginables y de forma compleja, dejando de paso pérdidas extraordinarias entre otros.

¿Qué hacer?

La explicación de Adrián (según entendí) solucionaba el problema registrando tanto la versión del software como la de la base de datos y migrando los datos al nuevo formato.

Pero este no es el caso. ¿Qué hacer si no es posible migrar los datos? ¿Hay una opción simple, barata, fácil de implementar y mantener?

Primera solución (ingenua y causa overhead.)

Agregar una columna a cada tabla donde se registra la versión del software que la elaboró (tal como se marca el televisor e inviolable como una llave primaria.) Será un valor diferente a la versión de la base de datos (un entero basta.)
Con esto al menos el software podría reaccionar ante registros desactualizados.

Otra solución (engorrosa y absurda.)

Crear una base de datos nueva cada vez que hay un cambio. Pero, un select o un join serían trabajo arduo, incluso imposible.


¿Qué otras soluciones hay?

En verdad hay muy poca información sobre trazabilidad normal e inversa en este campo (o no la supe hallar.)


Mientras tanto, el aviso "Hay una nueva versión del software, descárguela o asuma las consecuencias" es una opción "recomendable".


jueves, 27 de febrero de 2014

Modelo-Vista-Controlador (MVC) con JQuery - Ejemplo Básico

Este ejemplo de "hello world" sale de http://cakebaker.42dh.com/2007/03/17/mvc-with-javascript/ Lo que hice fue actualizarlo para JQuery.

--- HTML ---
  <a id="userEvent" href="#">
 notify user action to controller
  </a>

  <div id="feedBackMessages"> </div>


--- JavaScript ---
  var model = {}, view = {}, controller = {};
 
  model.getText = function () {
 return 'hello world';
  };

  view.showMessage = function (message) {
 $('#feedBackMessages').html(message);
  };

  controller.sayHelloWorld = function () {
 view.showMessage(model.getText());
  };
 
  $("#userEvent").click( function(event){
 event.preventDefault();
 controller.sayHelloWorld();
  });

sábado, 9 de febrero de 2013

KATA ARQUITECTURA


Sensei: Carlos Peix
Facilitador: Luis Mulato
Duración: 2 horas.
Lugar: Hackbo, Bogotá.

Por el número de participantes se dividió el ejercicio en dos grupos. Cada uno resolvería un problema diferente durante 40 minutos.
Ambos problemas coincidieron en tener múltiples usuarios y cobros en dinero aunque se trataban de negocios diferentes.
Un grupo centró su solución en cuatro aspectos: escalabilidad, concurrencia, consistencia (dinero) y seguridad. Se planteó que la latencia era un problema a la hora de lograr un sistema justo con igualdad de oportunidades. En la solución escogida participaban cuatro sistemas físicos independientes, uno de ellos, la comunidad, se resolvía usando una base de datos de grafos (Neo4J). Otros dos de los sistemas serían contratados y el centro de la solución usaría una base de datos tipo memcaché con un mecanismo sofisticado de backup. Se habló también de usar "event sourcing".
El otro grupo produjo una especie de sistema por "apartamentos" con una interfaz de administración donde la nube era protagonista. El caché fue un tema central de diseño y quedó por determinar si era central o distribuido.
Una vez vueltos a agrupar expusimos el problema, la solución y el estado de avance.
Sobre la caché del segundo ejemplo se propuso usar un proxi inverso a una aplicación de una sola página (SPA), como gmail por ejemplo.

Sobre Neo4j:

Sobre SPA:

Y sobre "event sourcing": 


Nota: La descripción de los problemas fue omitida para que el material pueda ser usado de nuevo.

Hice este ejercicio con el fin de promover la participación en este tipo de eventos

sábado, 21 de agosto de 2010

YUI 3 JavaScript Alloy Calendar Set MinDate

El post donde nace es (pero en español puedo ser más locuaz):
http://yuilibrary.com/forum/viewtopic.php?f=206&t=4122&start=0&sid=1ea15b5959719f92d8ab84a660bd4f80


Aclaro que se trata de un método de fuerza bruta para obtener un comportamiento que el objeto no proporciona. Así que debe considerarse como una herramienta de prototipado, sólamente para mostrar "el concepto".
El truco es destruir el objeto conservando su estado interno. En este caso, se trata de un objeto complejo: un widget en javascript que muestra un calendario. Pero puede ser cualquier cosa, desde un desarrollo propio hasta un objeto comprado por el que hay que esperar una actualización.

En este caso, el widget no provee (por ahora) una función que permita establecer minDate luego de haber dibujado el calendario. Aprovecharemos los eventos personalizados y funciones de YUI 3. También un mecanismo del mismo componente: un evento que informa una selección de fecha. Advierto que puede ser una patada para el browser si se usa en forma intensiva.
En este ejemplo, el calendario establece su propio minDate en un ciclo infinito.
//Alloy calendar
function newCalendar(oMinDate) {
 new A.Calendar({
  id: 'xxCal',
  trigger: '#input1',
  dateFormat: '%m/%d/%Y',
  setValue: true,
  minDate: oMinDate,
  maxDate: null,
  firstDayOfWeek: 0,
  on: {
   select: function (event) {
    A.fire('calMinDate:newMinDate', 
      event.date.formatted.toString());
   }
  }
 }).render()
}
//Destroy DOM elements and make new calendar object
function crtlCalendar(calMinDate) {
    A.Node.one('#xxCal').set('innerHTML', '');
    A.Node.one('#xxCal').remove();
    newCalendar(calMinDate);
}
//Our custom eventhandler
A.on('calMinDate:newMinDate', crtlCalendar);

//Now, our first object
newCalendar('08/24/2010');


El equivalente apropiado, si existiera (pero existirá), sería:

new A.Calendar({
 id: 'xxCal',
 trigger: '#input1',
 dateFormat: '%m/%d/%Y',
 setValue: true,
 minDate: oMinDate,
 maxDate: null,
 firstDayOfWeek: 0,
 on: {
  select: function (event) {
   this.setMinDate(
     event.date.formatted.toString());
  }
 }
}).render()


Este mecanismo tiene nombre, se llama "continuación".

Un experimento previo con YUI 3 es un MVC "hello world" que busca mostrar el concepto de Modelo Vista Controlador en forma concreta.

sábado, 14 de agosto de 2010

Parábola del Actor: el Acto termina

En el post anterior (Parábola del Actor y el Objeto) se planteó la idea de procesos ligeros e inmortales en memoria. Pero esta situación no es realista, estos procesos deben terminar algún día. La solución es simple: el proceso no se vuelve a llamar a sí mismo; el garbage colector se encarga del resto.
Por ejemplo estos dos mensajes terminan el proceso:

vendeDor(PrecioArticulo, CompradorActual, VentasLogradas) ->
 receive
  {despedido, Jefe } ->
   Jefe ! {enCurso, self(), CompradorActual },
   adios;
  {jubilado, Jefe } ->
   Jefe ! {enCurso, self(), CompradorActual },
   graciasADios
 end. 

La siguiente pregunta es:
¿Qué sucede si hay una actualización del módulo "vendedor"? ¿Se detiene todo para poderlo online?


Lo mejor sería reemplazar el código "in-runtime" (en caliente), finalizando las operaciones pendientes usando el código antiguo y atendiendo las nuevas con el más reciente. (En Erlang existe y es un tema avanzado, se llama "release handling".)




Estos dos conceptos implican una entidad superior que lo controla todo. Obviamente se trata de un principio de diseño llamado árbol de supervisión compuesto por trabajadores y supervisores.




Espero con esto haber despertado un poco de interes en esta tecnología.



Viene de: Parábola del actor y del objeto.


Relacionados:
Erlang: Programación funcional y concurrente.
Mapeo de actores a objetos.