Lucas Ontivero

Cita

Patron Factory Method 1

  
Video: Patron Factory Method 1

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

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.

• 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

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

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

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");
        }
    }
}

• 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

[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

 

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

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

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

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

 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 

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.

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.

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

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.

Hace algunos meses cenaba en casa con un geólogo, su mujer e hijo, mi novia y una pareja de amigos de ella, en un momento comenzamos a hablar de mi profesión por algunas preguntas y comentarios que se estaban haciendo y así que despues de explicar mas o menos los pasos generales de una migración de sistemas y todos sus pormenores, la complejidad que conllevan y el problema de que lo mejor que puede resultar es que todo siga funcionando igual que antes sin errores ni nada raro, el geólogo, sin pelos en la lengua, me dice "esa es la clásica respuesta de los informáticos para generarse constante trabajo". Lo llamativo es que todos en la reunión estaban de acuerdo. Nunca me habia puesto a pensar acerca de los prejuicios que sufrimos los informáticos pero son verdaderamente muchos. Acá van algunos:

Se generan el trabajo. Es muy común dado que la gente no tiene idea de lo que hacemos y en muchos casos creen que nuestra trabajo se basa en "estar" frente a una computadora.

Son nerds, computines, ñoños. Son términos para definir a los informáticos mas estudiosos o profesionales. Por ejemplo, leí por ahí la frase "los nerds que inventaron google" como si de tontos se tratase aunque esos nerds sean muy ricos e influyentes. Esto en un extremo de la interpretación quiere decir que son personas que no reciben luz solar, en su mayoria gordos asexuados fanáticos de los juegos por computadores y con escasísima vida social o tal vez con un poco de visa social "virtual".

Son mercenarios. También es muy común entre todos los que ocupan cargos administrativos (lease: accesorios) en las consultoras informáticas. Esta frase hace referencia a que los informáticos en cuanto ven la posibilidad de ganar un 20% o 30% mas que en su actual trabajo cambian por el mejor pago.

Creen tener coronitas. El informático cree ser mejor que el resto de la planta, mejor que los torneros, los guardias y hasta los capataces. Siempre andan flojos, con excusas y creen tener derecho a llegar e irse a la hora que quieren y siempre aluden a su "trabajo intelectual" y "altamente especializado".

Estos son solo algunos de los que he escuchado. A medida que viva otros mas los iré posteando.

Saludos.

Hoy leyendo meneame.net me doy con este título: "La propiedad intelectual es un gran freno para el avance de Internet". Una enorme verdad dado los casos principales de la industria de la música, películas y libros. Recientemente en un programa de Libertad Digital TV titulado "el canon digital" en el que se trata el "gravar por grabar".  n ese programa se explica como estas industrias recurren a cualquier medio (apoyados en sus influencias con los gobierno) para intentar perpetrar un modelo de negocios agonizante. Otra reciente es la noticia de que Microsoft va a demandar a diestra y siniestra a todos los que toquen una distribución de Linux. Ni que hablar de los contenidos regionalizados que analiza Enrique Dans en los que uno no pude modificar un equipo que es de su propiedad!

Saludos.

Poco. Esa es la respuesta sintética por si no queres seguir leyendo. Ahora, si te interese te lo comento con gráficos. Para ampliar las imágenes hay que hacer click sobre ellas.

Argentina ínvirtió entre 1996 y 2004 un promedio del 0.42% de PBI en I+D posicinándose bastante por encima de la media latinoamericana pero increiblemente lejos de los paises desarrollados que mas apuestan a la generación de conocimientos. Japón, Estados Unidos, Alemania y Francia pertenecen a este último grupo de paises investigadores que destinan mas del 2% de sus PBI a la investigación. Suecia es un caso único, destina casi el 4%.

Otro tema son los resultados obtenidos de esas inversiones, cosa que se refleja en la cantidad de investigadores por cada 1000 habitantes, los ingresos percibidos por los investigadores y la cantidad y calidad de las publicaciones y patentes registradas. En este punto cabe destacar que Agentina, si bien invierte menos que México, Chile y Brasil, posee muchos mas investigadores cada 1000 habitantes que estos y está número. Esto habla a las claras (y por las dudas está el gráfico 3) de que es el pais con menor gasto por investigador de entre los que comparación la fuente (secyt) y tiene un coeficiente de invención (patentes solicitadas por residentes cada 100 000 habitantes) que es también menor a paises con mucho menos investgadores como chile y brasil. Este dato habla de la calidad de los investigadores (o mejor dicho del sistema y de las inversiones en investigación) puesto que con mas del doble de investigadores (cada 1000 hab.) que brasil, este triplica el coeficiente de invención de Argentina. 

Otros datos importantes son:

• la escasa inversión que realizan las empresas privadas en I+D en Argentina comparado con paises como Brasil en donde la inversión privada duplica a la Argentina.
• El gasto Argentino en I+D viene creciendo de manera incipida pero constante desde el 2001.
• El grueso del gasto (66%) es en concepto de personal lo que deja ver la falta de materiales para la investigación

Fuentes:
Secretaría de Ciencia, Tecnología e Innovación Productiva (secyt) 
Red de Incicadores de Ciencia y Tecnología (ricyt)
Rannís – The Icelandic Centre for Research

Escribo este post un poco como respuesta al de Gustavo Bonansea pero sobre todo para dejar mis conclusiones en cuanto a la confección de un curriculum vitae o mas bien al "tunning" del mismo. Por tunning no quiero decir ni inflarlo, cosa que por lo que veo a diario no ocurre en forma sistemática, ni mucho menos mentir que es mas o menos lo mismo. Lo que quiero decir con "tunning" es modificar el curriculum de modo tal de volverlo lo mas interesante posible para quienes lo reciben.   Dado que el objetivo del CVs es lograr que te llamen, será entonces efectivo en la medida que logre ese cometido. Para eso debe ser efectivo Visualmente.
Debe tener cierto impacto visual sobre el resto de los CVs que tendrá sobre su escritorio quien deba seleccionar al candidato. Debe tener una estética en "onda" con la imagen de la empresa. Debe ser facil de leer, de diferenciar y sobre todo debe ser breve. En cuanto a la foto, si vas a tener trato con cliente pon una con saco si vas a ser un nerd de laboratorio entonces de remera puede estar bien.

En la web

Buscando un poco por la web me dí con un sinnúmero de artículos, con la clásica retórica empresarial, que recomiendan cosas como investigar a la empresa, investigar el puesto, sonreir mientras redactas, elegir tu foto mas seria, terminar cada parrafo en forma objetiva y positiva, redactar una carta, no olvidar mencionar tu entusiasmo y capacidades grupales, etc.....

También encontré algo sobre que cosas no poner, entre ellas los períodos de tiempo de inactividad a los que hace referencia Gustavo o, hice el jardin de infantes en "el solcito gruñón" por nombrar solo algunas. No importa cuan importante creas que sean estas cosas, no debes ponerlas!!!. Recientemente revisé varios CVs con los siguientes logros académicos: "fui segundo escolta en la primaria" y "curso de instalación de sistema operativo CPM - 1977", el problema es el mismo, no agregar nada al igual que poner cosas personales como "me apasiona el origami, la natación y la literatura francesa".

Premisas

No es un concurso que gana quien mas cosas pone

Recuerdo que Carlos Zanini, de quien he aprendido mucho de este "arte", me dijo en una oportunidad: "Lucas pasame tu curriculum pero por Dios sacale lo de DOS 4, DBase III+ y Assembler!", en ese momento no lo entendí.

No es un concurso para ver quien es el que mas sabe de un tema 

Salvo en el ámbito académico y de investigación, en donde los antecedentes son determinantes, quien mas conoce de un tema no tiene una gran ventaja sobre el resto de los candidatos.

Si no agrega valor, lo resta

Cuando el entrevistador leer el CV, cada item o párrafo que observa que no está en relación a lo que él está buscando te alejan del puesto en vez de acercarte. Por eso, todo lo que observe en tu CV debe resultarle de interes y estar en perfecta concordancia con la búsqueda. Es necesario lograr esto aunque debas dejar un hueco de los 18 meses que trabajaste en rentas o en el cyber.

El que se sobrevalora pierde

Es muy humano el creer que sos el mejor, al fin y al cabo todo el mundo está convencido de ello, pero desgraciadamente no lo sos! Esto evita que logres diferenciarte y sintonizar con quien evaluará tu CV porque seguramente el también cree ser el mejor.

En cuanto al orden

Las cosas que llevan 5 o mas años en lograrlas van primero como por ejemplo títulos universitarios e ingles. Las que llevan menos tiempo son las que les siguen y deben ponerse en un orden conveniente para captar el interes. Por último, ese seminario de 45 minutos al que asististe en una ferias de informática, si no viene como anillo al dedo ni lo pongas.

Luego la experiencia laboral y por último tenes unos pocos renglones para lucir alguna otra cosa.

Flexibilidad, audacia y marketing

Desde esta perspectiva, un curriculum es un folleto publicitario como los que se reparten en las elecciones por lo que todo lo que vale en el marketing te sirve. Por ejemplo, en mi último CV se me ocurrió pegar unos screenshots de mis hobbies al mejor estilo diseñador gráfico y funcionó de maravillas, es mas, las preguntas fueron casi por completo dirigidas a esos trabajos por lo que nunca tuve que sudar con una pregunta sino mas bien por las respuestas eran en ingles.

Trampas para evitar mentir

Si no sabes muy bien ingles no pongas "ingles - lecto comprensión" o "Nivel intermedio". Todo el mundo sabe que esto significa que no tenes buen nivel de ese idioma. Simplemente no pongas nada.

Si en algún momento no trabajaste en relación de dependencia y le tenes miedo a que vean alguna herejia en eso, no pongas las fechas con meses, solo poné los años 2002-2003, 2004-2005, 2006-actualidad.

Mantené el objetivo claro

Por último recordá que no se trata de crear expectativas sino interes. Que te llamen para conocerte y que se acuerden de vos. Para ver si eres bueno o no harán entrevistas, exámenes, reuniones con el lider técnico y hasta tests psicotécnicos.

Ya sé que nadie está muy de acuerdo con esto salvo uno o dos entre los que me encuentro yo. :)

Hace poco vi este video en youtube sobre como podrían ser las futuras búsquedas en Google con un "poquito" de IA. Luego de verlo pensé que era una total y absoluta tonteria ya que el video me mostraba como podia uno conseguir una imagen de una porción de pizza que no estuviese sujeta a copyright en poco mas de 2 minutos!!!. Bueno, para mi eso me pareció muchísimo tiempo y además la forma en que se hacian las búsquedas también me pareció absurdo porque quien podría ser tan tonto de poner "I am looking for a piza please" en el google?.

La verdad es que me equivoqué y si no miren algunas búsquedas por las que llegan a mi blog:

• como averiguo de cuantos bits es mi pc?
• codigo de un contador de una factura en vbnet
• codigo de la serie de lucas(c++)
• cuales son las partes del patrón composite

Estas son cuatro búsquedas que veo en el log de visitas de hoy, y en dias anteriores (que no las puedo ver) han habido otras por el estilo. Ahora, salvo la que listo en tercera posición que ni google ni yo ni vos ni dios sabe que estará buscando esa persona, las demás son perfectamente entendibles pero google los mandó a mi blog que es lo mismo que mandarlos a la m#$%&")!$%..

Cambié de parecer y mas allá de si es posible o no llegar a esto en el corto plazo creo que es la dirección a seguir. Sin dudas!

Saludos