05.28.08
Estándar Condificación y Trabajo v1.2
Libero la v1.2
Se añaden estándares para el Controlador y un modelo de trabajo base para la arquitectura de N-Capas.
Saludos.
Miguel.
[?]
05.27.08
Mensajes
Hasta hace poco cierta sucursal bancaria de este país mostraba el siguiente mensaje en sus cajeros automáticos tras realizar una operación de reintegro:
“¿Desea imprimir el comprobante?”
Recientemente se ha actualizado el aplicativo y el mensaje ha pasado a ser el siguiente:
“¿Necesita imprimir el comprobante?”
Hay que ver lo que cambia la frase modificando únicamente una palabra. Inicialmente el valor de la aplicación era que tenía la capacidad de imprimir un comprobante siempre que el cliente lo deseara. Ahora mismo, si queremos el comprobante lo podemos seguir obteniendo, pero, la aplicación nos hace reflexionar si realmente vamos a hacer uso del mismo, si lo vamos a aprovechar, si realmente nos merece la pena gastar papel.
Podrá parecer exagerado, pero a mi me ha dejado maravillado.
Saludos.
Miguel.
[?]
05.24.08
Scrum, Formato de la Reunión de Planificación del Sprint
Siguiendo el libro “Flexibilidad con Scrum” de Juan Palacio (http://www.navegapolis.net), del que ya hablamos en su momento en este mismo blog, paso a redactar unas líneas extraídas del capítulo donde se habla del formato que debería tener la reunión de planificación del sprint. Me tomo la libertad de resaltar en negrita las afirmaciones que más me han llamado la atención.
“Los miembros del equipo se auto-asignan las diferentes tareas teniendo como criterio sus conocimientos, intereses y distribución homogénea del trabajo. Esta segunda parte (en el mismo libro se define que la reunión de planificación del sprint tiene que estar dividida en dos partes), debe considerarse como una reunión de equipo, en la que deben estar todos los miembros y ser ellos quienes descomponen el trabajo en tareas, las asignan y estiman“.
Me temo que los cimientos de más de uno se habrán removido al leer cosas como estas. Resulta un ataque frontal a la manera de trabajar de muchas empresas que a mi sinceramente me parece como mínimo más que interesante (aunque está claro que no es aplicable en el 100% de los contextos).
Con maneras de trabajar así, temas como el “nivel de implicación” y “motivación” del equipo tienen que estar por defecto a niveles altísimos. Y los que tenéis experiencia en el desarrollo de software sabréis que la motivación del equipo de trabajo es uno de los pilares fundamentales para conseguir alcanzar los objetivos.
Saludos.
Miguel.
[?]
05.22.08
¿Servicios Web Polimórficos? (Parte 2 – Solución con WCF y Framework 3.5)
Hace ya bastantes artículos atrás estuvimos hablando de Servicios Web y Polimorfismo (aquí). Introdujimos el tema y le dimos alguna vuelta a la necesidad de poder aplicar el concepto de polimorfismo a las llamadas de un servicio web. Es más, incluso lo intentamos utilizando Servicios Web en .NET mediante el Framework 2.0… y… comprobamos que no era posible.
Quedaron abiertas otras soluciones, pero hasta el momento no había podido invertir tiempo en este tema, así que ahora que ya tengo algo que mostraros, allá vamos!
Para empezar, como habréis podido observar la solución parte del uso de WCF (Windows Communication Foundation). En concreto para la solución he empleado Visual Studio 2008 y el Framework 3.5 (remarco lo de la versión del Framework, ya que esta misma solución utilizando el WCF y el Framework 3.0 no os va a funcionar, ya que no se hace igual). Estamos de suerte y la solución con el Framework 3.5 la verdad es que es sencillísima.
Paso a mostraros fragmentos de código sueltos y luego os adjuntaré el proyecto para que podáis ver y probar vosotros mismos que funciona. Eso sí, avanzo que el código del proyecto es simplemente para probar el funcionamiento así que le faltarán comentarios y demás cosas que intentaré añadir directamente aquí.
Bien, antes de nada empezar diciendo que voy a intentar seguir la guía del primer intento que hicimos de Servicios Web Polimórficos, en la que la idea era conseguir tener un único Servicio Web que nos ofreciera la posibilidad de realizar el mantenimiento de infinitas entidades de datos, en lugar de tener un servicio diferente para cada una de ellas. Para hacerlo necesitábamos que el cliente que consume el servicio recibiera en la definición de su WSDL las clases que implementaban la interfaz IDTO, pero no había manera de que la aplicación de servicios al generar el WSDL lo hiciera de forma automática.
La idea sería tener un servicio web que tuviera métodos como los siguientes (para los que no conozcan la teoría de los DAO, DTO y Factorías, podéis encontrar literatura en la categoría de patrones de este mismo blog):
public void Insert(IDTO dto)
{
Factory.GetDAO(dto).Insert(dto);
}
public void Update(IDTO dto)
{
Factory.GetDAO(dto).Update(dto);
}
public void Delete(IDTO dto)
{
Factory.GetDAO(dto).Delete(dto);
}
Como véis esto sería la leche ya que cualquier llamada al servicio sería capaz de ejecutar la acción independientemente del DTO que le llegue…
Por aquí dejo el código de la factoría, que como véis, según el DTO que recibe, retorna el DAO correspondiente.
public class Factory
{
public static IDAO GetDAO(IDTO dto)
{
if (dto is CocheDTO)
{
return CocheDAO.GetInstance();
}
else if (dto is MarcaDTO)
{
return MarcaDAO.GetInstance();
}
throw new Exception(“no existe este dto”);
}
}
Además, como podréis observar, todos los DAO heredan de IDAO, que es quien define los métodos con los que un DAO puede trabajar, y es lo que usa la factoría para actuar con independencia.
Pero bueno, vamos al grano y a lo que interesa, que es cómo conseguir que se entere el cliente que recibe el servicio de los DTO que pueden heredar de IDTO. La clave está cuando definimos la clase IDTO.
[DataContract]
[KnownType(typeof(DTO.CocheDTO))]
[KnownType(typeof(DTO.MarcaDTO))]
public class IDTO
{
}
Sobre la clave DataContract, ya hablaremos cuando hagamos la introducción a WCF, en lo que quiero que os fijéis es en las claves KnowType. Aquí es donde estamos marcando al servicio que IDTO tiene como tipos conocidos otras clases, que son las que heredan de ella. Por cierto, habréis visto que IDTO es una clase y no un interfaz… por lo visto el atributo KnowType no puede utilizarse con interfaces, pero bueno nos da lo mismo en este caso.
Con todas estas combinaciones que os he presentando, y si probáis el ejemplo donde tenéis más código, veréis que en el cliente que se ha montado (que es una aplicación de escritorio con un botón), podréis leer el siguiente código:
Servicio.MiServicioClient cliente = new Servicio.MiServicioClient();
Servicio.CocheDTO coche = new Servicio.CocheDTO();
Servicio.MarcaDTO marca = new Servicio.MarcaDTO();
coche.Codigo =1;
coche.Matricula=”IB-4444-TRT”;
coche.NumeroPuertas=1;
cliente.Insert(coche);
marca.Codigo = 4;
marca.Nombre = “Mercedes”;
marca.Pais = “España”;
cliente.Update(marca);
Bingo! El cliente es capaz de instanciar objetos que no son retornados o pasados por parámetro explícitamente por un método de un servicio (que era uno de los problemas que teníamos con el Framework 2.0). “Mágicamente” podemos utilizar los DTO en cliente, rellenarlos y pasárlos a los correspondientes métodos de Insert y Update. Al llegar la petición al servicio, la factoría decide el DAO a llamar en tiempo de ejecución y a correr.
Con un único servicio podríamos realizar toda la fachada para mantener y consultar infinitas entidades de negocio. ¡Objetivo cumplido!
Os invito a descargar la solución de ejemplo que os adjunto y a lanzarla en modo debug, veréis que si lo seguís la ejecución mantiene el flujo que hemos definido sin problemas.
Saludos.
Miguel.
[?]
05.21.08
Definiendo el Negocio a Base de Flujos
Empiezo el artículo mostrando un típico flujo de trabajo de una aplicación de venta. Este es un flujo sencillo y seguramente reconocido por todos.
Hemos hablado ya de algún motor de flujo, como Workflow Foundation o W4, pero creo que se me olvidó remarcar la potencia que supone para los propios conocedores de su negocio la capacidad de trabajar con un motor de gestión de flujos de trabajo.
El propio conocedor del negocio define los pasos a seguir, las relaciones entre ellos, condiciones, responsables de las tareas, etc. Lo único que queda aquí es que describa a una persona más técnica (un programador por ejemplo) qué actividades comprenden la realización de una tarea concreta del flujo.
Una vez definidas las actividades relacionadas con una tarea, dichas tareas pueden reutilizarse en el mismo flujo o en otros. Imaginad por ejemplo dos flujos en los cuales se tiene que imprimir una factura, podríamos reutilizar la misma tarea que ya desarrollamos.
La mayor potencia de este tipo de soluciones es que el disponer de todos los pasos de manera tan visual ayuda a comprender mejor cómo funciona el negocio, a encontrar fácilmente mejoras en el procedimiento (vemos en el flujo que la disminución del stock y la impresión de la factura son labores que pueden realizarse en paralelo), a detectar errores y a manipular el orden o la secuencia de los pasos a seguir.
Si quisiéramos permitir una nueva forma de pago, añadiríamos una nueva tarea al flujo y únicamente deberíamos definir el conjunto de actividades que la representan.
Esto es el futuro señores.
Saludos.
Miguel.
[?]
05.20.08
Navaja de Occam y Principio Fundamental KISS
Navaja de Occam
La navaja de Occam (navaja de Ockham o principio de economía o de parsimonia) hace referencia a un tipo de razonamiento basado en una premisa muy simple: en igualdad de condiciones la solución más sencilla es probablemente la correcta.
Principio Fundamental de KISS
El principio KISS es aquel que recomienda el desarrollo empleando partes sencillas, comprensibles y con errores de fácil detección y corrección, rechazando lo enrevesado e innecesario en el desarrollo de sistemas complejos en ingeniería.
Este término es un acrónimo que corresponde a la frase en inglés ”Mantenlo simple, estúpido” (Keep It Simple, Stupid). Para evitar ser tosco, el acrónimo se hace corresponder con otras expresiones tales como “Manténgalo breve y simple” (“Keep It Short and Simple”) u otras similares, pero que mantienen la misma idea del principio.
Ambas descripciones han sido extraidas de Wikipedia.
Saludos.
Miguel.
[?]
Singletonitis
“Dícese del abuso del Patrón de Diseño Singleton en una aplicación”.
Catalogado como Antipatrón de diseño en Wikipedia.org
Lo que no veo explicado por ningún lado cuándo se puede considerar que se está abusando…
Saludos.
Miguel.
[?]
05.19.08
Repositorios de Código, la Potencia de Trabajar con Ramas
Hablamos ya anteriormente de “Repositorios de Código Fuente”, una herramienta básica para ayudar a mantener la “Gestión de Configuración” de nuestro proyecto (algo de lo que hemos hablado también).
Entre las principales bondades de los Repositorios de Código hablamos de la trazabilidad completa y de la posibilidad de trabajar con ramas. El uso de ramas es algo en lo que me gustaría hacer algo más de fuerza, ya que me temo que aunque haya bastante gente que esté acostumbrada a trabajar con respositorios como CVS, Subversion y SourceSafe, no hay tanta que esté acostumbrada a utilizar la posibilidad de utilizar ramas, una opción que permiten los tres repositorios.
Pongo un ejemplo de una situación que seguramente os sonará.
Estamos desarrollando una aplicación de la cual hemos liberado nuestra flamante version 1.0, fruto de un esfuerzo de varios meses de trabajo. Una vez liberada, varios clientes adquieren la aplicación por la cual pagan una cantidad de dinero tanto por su adquisición como por el mantenimiento de la misma (nuevos módulos y corrección de errores). Pasan las semanas y tras las primeras impresiones que se reciben por parte de los clientes, se decide comenzar el desarrollo de nuevos módulos y ampliación de los módulos existentes. Y cuando llevamos ya un mes de nuevos desarrollos para lanzar la esperada versión 2.0… uno de nuestros clientes explota un error de aplicación debido a que un módulo en concreto gestiona de manera incorrecta la memoria. Este fatídico error provoca que el cliente no pueda facturar el mes, y deja al descubierto un problema que se puede dar también en el resto de clientes que están utilizando la v1.0.
¿Qué hacemos ahora? Estamos a mitad del desarrollo de la v2.0. Ante esta situación podríamos plantear una solución de mínimos que pasaría por invitar al cliente que ha detectado el error a esperar a que salga a la luz la v2.0, y mientras tanto rezar que el resto de clientes que tienen la v1.0 (ya hemos vendido e instalado la aplicación en más de 20 clientes) no les ocurra lo mismo.
La otra opción, claro está, es utilizar ramas. Si tras cerrar la v1.0 hemos marcado la versión como línea de base, estamos salvados. Únicamente tendremos que partir de la v1.0, hacer la rama correspondiente y actualizar el código necesario para resolver el error. Una vez realizados los cambios, marcamos dicha versión como la versión 1.0.1, paquetizamos, y enviamos la versión de actualización a todos los clientes. Además, el propio repositorio de código va a permitir que podamos solventar directamente los cambios de código en la futura v2.0, en la que debemos evitar también el error.
Esta segunda solución va a permitir entre otras cosas mantener dos equipos de trabajo, uno centrado en nuevos desarrollos y otro preparado para solventar los posibles errores o pérdidas de versiones ya publicadas. Además dicho segundo equipo sería el encargado también de mezclar las correcciones en la nueva versión.
Saludos.
Miguel.
[?]
05.14.08
Definición de Soporte
Añado una nueva definición de la Real Academia Española respecto a una palabra más de las que normalmente utilizamos en el ámbito del desarrollo de software. En su día, empezamos este grupo de posts hablando de “Eventos”.
Soporte
(De soportar).
1. m. Apoyo o sostén.
2. m. Heráld. Cada una de las figuras que sostienen el escudo.
3. m. Quím. Sustancia inerte que en un proceso proporciona la adecuada superficie de contacto o fija alguno de sus reactivos.
4. m. Telec. Material en cuya superficie se registra información, como el papel, la cinta de vídeo o el disco compacto.
Añado también como complemento la definición de “Soportar”, ya que me ha hecho especial gracia.
Soportar
(Del lat. supportāre).
1. tr. Sostener o llevar sobre sí una carga o peso.
2. tr. sufrir (‖ aguantar, tolerar).
Fuente: http://www.rae.es
Saludos.
Miguel.
[?]
Estándar Codificación y Trabajo v1.1
Libero la v1.1
Añadidos los primeros modelos de trabajo, en concreto al respecto del uso del repositorio de código fuente. Nuevas nomenclaturas de estándares de vista y base de datos.
Saludos.
Miguel.
[?]