Lucas Ontivero

Trata de Patron Factory Method 1

Wed, 30 Jul 2008 05:36:56 GMT

Cita

Patron Factory Method 1

Video: Patron Factory Method 1

Lucas en Geeks.ms

Thu, 27 Sep 2007 21:03:07 GMT

Rodrigo Corral me ha invitado a formar parte de Geeks.ms y he aceptado con gusto su propuesta. Es por esto que no voy a escribir más en este espacio y los invito a que se subscriban a mi nuevo blog en http://geeks.ms/blogs/lontivero .

Saludos a todos.

Lucas Ontivero

[Anti-Patterns] Contenedor Mágico

Fri, 14 Sep 2007 19:31:30 GMT

El la facu siempre renegaba con mis compañero en cuanto a la calidad de código, ciertamente la inmensa mayoria escribia código extremadamente malo. Nunca pensé que luego, en empresas de software de gran nivel como en la que estoy ahora, iba a seguir renegando con lo mismo. La clase que estoy revisando ahora tiene 36.307 lineas!

Así que acá va la descripción de este antipatrón de novatos.

Un contenedor mágico es un antipatrón de desarrollo que surge cuando, por inexperiencia, se crean métodos (o funciones) que sirven a una gran cantidad de propósitos afines. Este antipatrón se hace evidente cuando se advierten métodos que reciben una enorme cantidad de parámetros muchos de ellos opcionales, de tipos muy generales, arrays o listas y, muchas veces, retornan también mas de un valor mediante los parámetros pasados por referencia (punteros en C/C++, parámetros out en c#).

La motivación de quien codifica este código radica en el afán de maximizar el reuso de una rutina mediante una generalización excesiva. Esto lo lleva a intentar la panacea de lograr la función que "sirve para todo".

Un ejemplo común se ve con frecuencia en los cursos de programación universitarios en los que los alumnos crean sus funciones "LlenarGrilla(....)" las cuales les permiten completar grillas (controles visuales) de muchas formas diferentes, ordenadas según ciertas columnas, con filas coloreadas según algunas condiciones, con formatos por columnas, ancho por columnas, con bordes o sin ellos, editables o no, etc. Para lograr esto, una función "LlenarGrilla(....)" debe recibir un número significativo de parámetros, muchos opcional, muchos arrays de objetos, algunos booleanos, otros strings y así según las funcionalidades que los alumnos deseen.

El código final resulta en extremo complejo y dificil de mantener. Cuando surge un nuevo requerimiento, que la función no contempla, solo queda agregar más parámetros a su firma e intentar introducir la nueva característica. Este proceso se repite hasta que se vuelve inviable.

Lo puse en wikipedia (Contenedor mágico) porque no estaba pero alguién en cualquier momento lo va a mejorar.

Lucas Ontivero

[Patterns] UnitOfWork

Fri, 14 Sep 2007 18:42:33 GMT

[Translate this post to english with google]

Este es uno de los patrones más útiles (desde mi punto de vista) con que me he encontrado en el libro "Patterns of Enterprise Application Architecture" (P of EAA) de Martin Fowler. Como dice Martin en su libro este patrón:

"Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems."

Este patrón se utiliza entonces para trabajar con un conjunto de objetos persistentes que deben tratarse como una "unidad" de trabajo, almacenandose en una base de datos de manera atómica. Este patrón es el encargado de trackear todos aquellos objetos que son nuevos, y que por lo tanto deben persistirse, todos los objetos que han sido modificados y que deben actualizarse en la DB y todos los que han sido borrados y deben quitarse de la base de datos.

Mediante la implementación del patrón UnitOfWork, se logra una disminución de la cantidad de idas y vueltas hacia la base de datos ya que los cambios se realizan por lotes (o unidades de trabajo) redundando en una mejora de la performance del sistema porque muchas veces el cuello de botella de las aplicaciones se encuentra en la red de datos. Otro aspecto interesante es que posibilita el esquema de trabajo desconectado con bloqueos optimistas sobre la base de datos, es decir, no se mantienen bloqueados los registros por largos períodos de tiempo sino que se abre una conexión, se inicia una transacción, se hacen los cambios, se commitea y se libera la conexión todo esto en muy pero muy poco tiempo.

De ser necesaria la incorporación de un control de concurrencia sobre los registros que serán afectados durante la transación, de modo de mantener la consistencia de los datos, este patrón nos brinda el ámbito adecuado en donde implementarlo.

Veamos un caso concreto, el famoso ejemplo de la factura. Existe una factura que el usuario debe modificar, entonces traemos desde la base de datos la factura con sus items (de factura) cargados, luego, una vez que lo presentamos en pantalla, el usuario hace lo siguiente:

Agrega dos items más a la lista de items,
Modifica el importe y/o la cantidad de productos de uno de los items y finalmente,
Elimina uno de los item.

En este caso, cuando deben persistirse los datos? apenas agrega, modifica o elimina un item? o debe tratarse a la factura como una unidad y persistir todo junto? Si algo falla,... debe guardarse el resto? que sucede si otro usuario (además del que estamos hablando) estaba trabajando con el mismo documento al mismo tiempo pero guardó primero? como sabemos que fue lo que modificó el usuario y que, por lo tanto, debemos guardar? guardamos primero la factura y luego los items o al revés?

Todas las respuestas a estas preguntas (que considero que las fuiste contestando) se resuelven mediante la implementación de este patrón.

Voy a explicarlo un poco. El Unit Of Work, como se observa en la figura de arriba, se implementa mediante una única clase la cual tendrá al menos tres listas, una lista para los objetos nuevos que deben guardarse en la db, otra lista para los objetos que han sido modificados y que por lo tanto deben modificarse en la db y, otra lista para los objetos que deben eliminarse. Opcionalmente, o mejor dicho, según la implementación lo requiera, puede contener una cuarta lista para almacenar clones de los objetos que se traen desde la base de datos, de manera que antes de persistir un objeto pueda corroborar, mediante estos clones de los objetos originales, que los registros correspondientes no han sido modificados por otro usuario.

Una razón para leer el libro y no solo conformarse con este artículo es que Fowler hace un análisi exaustivo de este patrón (y de todos sus patrones), sus formas de implementar, cuando implementarlos, pros y contras y sobre todo, lo que a mi más me gustó fueron los distintos intentos por hacer esta clase lo más transparente posible para el programador. Así, por ejemplo, analiza la posibilidad de que todas las clases persistibles hereden de una clase base que automáticamente las registre como nuevas en el contenedor, que cuando se invoque el setter methos de una propiedad, esta notifique al UnitOfWork correspondiente para que la registre como dirty, etc. Personalmente estube probando esto y otras ideas como AOP, que no me convenció para nada, y extensions methods con los cuales le agrega m'etodos de persistencia a los objetos que heredaban de esa clase base.

En cuanto a AOP, no me convención porque las opciones eran todas muy feas, o usaba el .Net Profiling API con C++ para capturar la ejecución del JIT y entonces inyectarle código MSIL a los setters, o las clases heredaban de ContextBoundObject para, mediante los proxies de remounting, poder interceptar las invocaciones a las propiedades (lento, sucio, que más?) o, usando un compilador de terceros (no MS) casi en todos los casos en beta 0.000001. Así que definitivamente por el momento no lo ví como una opción.

En resumen, creo que es mejor, aunque un poquito mas tedioso y propenso a errores, dejar que sea el programador quien registre los objetos en el Unit of Work.

Acá dejo una implementación sencillísima de UnitOfWork sin control de concurrencias y en colaboración con un DataMapper trivial. Más abajo les dejo un proyecto que implementa esta clase.

using System;

using System.Collections.Generic;
using System.Text;
using System.Transactions;
using System.Data.SqlClient;
using System.Configuration;
using System.Threading;
using System.Resources;

namespace Patterns
{
        // Nuestra clase UnitOfWork (Martin Fowler)
        public class UnitOfWork
        {
                // Aquí estan las tres listas de las que hablamos
                // Ademas de estas puede existir una cuarta que almacene
                // los objetos limpios (o que se leyeron de la db)
                List<IBusinessObject> newObjects;
                List<IBusinessObject> dirtyObjects;
                List<IBusinessObject> removedObjects;

                // Creamos las listas en este constructor
                public UnitOfWork()
                {
                        newObjects = new List<IBusinessObject>();
                        dirtyObjects = new List<IBusinessObject>();
                        removedObjects = new List<IBusinessObject>();
                }

                public void New(IBusinessObject bo)
                {
                        Guard.NotNull(Resources.parameter_is_null, "bo", bo);
                        Guard.IsTrue (Resources.object_is_dirty, dirtyObjects.Contains(bo));
                        Guard.IsTrue (Resources.object_is_deleted, removedObjects.Contains(bo));
                        Guard.IsTrue(Resources.object_is_already_inserted, newObjects.Contains(bo));

                        newObjects.Add(bo);
                }

                public void Remove(IBusinessObject bo)
                {
                        Guard.NotNull(Resources.parameter_is_null, "bo", bo);
                        if (newObjects.Remove(bo)) return;
                        dirtyObjects.Remove(bo);

                        if (!removedObjects.Contains(bo))
                        removedObjects.Add(bo);
                }

                public void Update(IBusinessObject bo)
                {
                        Guard.NotNull(Resources.parameter_is_null, "bo", bo);
                        Guard.IsTrue(Resources.object_is_deleted, removedObjects.Contains(bo));

                        if (!newObjects.Contains(bo) && !dirtyObjects.Contains(bo))
                        dirtyObjects.Add(bo);
                }

                // El método Commit es el encargado de iniciar las transacciones,
                // y realizar la invocación a la base de datos.
                public void Commit()
                {
                        string connectString = string.Empty;
                        using (TransactionScope transactionScope = new TransactionScope())
                        {
                                connectString = ConfigurationManager.ConnectionStrings["Patterns"].ConnectionString;

                                using (SqlConnection connection = new SqlConnection(connectString))
                                {
                                        try
                                        {
                                                // Construimos las sentencias SQL para luego pasárselas a la DB
                                                // mediante un command. Para esto, en .Net hay que hacerlo separando
                                                // las sentencias con un punto y como (;)
                                                StringBuilder stringBuilder = new StringBuilder();

                                                foreach (IBusinessObject bo in newObjects)
                                                stringBuilder.Append(Mapper.Instance.Insert(bo) + ";");

                                                foreach (IBusinessObject bo in dirtyObjects)
                                                stringBuilder.Append(Mapper.Instance.Update(bo) + ";");

                                                foreach (IBusinessObject bo in removedObjects)
                                                stringBuilder.Append(Mapper.Instance.Delete(bo) + ";");

                                                string command = stringBuilder.ToString();

                                                // Abre la conexió, crea el comando con las sentencias SQL
                                                // e invoca al RDBMS.
                                                connection.Open();
                                                SqlCommand command1 = new SqlCommand(command, connection);
                                                command1.ExecuteNonQuery();

                                                // Limpia las listas si todo estuvo bien.
                                                ClearAll();
                                        }
                                        catch (Exception ex)
                                        {
                                                System.Console.WriteLine("Exception Message: {0}", ex.Message);
                                        }
                                }
                                transactionScope.Complete();
                        }
                }

                private void ClearAll()
                {
                        newObjects.Clear();
                        dirtyObjects.Clear();
                        removedObjects.Clear();
                }
        }
}

El proyecto: http://www.carloszanini.com.ar/shared/UnitOfWork.zip No esperen gran cosa. Gracias a Carlos Zanini por el hosting.

Lucas Ontivero

Ajax and JSON

Wed, 12 Sep 2007 16:29:06 GMT

Estaba leyendo acerca de mappers y en particular sobre como resolver los problemas de impedancia entre los distintos componentes de los sistemas cuando encontré este artículo que analiza la impedancia entre el W3C XML y los objetos en tecnologias como .Net.

Este problema se presenta, principalmente, en todas las aplicaciones que publican o consumen servicios web ya que XML y WS se relacionan de tal forma que se han vuelto casi sinónimos (perdón por la burrada). Pero existe gente detras de cada tecnología que se ocupa de ocultar o mitigar este y otros asuntos mediante proxies y sistemas de serialización/deserialización.

ahora, en Ajax este es otro asunto. Asynchronous JavaScript technology and XML (AJAX) y JavaScript Object Notation (JSON) es el tema de este artículo.

Que es JSON?

JSON es un formato ligero de intercambio de datos", así se define un su website. Esto es, un formato de intercambio que cumple una función similar al XML pero ... NO ES XML!. La idea detras de JSON es utilizar la misma notación de los objetos en javascript para intercambiar datos. Es decir, que si tenemos el siguiente fragmento de código en javascript,

var contact = {
     "Name": "John Doe",
     "PermissionToCall": true,
     "PhoneNumbers": [ 
       {
           "Location": "Home",
           "Number": "555-555-1234"
       },
       {
           "Location": "Work",
           "Number": "555-555-9999 Ext. 123"
       }
     ]
};

la serialización de este objeto será exactamente idéntica al código fuente, osea:

{"Name": "John Doe", "PermissionToCall": true, "PhoneNumbers": [{"Location": "Home", "Number": "555-555-1234"}, {"Location": "Work", "Number": "555-555-9999 Ext. 123"}]

Que ventajas tiene y como se relaciona con Ajax?

Bien, todavia recuerdo cuando trabajaba con ASP 3.0 y XmlHttpRequest, cuando necesitaba consultar algo al servidor, este me lo devolvía en un xml que yo debia cargar en un DOM y manejarlo con XPath y getElementxxx() entre otros métodos, es decir, o hacia esto o lo deserializaba (a pata) y llenaba objetos JavaScript en el cliente. Pero esto era un poco duro y realmente una desgracia. La ventaja de JSON en este contexto particular es que la deserialización de los datos transmitidos se logra con solo hacer un eval() del mismo. Veamos este ejemplo:

xmlhttp.open("GET","/personnel/find?id=26481648",true);
xmlhttp.onreadystatechange=function() {
    if (xmlhttp.readyState==4) {
        if (xmlhttp.status!=404) {
            var employee=new Function("return "+xmlhttp.responseText)();
            alert("DNI : " + employee[0].dni+' - Full Name : '+ employee[0].fullname);
        } else {
            alert("Employee not found");
        }
    }
}

Como vemos, no hay DOMs ni rutinas de parseo de XMLs, ni proxies por ningún lado!!!. Además contamos con el modelo de objetos del servidor en el código que ejecuta el browser. Así es mas sencillo que nuestro código en el browser consuma web services y se simplifican muchas tareas. Aunque aclaro: no es el único propósito de JSON, JSON es un standar abierto para el intercambio de datos así que su utilidad no se acota a Ajax solo que es en este campo donde la contribucón se hace más notoria. Algunas ventajas sobre XML (tiene como todo en la vida sus desventajas también) son su extremada sencillez, es más compacto que un xml, trabaja con tipos mientras que xml solo puede validar si el contenido respeta un cierto tipo mediante un esquema, no necesita al menos en JavaScript ningún parser ni DOM, una curva de aprendizaje mucho menor.

Ahora, si trabajamos en .Net nos estaremos preguntando:

donde encaja JSON en un WS si estos utilizan XML?,
Si quisiera utilizarlo, como serializo mis objetos? tengo que hacer mi propio serializador?

La verdad es que la serialización no es un problema, existen muchos Framework para trabajar con JSON en .Net (Jayrock por ejemplo) los cuales son generalmente muy pequeños, fáciles y trabajan muy bien (por los comentarios en distintos sitios). También, para los que trabajan en ASP.NET está la implementación de AJAX "Serialization.JavaScriptSerializer".

En cuanto a los WSs, la única restricción real es que debe transmitir texto dentro de un sobre SOAP y nada más.

Algunos link muy interesantes:

JSON web site (en castellano)
An Introduction to JavaScript Object Notation (JSON) in JavaScript and .NET (completísimo, muy bueno y por gente de MS)
The B-List : I can't believe it's not XML! (muy buen artículo - explica muy bien el por qué JSON es una buena opción)
The JSON vs XML debate begins in earnest (discusión y comparación entre JSON y XML pros y contras - de alto vuelo)
MSDN Magazine: Client-Side Web Service Calls with AJAX Extensions (Algo práctico con ASP.NET)
Using JSON (JavaScript Object Notation) with Yahoo! Web Services (Otro ejemplo práctico - consumir WS de Yahoo - compara XML y JSON)
Silverlight and JSON (No lo leí pero dice "Silverlight 1.1 comes with an built-in JSON serializer which can..." )

Lucas Ontivero

Software Factories Blog

Sat, 08 Sep 2007 17:37:34 GMT

[Tanslate this post to english with google]

He creado un nuevo blog dedicado a todo lo referido a software-factories, patrones, metodologías y todo lo que esté orientado a incrementar la calidad, la productividad y el tiempo de entrega de los productos de software. Seguramente también incluiré algunas ideas y/o traducciones de artículos interesante. Ya he pasado algunos post de este blogs al nuevo. Véanlo en http://software-factories.blogspot.com/

Saludos.

Lucas Ontivero

[Benchmark] Reflection Performance

Thu, 06 Sep 2007 14:40:00 GMT

[Tanslate this post to english with google]

Escribiendo el próximo post sobre el patrón DataMapper mediante reflection (lo estoy cocinando) me puse a pensar en una lista de pros y contras como así también, algunos escenarios en donde yo lo implementaria y en donde no. Entre los argumentos en contra seguramente debía figurar el hecho de que reflection tiene un costo que hay que evaluar. Yo pensaba que este argumento bien podría ponerse en la balanza junto con todos los beneficios de este patrón y pensaba argumentar también que si bien, el uso de reflection es caro, tampoco es una locura.

Pero después me saltó la duda, cuan lento puede ser el uso de reflecion en comparación con un acceso convencional? Así que primero tiré un número a la mancancha, "debe ser 6 o 7 veces mas lento..." pensé. Y me puse a buscar en google, encontré este blog y este muy buen artículo y este otro blog que que aunque también hace la prueba parece que el benchmark está distorcionado porque lo hace con una aplicación winform en la que existen al menos dos threads compitiendo (UI y el que corre nuestro código).

Pero después me acordé de un proyecto que abusaba tanto de esta técnica que tardaba 3 minutos en arrancar!! Así que tiré otro número, "nooo, debe ser como 100 veces más lento". Así que hice mi propia prueba solo seteando un field, una property e invocando un método y los números me dieron la razón, en estos caso es mucho más lento.

Los números:

En un Pentium 4 de 2.8GHz y 1 GB de RAM / Windows XP PE SP2.

El mismo test (con bucles más chicos para irme a dormir más temprano) pero en un ADM 2800 con 512 de RAM /W2003 Server PE dió el resultado de arriba.

Si se corre este test más de una vez se obtienen resultados similares aunque distintos por varias razones, en primer lugar este test compite con las otras aplicaciones por el tiempo de ejecución por lo que nunca sabemos en que parte del código el S.O. nos interrumpe, otra cosa que distorciona es el hecho de que las operaciones de acceso directo a los campos, propiedades y métodos son más rápidas por lo que tienen menos posibilidades de ser interrumpidas por el planificador del SO. Esto último hace que a veces se obtengan brechas mayores a las que se muestran.

En síntesis, reflection es, al menos en estas operaciones, unas cientos de veces más lento que un acceso "común". También lo corrí poniendo el proceso con prioridad Hight y obtuve resultados similares.

Pueden impugnar este benchmark si ven algo que esté mal. Acá va el código:

using System;
using System.Text;
using System.Reflection;

namespace Temosoft.Benchmarks
{
        class Program
        {
                static void Main(string[] args)
                {
                        DateTime startDate;
                        TimeSpan ts;
                        int max = 10000000; //int.MaxValue;

                        TestClass t = new TestClass();

                        System.Console.WriteLine("----- FIELDS ------");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                t.field = i;
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "obj.field = i;", ts.Ticks);


                        Type type = typeof(TestClass);
                        FieldInfo fi = type.GetField("field");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                fi.SetValue(t, i);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "fieldInfo.SetValue(t, i);", ts.Ticks);


                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                typeof(TestClass).GetField("field").SetValue(t, i);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "typeof(TestClass).GetField(\"field\").SetValue(t, i);", ts.Ticks);


                        System.Console.WriteLine("----- PROPERTIES --");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                t.Field = i;
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "obj.Property = i;", ts.Ticks);


                        PropertyInfo pi = type.GetProperty("Field");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                pi.SetValue(t, i, null);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "propertyInfo.SetValue(t, i);", ts.Ticks);


                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                typeof(TestClass).GetProperty("Field").SetValue(t, i, null);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "typeof(TestClass).GetProperty(\"Field\").SetValue(t, i, null);", ts.Ticks);


                        System.Console.WriteLine("----- METHODS --");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                t.Method1(i);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "obj.Method(i);", ts.Ticks);


                        MethodInfo mi = type.GetMethod("Method1");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                mi.Invoke(t, new object[]{i} );
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "methodInfo.Invoke(t, new object[]{i} );", ts.Ticks);


                        mi = type.GetMethod("Method2");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                mi.Invoke(t, new object[] { i, i, i, i, i, i });
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "methodInfo.Invoke(t, new object[] { i, i, i, i, i, i });", ts.Ticks);

                        System.Console.ReadLine();
                }
        }

        class TestClass
        {
                public int field;
                public int Field
                {
                        set { field = value; }
                        get { return field; }
                }

                public void Method1(int i)
                {
                        field = i;
                }

                public void Method2(int i, int j, int k, int l, int m, int n)
                {
                        field = i;
                }

        }
}

Lucas Ontivero

[Patterns] Lifetime Container Pattern

Tue, 04 Sep 2007 15:52:20 GMT

Muchas veces es necesario mantener el control del tiempo de vida de los objetos. En tecnologias de código administrado como .Net o Java, a diferencia de otros como C y C++, existe un mecanismo de recolección de basura que libera al programador de la tarea de destrucción de objetos y la liberación de la memoria. No obstante, existen ocaciones en las que tener el control de la destrucción de los objetos es muy conveniente.

Por ejemplo, cuando la creación de un objeto consume mucho tiempo y recursos del procesador, crear estos objetos y permitir que se destruyan cuando se pierden las referencia a él puede que no sea una buena idea, en este caso se opta por crear un pool de objetos que no se destruyan cuando ya no se usen sino que permanezan disponibles aún cuando no se los esté usando. Otra situación se da cuando se necesita liberar un conjunto de recursos (objetos) que ya no se van a utilizar más porque en su conjunto representan o sirven a una sola unidad de trabajo. Un caso concreto es cuando se utilizan objetos que administran gran cantidad de otros objetos también completos como los WorkItem del Composite UI Appication Block el cual mantiene colecciones de objetos Views, Controlers, Commands, EventTopics, Services, SmartParts, UIExtensionSites, WorkSpaces, otros WorkItems y algunas cosas más. En este caso, cuando se libera un workitem, se deben liberar todos los objetos que han colaborado con él.

El Lifetime container, como su nombre lo indica, es un contenedor (una colección) que mantiene vivas las referencias a todos los objetos que se registran en él. Vamos al código:

using System;
using System.Collections;
using System.Collections.Generic;

namespace Temosoft.Containers
{
        public class LifetimeContainer : IEnumerable<object>, IDisposable
        {
                #region Private Fields
                // El contenedor interno que mantiene vivas las referencias.
                private List<object> items = new List<object>();
                #endregion

                #region Public Methods (Operations)
                public void Add(object item)
                {
                        items.Add(item);
                }

                public void Remove(object item)
                {
                        if (!items.Contains(item))
                        return;

                        items.Remove(item);
                }

                public bool Contains(object item)
                {
                        return items.Contains(item);
                }
                #endregion

                #region Public Properties (Read only)
                public int Count
                {
                        get { return items.Count; }
                }
                #endregion


                #region IDisposable interface
                public void Dispose()
                {
                        Dispose(true);
                }

                protected void Dispose(bool disposing)
                {
                        if (disposing)
                        {
                                List<object> itemsCopy = new List<object>(items);
                                itemsCopy.Reverse();

                                foreach (object o in itemsCopy)
                                {
                                        IDisposable d = o as IDisposable;

                                        if (d != null)
                                        d.Dispose();
                                }

                                items.Clear();
                        }
                }
                #endregion


                #region Enumerators
                public IEnumerator<object> GetEnumerator()
                {
                        return items.GetEnumerator();
                }

                IEnumerator IEnumerable.GetEnumerator()
                {
                        return GetEnumerator();
                }
                #endregion
        }
}

Como se puede ver, esta clase es muy parecida a una colección salvo porque implementa IDisposable para manejar la liberación de los objetos en orden inverso a su registración. No implementa ICollection porque en este caso no se debe posibilitar el método CopyTo() y porque en este caso, por razones de sencillez, no se hizo thread safe.

Como se ve, este es un contenedor sumamente sencillo y surge la pregunta "que hay de nuevo acá?", bueno, la verdad es que lo nuevo lo encontramos en la manera o las formas de usarlo. Veamos, en la entrada de este blogs: [Patterns] Distributed Applications using FactoryMethod and ServiceLocator Patterns, vimos como la clase ServiceLocator mantenia un diccionario de strings y objetos (después lo hicimos mediante object-object), este diccionario impide que los servicios que no se utilizan puedan ser eliminados! Como podemos manejar esto con un LifetimeContainer? la respuesta es NO mantener las referencias. Esto lo podemos hacer implementando el ServiceLocator mediante un weakRefDictionary<object, object> en lugar de un Dictionary<object, object>.

public class ServiceLocator
{
        private WeakRefDictionary<object, object> services = new WeakRefDictionary<object, object>();

        public void AddService(object serviceKey, object service)

Que beneficios nos trae esto? Ahora, cada componente, plugin, unit of work, form, o lo que sea puede registrar sus servicios, de manera que estén disponibles para todas los demas componentes, mientras dure su vida y que dejen de estarlo cuando ellos son destruidos (a menos que alguien los esté usando). Por lo tanto, cada componente tiene su propio Lifetime container para manejar el ciclo de vida de SUS objetos.

Lucas Ontivero

[Patterns] Distributed Applications using Facade Pattern

Fri, 31 Aug 2007 20:50:53 GMT

Este patrón tan sencillo es seguramente uno de los más importantes en el desarrollo de aplicaciones que publican sus servicios mediante Web Services. El motivo de este post es ayudar a entender la forma correcta de implementar Web Services con .Net.

El problema

Afortunadamente hoy contamos con muchas herramientas y facilidades para la creación y publicación de servicios web. En .Net, es increiblemente facil crear un servicio web a partir de una clase, solo hay que extender nuestra clase de la clase System.Web.Services.WeServices y adornar el o los metodos que queremos publicar con [WebMethod] y listo. Por ejemplo:

using System;
using System.Web.Services;

public class HelloWorld: WebService {
        [WebMethod(Description="Returns Hello", EnableSession=false)]
        public string Say() {
                return "Hello";
        }
}

El problema con estas facilidades es que muchos desarrolladores entienden que el objetivo de esto es exponer en el cliente, proxies mediantes, los objetos de negocios que se encuentra en el servidor. Esta creencia promueven un mal estilo de programación de los servicios web. Es más, no son servicios ya que se parecen mas a llamadas RPC o RMI. Esto es un error. No deben exponerse los objetos de negocio mediante un WebService.

Un escenario real: En un desarrollo para una empresa de reservas de hoteles, teniamos las clases Hotel, Habitacion, Reserva, Pasajero, Temporada y otras más. Un amigo se encargaba del desarrollo del cliente y sus necesidades eran claras, "necesito una lista con las disponibilidades (con los dias disponibles) y precios de las habitaciones de los hoteles en esos dias y la descripción de las comodidades o servicios que incluyen en esa temporada". Este y otros requerimientos no se corresponden con ningún objeto del negocio, es decir, sencillamente no se resuelven serializando y enviando ningún objeto del negocio.

La solución

La solución consiste en crear un Facade cuyos métodos representen los servicios que puede brindar la aplicación como por ejemplo: obtener disponibilidades de tal fecha a tal fecha para tantas personas en determinado sitio turístico, obtener nuevas reservas para un hotel determinado, reservar, cancelar reserva, etc.

Ahora, por lo general los métodos del Facade no tendrán problemas en cuanto a los tipos de parámetros a recibir ya que serán (repito, por lo general) tipos simples como int, DateTime, String, Boolean, Double, etc. Pero sí requerirán retornar al cliente tipos especiales que, como dije antes, no se corresponden con los objetos de negocio. Entonces esto ya no es una simple clase "ReservationFacade" sino que se trata de un componente (o layer) con sus propios tipos como Availability, Recommend, etc. Si bien estos tipos pueden, por sus nombres, parecer que pertenecen a los tipos del dominio en realidad no lo son. Por ejemplo, Recommend puede contener un destino o zona turística recomendada junto con una lista de ofertas de tipos de habitaciones con sus precios en distintos hoteles y los periodos de validez de estas recomendaciones.

Ventajas de este patron:

Facil de responder a los cambios. Si el Web Service debe modificarse para ajustarse a los nuevos requerimientos del negocio entonces solo es necesario modificar el Facade.
Facil de mantener. Es posible modificar la estructura interna (refactoring) de las clases de negocio sin alterar el contrato con los clientes de WS. Ya que no se crean dependencia entre las clases de negocio con las aplicaciones clientas.
Responde a la idea de servicios. Los servicios se consumen en operaciones atómicas. Es decir, el servicio de "Reservar habitación" se realiza mediante un solo mensaje con toda la información necesaria y es el Facade quien se encarga de realizar todas las operaciones (seguramente en una transacción).
Son mas veloces. Por la misma razón que expongo arriba se realizan muchas menos idas y vueltas desde el servidor al cliente y viceversa.

La ventaja quizás mas importante es independizar el WS del resto de la aplicación ahorrandonos de tener que regenerar el WS (salvo cuando tocamos el Facade) y por lo tanto evitamos tener que regenerar los proxies en todos los cliente de nuestro WS y recompilar todo, tanto nosotros como todos nuestros clientes que pueden estar utilizando nuestros servicios somos más felices.

Otra ventaje que se deriva del punto anterior es que el versionado de nuestro servicio se simplifica considerablemente.

Lucas Ontivero

[Patterns] Distributed Applications using FactoryMethod and ServiceLocator Patterns

Thu, 30 Aug 2007 20:08:38 GMT

En esta entrada vamos a ver la utilidad del patrón Service Locator para construir aplicaciones distribuidas. Los componentes de estas aplicaciones deben estar totalmente desacoplados y por lo tanto la mejor manera de hacerlo es mediante el consumo de servicios que obviamente respeten ciertos contratos.

Ok, largamos con el patrón FactoryMethod como patrón inicial para ver como llegamos al ServiceLocator. Entonces, basicamente, todo método que tiene por objetivo crear diferentes tipos de objetos implementa implementa el patrón FactoryMethod. Veamos un ejemplo:

 1 using System.Windows.Forms;
 2 
 3 namespace MyDocumentManager
 4 {
 5         enum DocumentExtensionEnum {DOC, PDF, XML};
 6 
 7         /* La clase Abstracta */
 8         public abstract class Document
 9         {
10                 public abstract void Show(Form container);
11         }
12 
13         /* Las clases concretas */
14         public class WordDocument : Document
15         {
16                 public override void Show(Form container){/*...*/}
17         }
18 
19         public class PDFDocument : Document
20         {
21                 public override void Show(Form container){/*...*/}
22         }
23 
24         public class XMLDocument : Document
25         {
26                 public override void Show(Form container){/*...*/}
27         }
28 
29         /* La clase creadora o consumidora de documentos */
30         public class DocumentManager
31         {
32                 DocumentManager(string filename)
33                 {
34                         Document doc = FactoryMethod(filename);
35                         doc.Show(new DocumentViewerForm());
36                 }
37 
38                 /* Este es el metodo */
39                 private Document FactoryMethod(string filename)
40                 {
41                         Document doc;
42                         DocumentExtensionEnum extension = GetExtension(filename);
43 
44                         /* crea el tipo de documento adecuado segun la extension del archivo */
45                         switch(extension){
46                                 case DocumentExtensionEnum.DOC:
47                                 doc = new WordDocument();
48                                 break;
49                                 case DocumentExtensionEnum.PDF:
50                                 doc = new PDFDocument();
51                                 break;
52                                 case DocumentExtensionEnum.XML:
53                                 doc = new XMLDocument();
54                                 break;
55                         }
56                         retrun doc;
57                 }
58         }
59 }
60

Este es un ejemplo claro, según la extensión del archivo, nos devuelve el objeto adecuado. El tema es ahora que en este método tenemos un switch hardcodeado! Es decir, no podemos agregarle otros tipos de objetos a crear sin modificar el código :(

Y aquí entra el patrón que nos convoca, el Service Locator. Se trata de un patrón creational el cual permite registrar servicios o componentes y luego solicitar una instacia de alguno de ellos. Veamos un poco de código:

public class ServiceLocator
{
        private Dictionary<string, object> services = new Dictionary<string, object>();

        public void AddService(string serviceName, object service)
        {
                if (string.IsEmptyOrNull(serviceName))
                throw new ArgumentNullException("serviceName");
                if (service == null)
                throw new ArgumentNullException("service");

                services.Add(serviceName, service);
        }

        public object GetService(string serviceName)
        {
                if (string.IsEmptyOrNull(serviceName))
                throw new ArgumentNullException("serviceName");

                if (services.ContainsKey(serviceName))
                return services[serviceName];

                return null;
        }
}

Aquí lo he implementado con un diccionario string-object para hacerlo mas facil pero despues voy a mostrar una alternativa mejor. Otra cosa, por lo general, solo existe una instancia de esta clase as'i que se implementa mediante un Singleton.

La ventaja que tenemos ahora es que podemos hacer una clase "Services Loader" la cual lea un archivo de configuración (seguramente deserealizando un xml) y que de acuerdo a eso cargue los servicios que hagan falta dentro del Service Locator. Esto es especialmente útil cuando queremos hacer un sistema plug-able porque podemos poner un assembly en un directorio y modificar nuestro xml de configuración de modo que esta clase Service Loader cargue ahora los nuevos servicios de nuestro assembly haciendo que estos esten disponibles para la aplicación.

A ver si se entiende bien! puedo por ejemplo:

IStorageManager sm = (IStorageManager)serviceLocator.GetService("Storage Service");

if(sm != null)
{
        sm.Save(myPersistentObject);
}
else
{
        IEventLogger ev = (IEventLogger)serviceLocator.GetService("Event Logger Service");
        if(ev != null)
        ev.WriteWarning(
        String.Format("{0} wasn't persisted", myPersistentObject.ToString()
        );

}

Bien, alguno debe estar pensando "y como hace un cast así! habria que validar que respete esa interface antes de castearla tan burramente!!!". Y sí, quien piesa así tiene razón, el tema es que lo hago así por sencilles y porque lo que quiero mostrar es que de esta manera lo que hacemos es: primero preguntamos si tenemos tal o cual servicio y de ser así lo usamos. Con este patrón (que todavia no tiene buena forma) podemos agregarle, sin tocar el código, un servicio de logueo cualquiera (que implemente la IEventLogger por supuesto). También podemos ponerle, sacarle o cambiarle el servicio de Storage registrando por ejemplo bajo el nombre de "Storage Service" a cualquier servicio que implemente la interface IStorageManage como por ejemplo, "SQL Storage Service", "Amazon Storage Services", "Web Blog Storage Service", etc.

Tanto que hablamos del "Service Loader" veamos como puede ser:
(Antes que nada, si ven algo que no anda es porque en la máquina en que estoy escribiendo esta entrada no tengo el .Net Framework 2.0)

[XmlRootAttribute("ServiceCatalog", Namespace="http://www.temosoft.com.ar/ServiceLoader", IsNullable = false)]
public class ServiceCatalog
{
        private Service[] services;
        public Service[] Services
        {
                get{ return services; }
                set{ services=value;  }
        }
}

[Serializable]
public class Service
{
        private string   serviceName;
        private string   assemblyName;
        private string   typeName;
        private Boolean  isAvailable;

        [XmlAttribute]
        public string ServiceName
        {
                get { return serviceName; }
                set { serviceName= value; }
        }

        [XmlAttribute]
        public string AssemblyName
        {
                get { return AssemblyName; }
                set { AssemblyName= value; }
        }

        [XmlAttribute]
        public string TypeName
        {
                get { return typeName; }
                set { typeName= value; }
        }


        [XmlAttribute]
        public Boolean IsAvailable
        {
                get { return isAvailable; }
                set { isAvailable= value; }
        }
}


public class ServiceLoader
{
        public void Load()
        {
                XmlSerializer serializer = new XmlSerializer(typeof(ServiceCatalog));
                FileStream fs = new FileStream("ServiceCatalog.xml", FileMode.Open);
                ServiceCatalog servicesCatalog = (ServiceCatalog)serializer.Deserialize(fs);

                foreach(Service s in servicesCatalog.Services)
                {
                        try{
                                Assembly asm = Assembly.Load(s.AssemblyName);
                                Type serviceType asm.GetType(s.TypeName);

                                ServiceLocator.Instance.AddService( s.ServiceName, Activator.CreateInstance(serviceType));
                        }catch(Exception e){
                        }
                }
        }
}

En este caso asuminos que el ServiceLocator es un Singleton. Es posible también hacer que cada servicio pueda recibir parámetros en su constructor. Ahora, como hacemos para mejorar esto?

public static class ServiceLocator
{
        private static ServiceLocator instance;
        private static object instanceLock = new object();
        private Dictionary<object, object> services = new Dictionary<object, object>();

        public ServiceLocator Instance
        {
                get
                {
                        if (instance == null)
                        {
                                lock (instanceLock)
                                {
                                        if (instance == null)
                                        {
                                                instance = new ServiceLocator();
                                        }
                                }
                        }
                        return instance;
                }
        }

        public void Add(object serviceKeyObject, object service)
        {
                if (serviceKeyObject==null)
                throw new ArgumentNullException("serviceKeyObject");
                if (service == null)
                throw new ArgumentNullException("service");

                if (!services.ContainKey(serviceKeyObject))
                services.Add(serviceKeyObject, service);
        }

        public object Get(object serviceKeyObject)
        {
                if (serviceName==null)
                throw new ArgumentNullException("serviceKeyObject");

                if (services.ContainsKey(serviceName))
                return services[serviceName];

                return null;
        }

        public T Get<T> (object serviceKeyObject)
        {
                object obj = Get(serviceKeyObject);
                if (obj != null && (obj is T))
                return (T)obj;

                return null;
        }
}

Si no te sirvió usa el ObjectBuilder :) ,que además de implementar este y otros muchos patrones muy grosos, implementa Inyección de Dependencias para un desacople muy bien pensado.

Lucas Ontivero.

[Software Factories] Introducción (Parte 2)

Mon, 27 Aug 2007 23:31:52 GMT

Ok. Esta es la parte dos de la introducción.

Realmente no quería caer en el mismo ejemplo de libro pero lo voy a hacer. La manera en que hoy desarrollamos software es exactamente igual a como se hacian los automóviles antes de Mr. Ford. Como era esto? Bueno igual que lo que hacemos hoy, venia un cliente y decía: quiero una auto así, así y así con madera de pino de Groenlandia, cuero de jaguareté y pedales de tutú carreta, entonces se diseñaba el auto de cero, a alguno se le ocurria que lo mejor era un rodado de marfil y aluminio de 23,67 pulgadas, etc. Una vez listo el diseño se ponian con los cerruchos, martillos, un tornito y otras herramientas y en 6 o 7 meses estaba listo. Salian mas o menos bien y costaban caro. Hoy en cambio todos los autos comparten un gran número de componentes comunes entre otras cosas gracias a los estandares. Son estos lo que me permiten enchufar mi televisor en cualquier parte del pais y que siga funcionando o cambiar el cuerito de la grifería sin tener que averiguar medidas.

Esta forma de trabajo se caracteriza por:

Uso intensivo de la mano de obra,
Uso de herramientas demasiado genéricas,
Mínimo reuso y,
Procesos genéricos

De esta manera se producen demoras en los tiempos de entrega, defectos, agujeros de seguridad y retrabajos. Además de imposibilitar la introducción de calidad desde el primer momento en cuanto a aquellos detalles diferenciadores como seguridad, usabilidad, desempeño, mantenibilidad y escalabilidad de los productos (sin causar fatigas por falencias en la arquitectura) entre otros.

Antes de continuar analizando los por qué del surgimiento de este paradigma vamos a definir algunos términos que son muy necesarios como por ejemplo el de Software Factory y luego voy a aclarar algunas cosas que me quedaron en el tintero del post anterior.

Definiciones

Software Factory

Si se le hubiese llamado de otra manera nos habriamos visto forzados a realizar un esfuerzo mental para averiguar y tratar de entender de que se trata este concepto pero desgraciadamente esta palabrita "Factory" nos habilita a pensar cualquier cosa. Las analogías que encontramos por todos lados con fabricas de zapatos o electrodomésticos terminan de confirmar nuestras fantasias mal fundadas. No son pocos los que creen que se trata de hacer software como si de automoviles se tratara, simplemente ensamblando algunas partes hechas en una linea de montaje y automatizando, robots mediantes, los detalles como el color de la pintura y otros. Bueno, no es así. La figura que adorna este post también confunde pero está muy buena para reflejar el estado actual del arte :)

Distingamos entre Software Factory como paradigma y como instancia. Como paradigma, es una alternativa a los métodos actuales de construcción que intenta resolver los 5 problemas planteados en el post anterior cuando las aplicaciones a construir comparten características comunes. Como instancia (SCSF por ejemplo), un Software Factory es un conjunto de herramientas, procesos tailorizados, frameworks, patrones y modelos (por lo general embebidos en los frameworks y/o herramientas integradas del IDE) y otros contenidos que usan para trabajar sobre una Linea de Productos. O mejor dicho, un SF es una linea de producto que utiliza un SF Template basado en un SF Schema.

Linea de Productos

Una linea de productos se refiere a un tipo de aplicación que puede agruparse o identificarse como perteneciente a una familia de productos como por ejemplo sistemas de CRM, software de seguros, software para entidades bancarias, de control aereo y cualquier otro. Es decir, pueden agruparse de distintas maneras, por segmento de negocios, tipo de soluciones, plataforma, etc. Lo importante es poder identificar aquellas características comunes. Tres aspectos claves de una linea de productos son: los alcances, la variabilidad y la extensibilidad. Los alcances determinan que tipo de soluciones pueden construirse a partir de la linea de productos y define por lo general la arcitectura base para la familia de aplicaciones, la variabilidad hace referencia a las parte comunes definidas en los alcances y aquellas que son variables por medio de configuración de la linea y la extensibilidad determina los puntos en los que es posible añadir funcionalidades.

Software Factory Schema

Un Software Factory Schema es un modelo general que por lo general utiliza grillas, gráficos o cualquier otro artefacto para describir cuales son los productos de trabajo, los pasos a seguir para construirlos, las relaciones existentes entre ellos. Esta es una herramienta para entender y posiblemente automatizar el funcionamiento del SF. Por ejemplo, un SF Schema puede describir los paquetes que se utilizan, la distribución f'isica de los componentes y como los distintos miembros de los equipos se relacionan con cada uno de estos aspectos. Un SF Schema se compone de Viewpoints que no son otra cosa que la descripción de todos los assets que intervienen en la generación de un aspecto del software que se desea desarrollar. Por ejemplo, un view point para la creación de un smart client podría ser la generación de la UI, en este caso el view point especificaría el conjunto de cosas necesarias para realizarlas, desde una clase base Form, diseñadores, DSL para especificar la navegabilidad entre formularios, herramientas de generación de algunos aspectos o plantillas, guias necesarias que intervienen es este punto, etc. Podría decirse que es la colección de todos los puntos de vista de un SF o el plano conceptual de este. Este plano tiene forma de arbol y cada rama trata un aspecto particular de la solución que a su vez se divide en otras ramas que los analizan desde otros puntos de vista. La definición de Viewpoint de la IEEE está en IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.

Software Factory Template

Una vez que tenemos los planos conceptuales del Software Factory que queremos construir debemos.... construirlo!! Es decir, ya sabemos que assets necesitaremos, como serán, donde intervendrán, como se relacionarán, etc. Ok, ahora hay que hacerlos. Esto es, crear los frameworks, las guias, los asistentes, los DSLs, procesos y todos los demás asstes descritos en el esquema he integrarlos (en lo posible) al IDE. Cada vez que se construye un nuevo producto, cada desarrollador puede (y debería) contribuir con el SF añadiendo sus plantillas, snippets, instructivos, frameworksy cualquier otro asset. Para más información acerca de estos últimos dos temas les recomiendo la edición número 9 de la revista The Architecture Journal y en especial el artículo de Tom Fuller "Fundamentos para los pilares de las Fábricas de Software".

Lo que me quedó en el tintero

Algo que me quedó en el tintero es el tema de las metodologias cuyo problema resumia como "o (son) muy formales o (son) uy ágiles". Greenfield y Short plantean (lo que a muchos nos parece obvio) que existen dos tendencias extremas con sus pros y contras. A diferencia de lo que uno podría esperar, Greenfield y Short no creen que una metodología más formal sea más MADURA, por el contrario, entienden que son inmaduras por extremistas.

En cuanto a los desarrolladores

Luego vamos a ver como distinguen entre "tipos" de desarrolladores (este "tipos" es mio, en realidad habla del valor de los desarrolladores y distingue entre ellos a aquellos que pueden construir los Software Factories y aquellos que los utilizan) y que importancia tienen estos dentro del proceso de desarrollo. Continuo planteando este tema porque cuantas veces hemos escuchado a gerentes de sistemas/Producers/Produc Manager/Team Leadres decir cosas como "Yo quiero/necesito poder sacar a uno (desarrollador) y poner a otro y que los proyectos continuen en marcha"?. La verdad creo que estas palabras (quiero/necesito) expresan un deseo. Sí, es una expresión de deseo! pero es un deseo genuino y entendible. Yo, en el lugar de esas personas querria exactamente lo mismo pero también entiendo que eso es un intento un poco necio de negar la realidad.

Como por ahí nombro los libros o cito los autores y no quiero poner palabras mias en sus bocas les recomiendo que los lean. Aunque en este punto es coveniente citarlos de manera textual.

"Unfortunately, the industry has a tendency to become overly prescriptive, assuming that developers are naive and uninformed, and attempting to use formal processes to prevent them from making mistakes by telling them what to build, how to build, and what skills are required to perform certain tasks."

El problema mayor que describe esta frase no es sobre lo de "ingenuos" o "ignorantes" sino que producen una infrautilización de las capacidades de las personas. Esto a veces constrasta con lo que se busca en un aspirante para un puesto como desarrollor, que esté muy capacitado, que pueda demostrar logros, que pueda plantear soluciones innovativas, que sea proactivo, etc.

Steve Jobs, fundador de Apple Computer, dice en una frase célebre:

"No tiene sentido contratar a personas inteligentes y después decirles lo que tienen que hacer. Nosotros contratamos a personas inteligentes para que nos digan qué tenemos que hacer."

Por otro lado, las metodologías ágiles no son la solución tampoco porque tienen sus problemas y no son aplicables a todas las realidades o mejor dicho, se aplican a un esquema muy particular de trabajo, gente, clientes, proyectos y demás.

Que solución se plantea? Ahí viene:

Process Framework

La solución planteada no sorprende a nadie. La clave es preservar la agilidad mientras se mantiene la posibilidad de escalar la complejidad introducida por el tamaño y la distribución geográfica de los proyectos. Lo verdaderamente importantes es como esta posibilidad va tomando forma real mediante la implementación del paradigma de Software Factories.

Los autores siguen diciendo que el problema de las metodologias formales es que son demasiado abstractas en el sentido que para poder utilizarse deben ser tailorizadas a cada proyecto o necesidad particular. La idea detrás de esta crítica, que no lo es tal, es tailorizar los procesos a una familia de productos concreta.

Es decir, enfocar los procesos hacia las tareas puntuales de todo el ciclo de vida de una familia de productos (o product line -este concepto es importantísimo y lo explicaré mas aelante). Así, por ejemplo, debería por cada actividad facilitarse los recursos necesarios como wikis, links a documentación importante (pero facilmente accesible y no en un archivo de Word o Excel que sabe dios donde está o que se tarda más en abrirse que en buscarlo por otros medios), información de contactos, guias específicas (instructivos) sobre como realizar tarea, checklists aplicables a la tarea, estilos de codificación, detalles de cual/es es/son el/los próximo/s paso/s en el desarrollo, herramientas, políticas, etc. Todo esto debería estar integrado al IDE y en lo posible automatizado.

Como hecho un tanto anecdótico debo resaltar que Microsoft provée el MSF for CMMI Process Improvement Guidance el cual abarca las prácticas relacionadas a las areas claves cubiertas por CMMI nivel 3.

Los Procces Frameworks se componen de dos conceptos: Constraint-Based Scheduling y Active Guidance.

Constraint-Based Scheduling se refiere a dividir (o abordar) un proceso en mini procesos para la construcción de artefactos o tangibles particulares. Cada uno de estos mini procesos define: los requerimientos para producir la salida, los recursos, los pasos a seguir y las decisiones claves que pueden requerirse en cada momento. Lo de Constraint hace referencia a que entre cada uno de los mini procesos existen precondiciones y postcondiciones que deben matchaer entre ellas y a las restricciones propias del scheduling del proyecto.

Active Guidance se refiere en parte a lo que ya mencioné arriba, que en cada paso de una actividad se brinde la información necesaria para realizarla. Esto debe ser estar facilmente accesible, facilmente entendible y en tiempo real, apoyado en asistentes, plantillas autodescriptivas y que asistan al desarrollador, recomendandole acciones, documentación y ejemplos a la vez que monitorizan el cumplimento de los constraints establecidos.

Me nombraron Coordinador del Grupo de Sistemas Operativos de la IEEE!!!

Sun, 26 Aug 2007 04:16:36 GMT

Estoy muy contento con la noticia. Por fin soy coordinador de algo como la gente. Pero lo mejor de lo mejor es que nadie me avisó y me vengo a enterar gracias a mi irrefrenable narcisismo.

Resulta que googleandome me encuentro en la página que la IEEE tiene hosteada en la UTN de Córdoba en la que si bien he participado en algunas oportunidades y he dictado cursos de C++ organizado por ellos, nunca pero nunca me nombraron coordinador de nada.

Mañana mismo voy a cobrar el sueldo que me deben estar adeudando pero bueno, una referencia más para poner en el curriculum! jajaja. No sé que pensar o mejor dicho, si sé que pensar pero lo dejo ahí.

Espero que como buenos amigos me feliciten todos eh.

Lucas Ontivero
Operating System Group - Coordinator

[Software Factories] Introducción (Parte 1)

Fri, 24 Aug 2007 20:12:01 GMT

Hace un tiempo que estoy estudiando sobre Software Factories, mas precisamente, leyendo los libros: "Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools" de Jack Greenfield y Keith Short y "Practical Software Factories in .NET: From Theory to Practice—A Primer, Reference, and Case Study" de Gunther Lenz y Christoph Wienands. Ademas de leer todo lo que diga "Software Factories" en google.

Según sitan todas las fuentes, y en especial referencia al CHAOS Report, son muy pocos los proyectos de desarrollo de software que se consideran exitosos (alrededor del 30%) mientras que el 50% tuvo problemas de irse del presupuesto, tiempo de entrega y calidad. La porción restante fueron cancelados durante el ciclo de vida del desarrollo. El informe le asigna una minúscula importancia a los aspectos técnicos aislados como causal de los fracasos en la terminación e implementación exitosa de los proyectos aunque es evidente que ellos se deben a la manera en que se construye el software, y esta es una tarea eminentemente técnica. Es decir, si se simplificara dramáticamente la tarea de desarrollo seguramente la calidad, la productividad, los costos y tiempos de entrega se dispararían a niveles mas deseables que los actuales. Y esto es un problema de "como se hace" (Técnica).

Haciendo una comparación entre nuestra industria y otras de diciplinas ingenieriles mas maduras como la mecánica, electrónica y/o civil, Jack Greenfield y Keith Short dicen que fallamos al desarrollar software porque:

Razón 1 - One-off development

Cada proyecto se construye desde CERO e independientemente de otros sistemas similares. Los Assets (no encuentro una palabra mejor pero llamemosles componentes o mejor "tangibles") de estos sistemas no se crearon con el prop'osito de ser reutilizables. Esto encuentra varias razones:

hacer algo reutilizable requiere una IDENTIFICACION y ANALISIS de aquellas características comunes que puedan servir en un futuro cercano.
hacer algo reutilizable requiere que se DISEÑE con ese propósito en mente,
que se CONSTRUYA,
que se VERSIONES y MANTENGA,
que se DOCUMENTE (si no se documenta no es reutilizable por más que se cumpla todo lo anterior)

En otras palabras, hacer un tangible reutilizable es una inversión que hay que analizar.

Una de las formas de reutilización mas común en la actualidad es la dupla copy/paste, que desde mi punto de vista es la peor práctica de todas. Mejores resultados tenemos en la reutilización de componentes en binario o ILs como el Framework .NET, Componentes COM/Activex, los paquetes Java y las .lib en C sin perjuicio de crear nuestros propios binarios para reutilizarlos en esa forma.

Otro problema con la reutilización de fuentes es que el código es mas facil escribirlo que leerlo y eso hace que al leerlo, al no tener la documentación de este (casi nunca la tenemos), al no estar pensado para reutilizarlos facilmente y al no sernos "agradable" la "estética" del código, se nos cruce el pensamiento "Por dios! quien hizo esta porquería!?. Hay que hacerlo de nuevo". Esto es reinventar la rueda. Más allá del hecho de si servía o no, el tema es que habrá dos fuentes con multitud de características similares que bien podrian haberse hecho de una manera mas inteligente.

Razón 2 - Monolithic systems and increasing systems complexity
Los sistemas monolíticos son aquellos en los que sus componentes están fuertemente acoplados y no permiten tratarlos de manera sistemática porque un cambio en una parte produce la necesidad de hacer cambios en muchos de los componentes con los que se relaciona. El problema se observa con mayor claridad al tener que mantener, extender y adaptar el sistema a los cambios en los requerimientos post

implementación. Como contrapartida de los sistemas monolíticos tenemos los sistemas pluggeables.

Razón 2 - Working at low levels of abstraction
Este tema ya lo toqué en otros post sobre Domain Specific Language y NBusiness. Veamos como se desarrolla un software: Nos llegan los requerimientos de nuestro Program Manager/Team Leader y, despues de las reuniones de rutina, en que nos comentan hasta como se peina el cliente, empezamos con un pequeño brainstorn personal o con algún grosso amigo (hoy en dia esto lo hacemos casi desde CERO).

Cuando tenemoslas ideas y los documentos y llega la hora de hecharle mano al código (en este caso ejemplifico con c# pero podría ser cualquier lenguaje: VB, Java, SQL, XSLT, etc) comenzamos así:

using System.IO;
:
:

public class Product
{
    private string productName;
    public string Name
    { get {...} set {...} }

La pregunta es: puede ser esta la manera más natural de especificar el comportamiento y las cualidades de un componente de catálogo de productos? No estaremos hilando demasiado fino? Es más, me atrevo a preguntar: no debería estar hecho ya por alguien más o es que acaso nadie nunca escribió un producto que trabajase con productos?. Está bien, acepto que para algo así falta mucho, que habria que estandarizar bloques de construcción y un montón de cosas más pero la pregunta inicial sigue en pie. Son los lenguajes de propósito general los adecuados para todos los casos particulares? Claro que no. Aquí es donde entran, entre otras cosas, los DSLs o Lenguajes específicos de un dominio.

Aclaro, como desarrollador siempre pienso en función de lenguajes de programación pero bien podrían ser lenguajes de empaquetado, de testings, de validación, de especificación de requerimientos o cualquier otro.

Como alternativa a este bajo nivel de abstracción se analizan una variedad inmensa de cosas, entre las que ya las DSL, como Model Driver development (MDD) y Model Driver Architectural (MDA). Todos con mayor o menor grado de relación con UML y su posibilidad, gracias a XML o mas precisamente XMI, de automatizar una gran cantidad de tareas de desarrollo como así también elevar el nivel de abstracción.

Este es sin dudas el tema mas interesante si se lo estudia en forma aisladas y es el que mas material tiene escrito (tanto que te cansa).

Razón 3 - Process immaturity
Alguién podrá pensar: "ah no!, ese problema nosotros no lo tenemos. Tenemos CMMI! jajaja". Bueno, la verdad es que esto es para vos también y se resume así: o demasiado formal o demasiado agil.

Veamos por qué:

Los mas agiles:
Ventajas:

responden bien ante los cambios
comunicación en lugar de documentación
desarrollo y corrida en iteraciones pequeñas
los requerimientos se validan continuamente gracias a una comunicación constante con el cliente
continuamente se hace refactorin de las aplicaciones

Fallan:

imposible de escalar a grandes proyectos o muy complejos.
escaza documentación de la arquitectura crean problemas de soporte e integración
equipos distribuidos

Los mas formales:
ventajas:

tienen perfectamente establecidos los roles, artefactos y actividades activities
hacen énfasis en los requerimientos, análisis y diseño
la arquitectura se documenta con modelos

Fallan:

Responden lento a los cambios
perfectamente escalables a grandes proyectos o proyectos complejos

Existen muchas discuciones en torno a este tema. Cual es mejor?. La verdad es que en la práctica, esta elección muchas veces no es posible. Hay muchos aspectos a tener en cuenta además de los arriba mencionados que entran en juego y que condicionan una libre elección de la metodología. Por ejemplo: Si tengo grupos pequeños de gente muy capacitada (que no se me van a ir el mes que viene), expertos en temas puntuales, con experiencia, trabajando juntos, con clientes que confian en nosotros a los cuales podemos llamar o ver en cualquier momento, con proyectos relativamente pequeños; bueno, agil es la respuesta. Ahora, si tenemos clientes con distintos usos horarios, idiomas, o nuestro cliente es un gobierno extranjero, que no nos conoce, que quiere mas que una estimación un presupuesto ajustado, que puede hacernos una auditoría, si cotizamos en bolsa, si tenemos proyectos muy grandes, con mucha gente (que se nos va el mes que viene), o somos una pyme de una provincia del interior de un remoto pais que no conoce nadie llamado Argentina y queremos salir a vender nuestros productos por el mundo: bueno, no queda otra, entrá a http://www.sei.cmu.edu/.

Razón 4 - Rapidly growing demand for software systems
No solo que se incrementó la demanda de software sino que además va creciendo el tamaño y la complejidad del mismo. Los clientes de hoy solicitan funcionalidades o características que hace 2 o 3 años atras ni se les hubiera cruzado por la cabeza. Así que no piensen solo estriban siguiendo la metodología HP (Horse Programming)

Bueno, esto ya está mas largo que un post de Diegum prometo seguir con este tema en próximos post.

Lucas Ontivero

Simpsonizate

Tue, 07 Aug 2007 03:27:37 GMT

Hoy leí una entrada del blog de Gustavo Bonansea en el que él se simpsoniza así que acá voy yo.

La verdad es que estoy bastante parecido o al menos eso creo, jajaja. La página para convertirte en un personaje más es http://simpsonizeme.com/, eso sí, mejor si tenes alguien al lado que te diga "nooo, vos sos mas pelado" o "tenés los ojos un poo mas chiquitos".

Saludos.

"Vení que te queremos mucho" y el flujo del personal

Thu, 31 May 2007 20:13:59 GMT

Es curioso, a diario observo como va rotando el personal mas calificado de las empresas de una manera que a veces parece un algoritmo de cubeta con goteo (se van llendo de a poquito) y otras veces me recuerda al de cubeta con ficha (se van en lotes :) ) generando una implosión de la nómina de una empresa. Este último caso ocurre por alguna situación especial que rebalsa el vaso.

Leyendo sobre filosofía de la calidad en una monografia sobre los 14 puntos de Deming leo lo siguiente:

"Hay zonas en donde los empleados viven rotando entre las diferentes empresas , inclusive escuchamos un caso, que cuando cambia una persona, sus amigos se van con ésta. Es tan poco atractivo permanecer en una empresa, hay tan poco estímulo. Realmente muchos ven a sus colaboradores como "enemigos pagados", desaprovechando el potencial que tienen para lograr la transformación que las empresas necesitan. Frecuentemente escuchamos casi como súplica, "ya sabe, si conoce de algo para mi, me avisa". Todos están dispuestos a cambiar de empresa. No se escuchan las sugerencias, no se les involucra en la solución de problemas."

Otro síntoma de esto es que cuando algún compañero avisa que se va porque ha conseguido otro trabajo todo el mundo lo felicita. Sin dudas, el artículo facilitado por Carlos Zanini, "Las empresas no están preparadas para el mercado laboral del futuro", dice un par de grandes verdades y sugiere a las empresas "procurar un marco más libre para sus empleados" que como decia Job Steven (Apple):

"Contrato gente inteligente para que me diga qué y cómo tengo que hacer, no para decírselos a ellos"

Y es sentido común no?

Aunque los principales factores, a mi entender, son la falta de ilusión, expectativas y mala administración que genera la inmensa mayoria de males, existen también otros factores de entre los cuales rescato al "contrato individual". La clásica "¿cuales son tus pretenciones económicas?" o "la empresa tiene una oferta para hacerte..". Si bien esto logra bajar el costo inicial del empleado, es como empezar con el pie izquierdo porque genera un montón de problemas. Es una especie de causa de todos los males que propicia la aparición de envidias, la existencia de vivos y tontos, injusticia por cuanto no se respeta el principio de igual paga a igual trabajo, malestar por el hecho de quien entra último entra mejor y hasta broncas al tener que capacitar a gente inexperta que ingresa con mejor salario que tu que llevas años en esa empresa. Esto también genera incomodidad a la hora de reclamar un aumento por lo que muchos prefieren escuchar otras ofertas.

Este y otros asuntos como los premios, bonos, incentivos, presentismos y otras yerbas son producto de la conjunción de varios aspectos:

Una concepción clasista de los puestos de trabajos aun en organizaciones colegiadas,
Un estilo de administración centrado exclusivamente en el costo evidente e inmediato de personal,
La falta de conocimientos de administración científica (basada en número de costos finales) con respecto a la rotación del personal, ¿cuanto cuesta?
Falta de experiencia, estudios, estilos de administración y demás conocimientos necesarios para la creación y administración de organizaciones basadas en las personas como ejes generadores de innovación y valor.

Todas los tipos de poder, poder coercitivo, de información, de premios, de relación (o amistad) y cualquier otro tipo dentro de las empresas deben dejar lugar al poder de experto y normativo. Incentivar la innovación pero de verdad, la autonomia, el trabajo en grupo pero de la boca para adentro también, la igualdad, las relaciones sin barreras horizontales ni verticales, igualmente la comunicación en todos los sentidos, en resumen seria algo así como crear un grupo sin escollos en donde la sinergia surje de manera natural y en donde la gente quiera trabajar, permanecer y sentirse orgullosa de pertenecer y de hacer para ella.

Lean algo de Deming por Dios!!

Saludos