La  idea de este post surgió de casualidad, por una discusión que nada que ver -o, en realidad, aparentemente nada que ver- en el Foro de Arquitectura MSDN

El que abría el debate preguntaba si era objetable adoptar como estándar de constructores de clase la llamada al constructor base, es decir el clásico
 

    public class Pepe : Juan
    {
        // ... campos y propiedades de la clase

 
        public Pepe() : base()   // llamada explícita al constructor por defecto de la clase base 
        {
            // ... lógica de inicialización de la clase
        }
 
        // ... sigue la definición de constructores y métodos de la clase
    }

 
A él lo motivaba el hecho de que, al explicitar la llamada al constructor base sin parámetros (algo que de todas formas ocurrirá si no se explicita otra llamada a constructores de la clase base, los programadores iban a estar más conscientes de lo que iba a ocurrir entre bambalinas

La discusión siguió y no viene al caso reproducirla (está disponible haciendo click acá si te interesa), pero la parte que yo quiero destacar, la que me pareció seria, es que -aunque el autor no necesariamente afirmaba pensar eso- todas las clases heredables tendrían que incluir el constructor por defecto (así se llama al constructor sin parámetros)

El problema de que una norma de buena programación conlleve a que todas las clases -al menos las heredables- lleven un constructor por defecto choca de frente con la posibilidad de tener clases inmutables (immutable classes)

Qué son estas clases, para qué podríamos quererlas? Te lo voy a ilustrar con un ejemplo:

Imaginate que estás trabajando en un proyecto grande donde tu equipo se encarga de codificar una parte y otros equipos se hacen cargo de otras partes, etc

Suponete que tu equipo va a generar una API financiera que otros equipos van a usar, pero sin abusar (attenti, ahora te explico). Tu API, a grandes rasgos, consiste en una clase principal llamada Cotizador, con un método Cotizar() de las siguientes características
 

    public class Cotizador
    {
        // ... campos, propiedades y constructores de la clase

        public ICotizacion Cotizar(double monto, 
            DateTime fechaPrestamo, 
            DateTime fechaPrimerPago,
            int meses,
            double tasa)
        {
            ICotizacion cotizacion;

            // ... sigue la implementación, que en base a los argumentos
            // estima las distintas cuotas, con sus respectivas fechas de
            // vencimiento y el capital e interés cancelados en cada una

            return cotizacion;
        }



        // ... otros métodos de la clase
    }

 
Concretamente lo que Cotizador.Cotizar() devuelve es una interfaz, ICotizacion, con las siguientes propiedades read-only (en seguida veremos por qué)
 

    public interface ICotizacion
    { 
        int Cuotas { get; }
        double Tasa { get; }
        double ValorCuota { get; }
        DateTime InicioPrestamo { get; }
        DateTime FinPrestamo { get; }
        ICuota this[int index] { get; }
    }

    public interface ICuota
    {
        DateTime FechaVencimiento { get; }
        double CapitalCancelado { get; }
        double InteresCancelado { get; }
    }

 
Te decía que las propiedades de ICotizacion y de ICuota deben ser de lectura unicamente porque si se pudieran cambiar una vez que el cotizador las creó, cualquier otra clase puede acceder a sus propiedades, falseando los resultados originales
 

En este punto no falta quien me pueda tildar de exagerado, de que alcanza con avisarle a los desarrolladores que no deben cambiar los valores de una ICotizacion y sus ICuota una vez que fue creada y ya está. Pero mi punto no es ése

Sin ser peronista, quiero citar una frase de Perón que decía "los hombres son todos buenos, pero si se los vigila son mejores"

En proyectos grandes donde la gente viene y va, unos pasan, otros quedan, esas "puertas traseras" que uno va dejando en el código son las vulnerabilidades que pueden a la postre ser explotadas por quienes se propongan cometer fraudes

Hay que salir al cruce de las mismas sin caer en tontos positivismos de "acá nunca va a pasar eso"

Sólo para curiosos, incluyo una posible implementación de ICotizacion, en la que preferí usar struct en lugar de class, que me almacena en forma contigua en memoria el contenido de una cotización en forma consecutiva (si en cambio fuera una clase, lo que se almacenaría en forma contigua serían las referencias a sus campos. Fuera de eso no vas a encontrar nada paranormal, excepto quizás el modificador de acceso del constructor de la clase (internal en lugar de public, ahora te sigo contando qué es eso)
 

    public struct Cotizacion : ICotizacion
    {
        // campos privados
        private int cuotas; 
        private double tasa; 
        private double valorCuota;
        private ICuota[] vectorCuotas;

        // propiedades
        public int Cuotas { get { return cuotas; } } 
        public double Tasa { get { return tasa; } } 
        public double ValorCuota { get { return valorCuota; } } 
        
        public DateTime InicioPrestamo
        {
            get { return this[0].FechaVencimiento; }
        }

        public DateTime FinPrestamo
        {
            get { return this[cuotas-1].FechaVencimiento; }
        }

        public ICuota this[int index]
        {
            get { return vectorCuotas[index]; }
        }

        // constructor
        internal Cotizacion(int cuotas,
            double valorCuota,
            ICuota[] vectorCuotas)
        {
            this.cuotas = cuotas;
            this.valorCuota = valorCuota;
            this.vectorCuota = vectorCuota;
        }
    }

 
Quiero que notes que en la estructura Cotizacion los valores de sus propiedades públicas sólo se pueden asignar al momento de construirla. Una vez creada ya no hay forma de alterarlos

Por esto se dice que Cotizacion es inmutable (immutable). Se mira pero no se toca. El responsable de la clase (o de la lógica de negocio de este módulo) puede quedarse tranquilo de que, una vez que Cotizador.Cotizar() devolvió una instancia de Cotizacion, al menos esa instancia no va a poder ser manipulada o adulterada en ninguna forma 
 

 
Lo de internal es algo tan revolucionario como polémico. Ese modificador de acceso indica que el constructor es público... dentro del mismo ensamblado. Con eso nos prevenimos de que nadie por fuera de Cotizador.Cotizar() crée una instancia de Cotizacion asignándole sus argumentos a las propiedades, y luego la cambie por la que nuestro método le había devuelto  

La polémica se inicia cuando, como requisito, se pide poder persistir una Cotizacion (algo que seguramente ocurrirá). O más precisamente, la polémica se inicia cuando haya que recuperar una Cotizacion que se había persistido ya que, si la arquitectura de la aplicación separa la capa de acceso a datos en otro ensamblado... Cómo construir desde aquella capa las instancias recuperadas de cotizaciones?

Entonces mejor lo volvemos a dejar público al constructor, pero ahora de nuevo corremos el riesgo de que alquien, en lugar de llamar al Cotizador, se crée una Cotizacion a mano y nos la haga pasar por buena!

Parece el cubo mágico, no? Para armar una cara tenés que desarmar lo que tengas hecho de las otras. Cómo salir de aquí?

Yo en verdad opté por dejar de lado el internal, volviendo a contar con un acceso público al constructor de Cotizacion pero impidiendo, vía Code-Access Security (CAS), que desde ningún ensamblado se lo pueda llamar, excepto el del módulo Cotizador y el del DAO de ICotizacion. Yo mostré CAS en acción en el webcast sobre Arquitecturas Seguras

Si, como parecía plantear el participante del foro al principio, las clases tuvieran que tener un constructor por defecto (esto es, sin argumentos) de esa manera estaríamos obligados a definir las propiedades como lectura/escritura para poder asignar un valor inicial. Pero una vez que las propiedades son writables (sí: accesibles para escritura), el riesgo de tampering está presente

Si bien la inmutabilidad (immutability) juega un rol clave en evitar tampering, debe ser aplicada junto a otras medidas que refuercen la barrera contra la violación de precinto a lo largo de todo el ciclo de vida de una instancia 
 

Un par de datos más sobre inmutabilidad:

• Por la forma en que las interfaces y las implementaciones del ejemplo fueron definidas, no es posible reimplementar la interfaz redefiniendo propiedades mediante el agregado de set(), ya que no compila si la interfaz implementada no tenía tal modificador. Del mismo modo, la estructura Cotizacion no se puede extender añadiendo setters a sus propiedades read-only, ya que éstas no tienen el modificador virtual que explicita la habilitación de sobre escritura. No obstante, no es mala idea que ciertos procesos delicados que van a trabajar con una Cotizacion recibida como argumento, se garanticen que su tipo se corresponda a su nombre fuertemente firmado (y no, por caso, una posible reimplementación trucha de ICotizacion)
• El otro beneficio que tienen las clases inmutables es que, en escenarios de multitarea y concurrencia, al ser sus propiedades invariables no es necesario sincronizar el acceso a sus miembros mediante el comando lock(). Por consiguiente, serían un foco menos de generación de contención de hilos

Será hasta la próxima (me voy al cobán a ver si me aprobaron el crédito)

 Actualmente  se viene dando algo curioso en ciertas distribuciones de las conocidas como market share (reparto del mercado), ya que ciertos nichos parecieron durante años tener dueños prefijados, y sin embargo ahora eso está en franca discusión. Concretamente me refiero a lo que está pasando en los segmentos de los clientes web y sus respectivos servidores

Por un lado, es innegable el avance de Firefox sobre el -por ahora- líder Internet Explorer

En estos últimos doce meses se podría decir que lo que perdió uno lo ganó el otro
(Fuente: Market Share)
 

Un detalle no menor es que hacia el año 2004,Internet Explorer gozaba de un 91.16% (siempre según Market Share). Qué está pasando que el drenaje no se corta? La explicación más racional es el surgimiento, hacia finales de 2004, del potente rival que se va comiendo una porción cada vez mayor de la pizza. En efecto, Firefox venía con capacidades no disponibles en el Internet Explorer de aquellos días, como por ejemplo la habilidad para suscribirse a contenidos RSS(algo que, en realidad, a Doña Rosa le pasó por al lado) y sobre todo la habilidad de manejar navegación múltiple mediante pestañas individuales, todo en una misma ventana (algo que incluso Doña Rosa notó y celebró). Finalmente se podría mencionar como razón la percepción de seguridad que en general rodea a todo el soft que no es de Microsoft (o, dicho en otras palabras, la percepción de inseguridad que rodea a todo el soft que es de Microsoft, aunque esta percepción negativa se ha reducido bastante ultimamente)

En concreto, Firefox presentaba innovación verdadera frente a un obsoleto Internet Explorer 6.0 datado en el año 2002 y con planes de una renovación alejada en el tiempo. Cuando el drenaje comenzaba a hacerse demasiado evidente, se adelantó, hacia enero del 2006, la beta 2 de la versión 7 cuya fecha de liberación también se anticipó para finales de ese mismo año (más de cuatro años entre una versión y otra, hmmm...)

Esta beta 2 era pública (comparada con la Beta 1, liberada en forma restringida seis meses antes) y también posibilitaba suscripción RSS, navegación en múltiples pestañas así como también soporte AJAX nativo (algo que hasta el momento venía siendo soportado mediante un componente ActiveX)

Aunque Abril pasado fue el punto más bajo y a partir de allí la situación se amesetó al menos hasta hoy, Firefox viene con mucha fuerza y dispuesto a que la distribución de la torta no esté tan desbalanceada. Desde el punto de vista del consumidor, esta competencia es más que provechosa. Incluso para el que prefirió no moverse de IE y migró a su versión actual, hoy tiene un navegador que ofrece una experiencia de usuario mejorada. Por consiguiente, bienvenida la competencia

Una lectura alternativa del éxito del Firefox con que me he topado es que, por ser freeware, es inmediatamente más atractivo que su rival. No tiene mucho asidero esa versión ya que Windows está presente aún en más del 90% de las compus de escritorio (es decir, las que no son exclusivamente servidores). Por lo tanto, ese más del 90% eligió un sistema operativo pago que incluye el navegador Internet Explorer. Entendería que instalen Firefox por preferencia personal en cuanto a lo que Firefox brinda. En cambio, me parecería impensable que lo adopten para ahorrarse unos mangos (de qué? Si al pagar el sistema operativo el browser les vino de arriba)

Entonces, claro, ahora toca la parte que se para alguno y me dice "bueno, pero y los que usan Linux!? Esos prefirieron Firefox como parte de un pack completamente freeware". Los linuxeros? Hablamos de los que usan Linux como sistema operativo de su compu (o sea, no los servidores Linux dedicados)? Según Market Share, el uso de Linux como sistema operativo de escritorio fue de un 0.75% al término de Julio. Muy por detrás de MacOS, que cerró el mes con un casi 6% Dicho sea de paso, venga la siguiente observación: MacOS es pago. Precio de lista u$129 (ciento veintinueve dólares). Es más barato que Vista, cuya versión más básica, no el upgrade sino el instalador full, vale u$199 (ciento noventa y nueve dólares). Lo real es que MacOS hoy puede correr en arquitectura Intel pero los equipos siguen siendo Mac. El precio de una notebook Mac arranca de los u$1099 (mil noventa y nueve dólares) y de ahí para arriba. Notebooks con Windows Vista incluído tenemos una variedad mucho más amplia, partiendo de los u$550 (quinientos cincuenta dólares) y de ahí para arribeños

La conclusión que quiero sacar es que el principal factor a favor de Linux como desktop ("es freeware") no parece estar siendo tenido en cuenta si menos del 1% optó por él

Normalmente es en esta parte en la que se vuelve a parar el que me sacó el tema de Linux y me dice "okay, admitido que Linux si bien tiene una arquitectura abierta y que permite que cada uno se arme la película que quiera, a la mayoría de los usuarios eso los confunde porque prefieren algo ya hecho y listo para usar. Pero no obstante Linux tiene su potencial en la seguridad y la estabilidad y es por eso que la mayoría de los servidores web corren alguna combinación de Linux y Apache"

Bueno, desde hace un tiempo a esta parte que la combinación Windows Server más su servidor web Internet Information Services (IIS) viene recuperando parte del considerable terreno que el servidor web Apache ha venido perdiendo

Barranca abajo: en los últimos doce meses Apache perdió un 10%. Parte de esa caída la
embolsó Internet Information Services (Fuente: Netcraft)

El crecimiento de Internet Information Services representaría un doble triunfo ya que Apache está especialmente desplegado sobre plataforma Linux, lo que viene estando confirmado por otros sondeos que muestran a Windows Server creciendo más rápido que el sistema operativo del pingüinito (esto no de ahora: ya se comentó algo el año pasado y también el anterior). Volviendo a Apache, Netcraft sugiere que de seguir las tendencias actuales, en algún momento del 2008 IIS lo alcanza (verlo en http://adtmag.com/article.aspx?id=21092). De todas maneras, pase o no, la competencia es interesante y sana

De nuevo quiero extraer acá la conclusión de que ese preconcepto de que el software abierto y sin fines de lucro ofrece lo mismo que el software comercial es más aparente que real: si no hay un negocio atrás que lo sustente (que reinvierta en investigación y desarrollo), es cuestión de tiempo (el autor de esta nota admite, sin ponerse colorado, no ver como un pecado que quién desarrolle software gane dinero por ello)

Epílogo: El Mundo Al Revés

Habitualmente se asocia a Microsoft con "software cerrado", "propiedad intelectual", "licencias", etc. Y son conocidas las presiones que la Unión Europea y otros países le ponen para que libere parte del código de Windows, como una forma de equiparar las posibilidades de vendors locales de distribuir productos para esta plataforma con la misma calidad con que podría hacerlo la misma Microsoft

Pues bien, Microsoft ha inaugurado semanas atrás un portal dedicado al software que distribuye en forma abierta (no Windows y Office, por ahora , aunque del Office sometió su OpenXML, el formato de sus documentos, a estandarización de manera tal que cualquiera pueda proveer una suite de similares características sin riesgo de incompatibilidad al distribuir documentos a usuarios de otras suites)

Como contrapartida, Optaros (una consultora de Boston) lanzó también semanas atrás el Enterprise Open Source Directory: un catálogo de aplicaciones de código abierto listas para las empresas (con revisiones, casos de estudio, etc). La idea de Optaros es acercar a los que desarrollan código abierto con las potenciales empresas que utilicen sus productos. El de Optaros no parece ser el único caso: recomiendo la lectura del artículo "El Open Source Empresarial Consiguió Algunas Recomendaciones" de John Waters, para el canal de Arquitectura del portal FTPOnline

Habrá una batalla interesante aquí. Enhorabuena y que gane el mejor

 La verdad  es que no me gusta mucho la idea de hacer un post sobre el blog en sí (es decir, que no agregue ningún valor respecto del objetivo del mismo -Arquitectura de Software y algo más allá sobre la vida misma-). Pero lo que pasó esta semana merece ser destacado, y simplemente este metapost quedará sin categoría asignada

En la semana en que terminó anoche, 1294 (mil doscientas noventa y cuatro) páginas de mi blog fueron visitadas. Debo darle las gracias a San Google que me viene indexando bastante lindo. Me acceden mayormente desde México y Colombia, al que se ha añadido ahora Perú. También recibo visitas -en un segundo orden- desde Chile y Brasil, y en menor medida desde Argentina y España

De mantenerse este ritmo (no lo creo, es demasiado, pero soñar no cuesta nada) en 10 (diez) semanas estaría superando las 100000 (cien mil) visitas desde que el blog se inauguró, el 11 de Agosto de 2005

Mil doscientas noventa y cuatro GRACIAS a todos. A los que me visitan voluntariamente y también a aquellos que dieron conmigo mientras buscaban algo (espero, en ese caso, haberles servido)

 *** REGALO ANIVERSARIO: El DVD de Patterns & Practices 2007 con Todas las Software Factories, Guías de Arquitectura, Labos, Videos y Más!! ***

 Amigazos,  a Uds que léen siempre lo que tengo para decir, a aquellos que incluso se suscribieron a mi RSS para no perderse ni un post -incluso los que son más de ocio que de Arquitectura-, aquellos que he ido conociendo por sus comentarios sobre mis posts y que me encantaría tener la chance de conocer personalmente (tengo fé de que va a pasar), a los que me hicieron preguntas adicionales (y con eso me hicieron sentir importante por un rato)...

A todos Uds gracias. El pasado 11 de Agosto (el sábado último) cerramos el segundo año de este blog que, si bien está lejos de ser lo que me gustaría que sea si tuviera más tiempo para dedicarle, sí puedo anticipar que tiene cuerda para rato

A modo de balance voy a destacar los posts más salientes de cada mes

Mientras escribo esto me quedo pensando en lo que contaba de esa semana en que estuve en Orlando, durante el TechEd, y no me puedo borrar charlas con algunos arquitectos que me decían "todo esto me parece muy cool, pero por darle pelota me pasa que lo que antes hubiera hecho en una hora -seguramente sin buscar que sea reusable, compatible con el futuro, modular, componentizable, etc- ahora me lleva no menos de tres y me queda una sensación incómoda de si no estaba mejor cuando hacía cosas que seguramente no me iban a servir para siempre, pero que en lapsos breves estaban andando"

Qué amarga conclusión si se comprobase que todo esto para lo único que sirve es para convertir soft barato y presuntamente berreta (habría que confirmar esto último, ya que no necesariamente) en soft que promete mucho pero no concreta tanto, y cuesta valores saladitos (recursos humanos escasos o no siempre a la altura de los últimos avances; horas / hombre que, baratas o no tanto, finalmente terminan siendo muchas más que las presupuestadas)

Estará yendo todo el mundo a SOA, realmente? O SOA es algo que genera curiosidad, todos quieren leer algo sobre, pero pocos están firmemente decididos a ir para aquel lado? Y los que fueron a SOA, habrán encontrado una bolsa con moneditas al final del arco iris? Tendrán arco iris, o todavía están esperando que aparezca cuando pare la tormenta eléctrica, granizo incluído, que amenaza con enterrar el datacenter?

La verdad es que SOA, como todas las restantes tendencias son resultados evolutivos de intentos anteriores que por alguna razón fracasaron. SOA no es más que una respuesta desacoplada al CORBA de los '90

Y REST, qué es? Es una salida elegante y liviana a escenarios donde las complejas extensiones WS-* de los servicios web no sean necesarias

Algunas nuevas tecnologías llegan a ponerle la tapa al cajón de los intentos anteriores, en tanto que otras vienen sólo a complementar (a sumarse a) soluciones aportando una dosis de sencillez allí donde no hacía falta poner toda la carne a la parrilla

Qué pasos debe dar un arquitecto para aconsejar determinada tecnología? Preliminarmente, mantenerse informado de las tendencias actuales (sin tomar todo al pié de la letra, sólo estar alerta)

Posteriormente organizar una Prueba de Concepto (Proof of Concept, o PoC) para aquellas tecnologías que considere que verdaderamente van a permitir mejorar el soporte del área de tecnología a los objetivos del negocio (tanto por el aseguramiento del revenue como por la reducción de costos). La PoC es un primer filtro a las tecnologías testeadas, que le deberían permitir al arquitecto hacerse una idea de hasta dónde esta aparente solución no podría ser un nuevo foco de complejidad

Si la PoC resultase exitosa el arquitecto puede aconsejar al líder del proyecto (eventualmente a la gerencia de tecnología) de invertir más en esa tecnología para una posible adopción (sea en un dado proyecto o sea a nivel estratégico en un portfolio más amplio de aplicaciones). La aceptación por parte del líder de proyecto y/o de la gerencia dependerá en qué tan hábiles seamos en mostrar que estas tendencias realmente van alineadas con objetivos de la organización. Va a ser difícil, si no, que nos suelten un mango (pasa que nadie se quiere quemar después, viste? Entendé eso primero y se te va a hacer la vida mucho más fácil)

Si hay luz verde, se abre una etapa donde se debería capacitar tanto a desarrolladores como a profesionales de TI (infraestructura) en las tecnologías a aplicar, así como eventualmente contratar profesionales ya entrenados en las mismas (y, de ser posible, "estrenados" también: con experiencia)

Personalmente creo que el arquitecto no debería competir con los desarrolladores senior a ver quién la tiene más clara en las nuevas APIs. Suele pasar esto en aquellas personas de carácter inseguro de sí mismas que temen verse desplazados por aquellos que dominan mejor las nuevas tecnologías, como si la visión de negocio detrás de las mismas -se las domine o no- no le importase a la gerencia. En cambio, el arquitecto debería aprovechar el training en las nuevas tecnologías para, con la ayuda de los desarrolladores senior, definir frameworks (componentes, generadores de código, etc) que permitan esconder la complejidad inherente de las nuevas tecnologías, de manera de adoptarla en una forma commoditizada. En castellano, esto significa poder montar un framework de componentes y herramientas que permitan hacer uso de APIs nuevas, complejas, por parte de desarrolladores de nivel intermedio -que quizás, con suerte, ni sepan que lo que están desarrollando termina haciendo uso de estas nuevas tecnologías-. En suma, el arquitecto juega acá un rol primordial en bajar todo lo que se pueda el costo de adopción 

Balas de plata, ya lo había dicho Frederick Brooks Jr, no hay ni va a haber: aún siguiendo las tendencias más noveles, de las que haya casos de estudio exitosísimos por todos lados, nada nos garantiza que a nosotros nos deba ir bien también. La clave es no dejar de lado las reales motivaciones, en términos de resultados de la organización, de subirse a nuevas tendencias. El arquitecto que pasa demasiado tiempo con la vista baja mirando las tecnologías, y no la levanta cada tanto para mirar lo que la organización demanda es como el tenista que no mantiene en todo momento la vista en la pelota

Y con esto dicho se inaugura DiegumZone Año III

 Al  principio de esta serie te había explicado el concepto económico conocido como "efecto red" con un ejemplo cotidiano de los que que van a canjear cosas usadas a Parque Rivadavia. Acá se viene mi segunda explicación de barrio: te presento a The Long Tail (Larga Cola, modelo económico atribuido a Chris Anderson, editor de la revista Wired y autor del libro homónimo, que ilustra la apertura de este post)

Situate: estás caminando por la avenida Santa Fé de Buenos Aires, Providencia en Santiago, 18 de Julio en Montevideo o cualquier avenida importante y llena de comercios de la ciudad que vivas. Te metés en la librería más grande que encontrás. Tiene varios pisos, hacia arriba y también uno o dos subterráneos. Está llena de vendedores y cajas registradoras por doquier para poder pagar sin cuellos de botella (sin colas largas, je ). Al entrar ves en las mesas de adelante una con el cartel "Novedades" y te mandás a ver qué hay. Algunas novelas, libros de actualidad política, management, manuales de autoayuda, etc. Ves otra mesa de "Ofertas". Libros muy baratos allí pero será psicológico o qué, el hecho de que estén en "Oferta" inmediatamente te produce la sensación de que son libros que hoy no aportan gran conocimiento así que por muy baratos que estén, si valen más de 0 (cero) ya es plata tirada. Seguís y te adentrás en el resto de la librería. Los libros están ordenados por genero, claro. En una hora y media te la recorriste toda y agarraste dos o tres libros que te interesaron y te los vas a comprar

Pero atendeme una cosa: no te compraste los libros que vos querías en realidad. Te compraste libros de un conjunto más restringido que ése: te compraste los libros que más te gustaron de entre los que la librería tenía disponibles. No tenés que ser un premio Nobel para entender que el espacio físico es finito y por ende no podrías meter allí TODOS los libros que se hayan escrito alguna vez. Por esta razón, los libreros tratan de llevar libros que saben que en el corto o mediano plazo van a vender. Esos son los libros disponibles y de entre esos puede haber varios que te interesen a vos. Pero no necesariamente todos los que a vos te interesaban, por muy grande que sea la librería, puede estar en stock
Por ejemplo, yo estoy interesado en la colección de la historieta creada por Trillo y Altuna, "Las Puertitas del Señor López" (originalmente publicada en la desaparecida revista Humor, de la también extinta Ediciones de la Urraca, y posteriormente compilada en tres libros de esa misma editorial). El asunto es que esa editorial no existe más y hasta donde sé, esos libros ya no se editan. Por consiguiente, tenés que meterte en los sucuchos libreros de Avenida Corrientes, revolver todo y seguramente en algún momento encontrarás uno o dos. Si encontrás los tres te pago el doble de lo que hayas pagado por ellos. Si vas a mega librerías como Cúspide, Yenny-El Ateneo, etc, no doy fe de que los encuentres

Bueno, eso es el mundo real, físico. No el mundo virtual de Internet. No te olvides que la web empezó con una idea de unos científicos de crear un hipertexto global que relacione las obras de todos ellos, de sus antecesores y sucesores, de manera tal que si estabas leyendo un paper que en un párrafo dice "como manifestó Fulano de Tal en bla bla bla", puedas ir con el mouse a "Fulano de Tal" y/o a "bla bla bla" y mediante un click ir a ver su trabajo. De hecho, HTTP significa "protocolo de transporte de hipertextos", en tanto que HTML significa "lenguaje de delimitadores (markups) para hipertextos". Los científicos que inventaron y ejecutaron esta idea nunca se imaginaron lo que se podía hacer con su herramienta si esta caía en manos de hombres de negocios

Qué pasaría si todas las librerías ponen su stock disponible todo en un solo lugar, de manera tal que si yo quiero "Las Puertitas del Sr López", entro a esa librería virtual y me dice las -por decir algo- tres direcciones más cerca de mi casa donde los libros están disponibles. O me dice, independientemente de dónde estén los libros, los diez precios más bajos (incluyendo el shipping, el envío), por el cual me puedo hacer de la colección. Te digo más: no necesariamente debo comprar los tres juntos. Excepto que haya una oferta irresistible tipo "los tres a mitad de precio", puedo comprar cada uno en el lugar que me lo vendan más barato (siempre envío incluído)

Ese beneficio nos ha traido la web hoy. Te acordás cuando te decía "Los Datos Mandan"? Si alguien es capaz de reunir la información del stock disponible (quién lo tiene, cuánto vale, cuánto demora en llegar, que ofertas ofrece, etc) el valor agregado de esa info toda junta es un caño!!

Piedra libre para el Señor López: sin moverme del living encontré a dos particulares que
pusieron dos volúmenes a la venta. No voy a tener que recorrer librerías en vano

Ese es entonces el modelo de la cola larga. El que acuñó el término lo que sostiene es que "el futuro del comercio pasa por vender menos cantidad de más cosas". Porque si sumamos toda la plata que nos podría entrar por lograr vender esos libros que ya muy pocos quieren... eso puede ser guita grande!

No todo es lo que parece. Si bien antes de la web, el área roja
parecía más fácil de cubrir que la naranja, hoy la globalización
de la tecnología equiparó el costo de cubrir esta última franja

Precursores de esta nueva forma de comercio son, como decíamos, Google y Amazon. Pero no fueron los únicos ni al comienzo ni ahora. Es loable la forma de en que Netflix, una cadena yanqui de alquiler de DVDs tipo Blockbuster, captura su cola larga (compuesta, en este caso, por aquellas películas que poca gente quiere ver)

El modelo comercial de Netflix, el videoclub sin locales

Netflix no tiene locales. En cambio, te ofrecen un catálogo en donde te armás la lista de las pelis que querés ver y ellos te las llevan a tu casa gratis, junto con un sobre vacío para que pongas las pelis ahí y se las mandes por correo cuando terminés de verlas. En cambio en los video clubes tradicionales, fisicamente establecidos, vos tenés que ir y elegir de entre las pelis disponibles cuáles querés llevar. De nuevo, como el espacio para meter películas no es ilimitado, seguramente estarán disponibles aquellas que se alquilan rápido en gran cantidad. Y las que se demandan poco, con suerte las tengan

Algo que Netflix me permite hacer, y que normalmente es raro que pueda hacer en los
videoclubes tradicionales: conseguir disponible esta película que es ya un clásico de culto
de la cultura punk, pero al igual que dicho género musical, hoy está muerta

Por supuesto, para la economía global la cola larga trae una espiral de beneficios por cuanto abre la puerta a industrias asociadas. Por ejemplo en el caso de los libros, cómo hago para comprarlo una vez que me decidí por la librería de Sri Lanka? La industria de transporte de bienes va a tener que intervenir acá, pero además, si la librería de Sri Lanka está distribuyendo varios libros a varios países, van a necesitar alguien que les haga la logística para distribuir la mayor cantidad de bienes contratando la menor cantidad de transportes posibles (el factor "tiempo" cuenta acá, no es que pueden demorar toda la vida para mandarme "Las Puertitas del Sr. López": pueden poner una ventana de 48 horas hasta ver si alguien más por mi región se sube y, cumplido el plazo, mandarlo sea como sea). Esta ventana de oportunidades a industrias relacionadas ya la abría la Web 1.0, pero es claro que con el modelo de la cola larga se afianza

Pero volvamos a la oficina, a la Enterprise 2.0. Qué tenemos que hacer para encontrar nuestra cola larga y empezar a cubrirla?
Nosotros? Nada. Nosotros, los desarrolladores de software, arquitectos, jefes de proyecto de software, etc, no somos -por lo general- ni tomadores de decisión a nivel de negocio ni expertos en ingeniería industrial (ni siquiera somos simples contadores, apenas). Entonces, sin más trámites, dejemos que esa gente que sí entiende el negocio (y actúa en consecuencia) se preocupe de definir cuál es la cola larga a cubrir, y calcule su superficie para decidir si vale la pena salir a cubrirla o no

Nosotros piolas? No. A nosotros nos toca poner lo nuestro: el aprovechamiento de lo que las tecnologías que te destacaba en los posts anteriores pueden contribuir para lograr una buena experiencia de usuario que garantice que no se caiga las oportunidades, exponiendo una fuerte base de datos depurable (cuando no extendida) por los usuarios, de manera de proveer el virtuosismo del "efecto red". Después de tantos posts, esto como que va cerrando, no?

Justamente, respecto de estos datos, la clave para agregar valor no pasa por tirarselos en la jeta al que nos visita de modo que sea él quien se encargue de clasificarlos -lo que sería nuestro suicidio, comercialmente hablando- sino el agregado desde fuentes confiables, renovables (extensibles por los usuarios), filtrables en base al contexto de quien nos visita

Caso de Estudio I: el diario Clarin tiene en su página principal un espacio para publicidad
asignado. No obstante no le muestra a todos sus lectores el mismo, sino un aviso que perciba
que pueda ser del interés de quien lo lée. En mi caso, detecta por mi dirección IP que no
estoy accediendo a su portal desde Argentina. Pero al mismo tiempo asume que si entro al
diario Clarin, probablemente sea argentino. Consecuencia: la publicidad que me toca ver a
mí es una oferta para llamar por larga distancia a mi país
Este es, entonces, un ejemplo de como el agregado inteligente de datos (esto es, utilizando
algoritmos que filtran la data en función del contexto del visitante) maximiza oportunidades,
especialmente comerciales

Caso de Estudio II: el que llega a Perú primero se queda con el pingüino (que se perdió
mientras buscaba comida en las costas chilenas). En este caso, el diario SeattleTimes, de
entre los tantos avisos publicitarios que tiene disponibles, filtra uno que tiene que ver con
el artículo que me dispuse a leer: Perú. Un nuevo ejemplo de cómo maximizar la cobertura
de la cola larga

Estimados, después de una intro y cinco entregas, creo que va siendo hora de dejar esta serie aquí. Seguro que se puede seguir hablando largo y tendido de las oportunidades que Enterprise 2.0 abre y, sobre todo a nosotros, arquitectos de software, lo que el estado del arte tecnológico nos pone a disposición para matchear con lo que el costado comercial de la organización para la que trabajamos nos demanda. Fue un placer para mí toda la investigación que el armado de esta serie me motivó y te quiero agradecer la paciencia y la confianza de haberla leído completa

Esta serie se compuso entonces de

• Introducción
• Más se Usa, Más Nuevo Queda
• Elogio del Choreo
• Que No se Retove el Usuario
• Siempre "Casi Listo"
• Los Últimos Serán los Primeros