bitácora de uno

Dos perlas…

“La Gestión del Conocimiento abre el espacio para que podamos mostrar nuestra personalidad (nuestra huella genética), nuestra aportación sin ataduras orientado a nuestro negocio y a nuestra realidad empresarial.”

“Las empresas en que más traumático será ese cambio, serán aquellas que han tenido un gran crecimiento internacional y han creado estructuras muy politizadas, que en sí mismas son las principales barreras de alineación, entre ellas estarán las Administraciones Públicas.”

Tenemos la información como un concepto más evolucionado y amplio que los datos, y por encima de ambos el Conocimiento.

De un artículo de Alberto G. Valencia : La Nueva Organización Empresarial

Antes de ir al grano tengo que decir escribir que le he cogido un poco de manía al concepto de Patrones de Diseño mal aplicado. Por lo que he leído da la impresión de que como es muy chuli esto de los patrones, se fuerza a que cualquier cosa o idea luzca las palabras en su descripción. Efectivamente podemos ver un patrón en cómo removemos el azúcar del café, pero si así lo percibimos en este caso ¿en qué situación no los veremos? Me da la sensación que de esta forma pierden su cometido y, cuando menos, su particularidad.

Christopher Alexander, arquitecto de edificios reconocido como el originador de la idea de los patrones, explica que “cada patrón en una regla con tres integrantes que expresa la relación entre cierto contexto, un problema y una solución a dicho problema”.

Un desarrollador de midlewares, frameworks o aplicaciones específicas se tiene que enfrentar a retos relacionados con el diseño y la programación de asuntos tales como:
La persistencia de los datos, la organicación de los datos, la gestión de las conexiones, inicialización de servicio y objetos, el manejo de los parámetros de configuración, la comunicación entre estructuras, la concurrencia, el control de acceso a los recursos, control del flujo de programa, la gestión de errores y de información de log, bucles de gestión de eventos, etc.

La resolución de estos retos se presenta una y otra vez, e inicialmente el conocimiento necesario para resolverlos estaba en las mentes de algunos desarrolladores o, de forma implícita y poco aprehendible, en el código. Los patrones de diseño tratan de solventar este problema.

Los patrones permiten la reutilización de los conocimientos y experiencia de diseño implementando los aspectos estáticos y dinámicos de soluciones satisfactorias a problemas que surgen al desarrollar software en un contexto determinado. De esta forma ayudan a incrementar la reusabilidad capturando y reutilizando las estructuras y las formas de colaboración de los elementos clave de undiseño software.

Se ha realizado un gran esfuerzo para documentar patrones y en el desarrollo de frameworks basados en ellos que permitan a su vez el desarrollo y la reutilización de middlewares.

Patrones de Diseño:
Proporcionan un esquema con los elementos de un sistema software y las relaciones entre ellos y describen una estructura dfe elementos en comunicación que soluciona un problema de diseño general en un contexto particular.

Patrones de Arquitectura:
Expresan la estructura fundamental de organización de un software y proporcionan un conjunto de subsistemas con sus responsabilidades, y las líneas para organizar la relación entre dichos subsistemas.

Lenguajes de Patrones:
Agrupan una trama de patrones para definir un vocabulario para hablar de problemas de desarrollo y ofrecer un proceso para su resolución. Un grupo de desarrolladores trabajando en un software y hablando de los problemas que se les presentan y las soluciones más acertadas y que se preocupen por leer lo que hay por ahí en patrones y software, acabarán incorporando a sus conversaciones los nombres de los patrones más utilizados y entendiendo como grupo, sus aplicaciones y las relaciones entre ellos. Estará bien trabajar en un grupo así usando un lenguaje de patrones ¿no?.

Podíamos decir que los patrones son descripciones más abstractas que los frameworks ya que éstos están implementados en un lenguaje en particular. En general los frameworks albergan e implementan docenas de patrones de diseño, y a su vez los patrones se utilizan a menudo para documentar los frameworks.

Veremos algún patrón, junto con su aplicación y ejemplo de uso en nuevas entradas.

Mucho de lo aquí visto están en la enriquecedora página de documentación de ACE.
También puedes hurgar un rato por la Wikipedia.

Podríamos traducirlo por marco o entorno de trabajo, pero como con tantos conceptos dentro de la computación que han surgido del mundo anglo-sajón, creo que en este caso y dada la extensión de uso del término en inglés lo dejamos como está y listo.

Las características deseables para un producto software son variadas y muy necesarias. Un software debe ser extensible, modular, robusto y eficiente. Conseguir estas características es complejo, y los frameworks aportan la tecnología que trata de abordar esta complejidad incrementando los niveles de reusabilidad del código.

Un framework es una colección de componentes software que colaboran entre sí para proporcionar una arquitectura reusable para una determinada familia de aplicaciones.

Los componentes de un framework son clases (gestores de mensajes, manejadores de eventos, mapas de conexiones,…), jerarquías de clases, categorías de clases (familias de mecanismos de control) y objetos.Un componente es una unidad de encapsulación de servicios con uno o más interfaces a través de los cuales se proporciona acceso a los servicios que ofrece. También podemos definir un framework como un diseño reusable, de una parte o de un todo de un sistema, representado por un conjunto de clases abstractas y la forma en que interaccionan sus instancias.

Se trata de integrar componentes que son independientes de la aplicación con los que son específicos de forma sencilla para que puedan colaborar entre ellos. La configuración de los componentes de un framework puede ser dinámica (en instalación o ejecución) o estática (en tiempo de compilación).
Normalmente los framework se apoyan y hacen un uso intensivo de los patrones de diseño.

Un framework tipo Modelo/Vista/Controlador se puede descomponer en tres patrones de diseño principales y varios secundarios.
Observer : Para asegurar que la presentación de la vista del modelo está actualizada.
Composite: Para anidar vistas.
Strategy : Para provocar que las vistas deleguen la responsabilidad de tratar los eventos de usuario a sus controladores.

Un framework orientado a aplicaciones distribuidas en red tiene tres características principales:

Inversión de Control.
Cambia el modo de programación. No somos nosotros como desarrolladores de un aplicación basada en un framework los que programamos la lógica de control del software. El framework proporciona mecanismos que llamarán a los métodos específicos que programemos para nuestra aplicación.
La inversión se realiza a través de funciones de devolución de llamada (callbacks) a los métodos gancho (hook methods) cuando ocurre un evento como la llegada de datos a una conexión de red. Cuando llega el evento el framework llama al método gancho virtual de un componente registrado previamente que realiza el procesamiento específico de la aplicación.
Los métodos gancho virtuales separan y abstraen el software específico del software reusable que proporciona el framework, y esto nos permite extender y personalizar las aplicaciones de forma más fácil y sencilla.

Proporciona un conjunto integrado de estructuras y funcionalidad para determinado dominio.
Soluciones comunes, recurrentes, probadas y elegantes.

Es una aplicación semi-completa.
El programador la personaliza para crear la aplicación buscada extendiendo los componentes reusables del framework.

El objetivo perseguido es aumentar la cantidad de código reutilizado frente al nuevo.

El uso de frameworks presenta algunos problemas:
• Difíciles de aprender.
• Son muy potentes pero también son complejos. Requieren de más y mejor documentación que otros sistemas.
• Difíciles de desarrollar: Requieren profundos conocimiento de ingeniería y programación, dominio de patrones de diseño y de técnicas Orientadas a Objeto. Mejores programadores que la media.
• Restringido por lenguaje: Están implementados en un lenguaje y en general quedan restringidos a productos desarrollados en el mismo lenguaje. CORBA trata de resolver este problema entre otros.

Algunos ejemplos de frameworks son MacApp, X-Windows, Java Swing, MFC, Struts y ACE.

No perdamos de vista el objetivo pricipal de todo esto de la ingeniería del software: Currar menos pero mejor.

Así están las cosas y el mismo concepto puede nombrarse usando el término - quizás más correcto en una entrevista de trabajo - de Reusabilidad.

La reusabilidad de código y diseños es fundamental en el proceso de desarrollo de software, porque al reutilizar escribimos menos código que, además de mejorar la productividad, reduce la cantidad de fallos cometidos y los periodos de pruebas y consigue que la calidad y solidez general del producto se vea incrementada.

Middlewares, frameworks y patrones son conceptos diferentes pero interrelacionados que pretenden incrementar la reusabilidad.

Un Middleware es un software que puede incrementar significativamente la reusabilidad mediante soluciones utilizables rápidamente y basadas en estándares aplicables a problemas y tareas comunes en programación.

La idea es que los desarrolladores se puedan concentrar en asuntos propios de la aplicación y olvidarse de problemas comunes - estructurales o no - ya resueltos previamente de forma elegante y satisfactoria. CORBA (Common Object Request Broker Architecture) es un middleware estándar que surge la la organización internacional OMG. Otros estándares como JVM, J2EE y .NET han surgido de consorcios industriales y líderes en diferentes áreas del mercado.

Para el desarrollo de los diferentes middlewares son cruciales los patrones de diseño y los frameworks. Es común que los middlewares se desarrollen usando frameworks que se basan a su vez en patrones de estrategias de composición y optimización. Entre los tres tipos de abstracción se aprovechan muchas sinergías. El tipo de middleware en el que yo estoy interesado es el orientado a aplicaciones distribuidas en red.
Normalmente podemos descomponer un middleware en sus capas de igual forma a como se hace con los protocolos de red.

Empezando de abajo arriba y obviando las capas de dispositivos hardware y la de los sistemas operativos:

Middleware de Infraestructura de Servidor
Sirve para abstraerse y mejorar los mecanismos nativos proporcionados por los sistemas operativos subyacentes. Proporciona mecanismos resusables para manejo de la demultiplexación de de eventos, comunicación entre procesos, concurrencia y sincronización por nombrar algunos ejemplos. Abstrayendo estos mecanismos y las peculiaridades de los diferentes SO creamos objetos reusables que ayudan a eliminar los aspectos tediosos y tendentes a errores, además de poco portables, de bregar con los detalles de bajo nivel de cada sistema operativo (SO). Ejemplos de este tipo de middleware son la máquina virtual de Java (JVM), y el Common Language Runtime (CLR) de Microsoft. ACE encaja dentro de esta categoría.

Middleware de Distribución
Proporcionan un modelo de programación distribuida de más alto nivel cuyos objetos e interfaces automatizan y extienden la funcionalidad de los SOs encapsulada por la capa anterior de infraestructura de servidor. Nos permite programar aplicaciones llamando a operaciones en los objetos destino olvidándonos de dependencias como la localización, el lenguaje de programación, SO, plataforma, protocolos de comunicación y hardware. En esta categoría se encuentran CORBA y Java Remote Invocation (JRI) de Sun. SOAP (Simple Object Access Protocol) es un marco extensible y descentralizado que permite trabajar sobre múltiples pilas de protocolos de redes informáticas. Los procedimientos de llamadas remotas pueden ser modelados en la forma de varios mensajes SOAP interactuando entre sí, y permite el intercambio de información estructurada (XML) en la Web utilizando diferentes protocolos tales como HTTP, SMTP y MIME.

Middleware de Servicios Comunes
Mejoran el middleware de distribución definiendo servicios reusables de más alto nivel e independientes de dominio, que permite a los desarrolladores de aplicaciones centrarse en la programación y el diseño de la lógica del negocio, evitándose la necesidad de escribir el código que tendrían que escribir para aplicaciones distribuidas si usaran middleware de capas más bajas. Ejemplos de servicios ofrecidos son toda la capa transaccional, seguridad o pooles de conexión a base de datos, de manera que el programador no tenga que realizar más esas tareas utilizando un modelo de componentes y lenguajes sencillos por lotes.

Middleware de Dominio Específico
Los servicios en este caso están asociados y enfocados a determinados dominios como pueden ser las telecomunicaciones, el comercio electrónico, o el campo de la salud y la medicina.

En la próxima entrada tratare de aclarar (y aclararme) qué puñetas es un framework, para qué sirve y por qué es interesante usarlos.

Os dejo el enlace al pedazo de bitácora hermana de Justo Hidalgo con parecidas ambiciones a la presente bitácora. Merece la pena bucear en sus entradas si te interesa la ingeniería del software y tienes una mente inquieta.

¿Está claro que aportación realmente orginal hay poca en este artículo y en general en todo lo que escribo? Reconozco que copio de varios sitios y no tengo ganas de - ni capacidad de acordarme de - referenciarlos a todos.

Es bien cierto que muchos de los proyectos con éxito basados en la idea de software libre se han gestado en el viejo continente. Tenemos - por ejemplo - Linux y MySql, por decir dos de los más mencionados. Pero parece que siempre pensamos en Silicon Valley.

El otro día leía en la Pastilla Roja un artículo sobre el presupuesto medio de los proyectos que han presentado las empresas españolas a las subvenciones Profit que gestiona el Ministerio de Industria. Era de unos 320.000 euros, que viendo la media de subvención concedida (un 15%) supone que el proyecto - en caso de ser seleccionado - recibirá unos 45.000 euros. Sergio Montoro comparaba este apoyo con el que puede uno recibir de inversores privados en EE.UU, y - claro - el apoyo europeo quedaba como de juguete. También es verdad que una cosa es una subvención o un crédito a fondo perdido, y otra es un inversor privado con un objetivo a corto, medio o largo plazo muy claro.

¿Por qué la mayoría de los proyectos son de 320.000 €? Porque una de las condiciones del Ministerio es que los proyectos superen los 288.000 € anuales, para que tengan cierta enjundia. Así que las empresas españolitas hacemos el presupuesto para que dé esa cifra y algo más, y así nos sale esa media. Supongamos - supongamos - que contratamos a la gente necesaria en el proyecto por un sueldo de 30.000 € anuales. Si a esa cifra le sumamos los gastos de seguridad social, equipo, formación y demás gastos de infraestructura y administración nos sale que por cada persona que integramos en el proyecto necesitamos invertir unos 45.000 €. Si el proyecto necesita sobretodo trabajadores tenemos para contratar a unas 4 personas, de las cuales el estado nos podría financiar una durante un año.

Es verdad que cuatro personas con un rendimiento adecuado, y durante un año, pueden hacer las pirámides, pero… no nos engañemos. De todas formas y sin irnos del asunto, podemos ver que las ayudas a empresas pequeñas o medianas con proyectos interesantes no son definitivas.

Estamos hablando de un año en el que tanto Europa como España se supone que están apostando fuerte por la Investigación, el Desarrollo y la Innovación. ¿Es así como vamos a salir del país europeo con el antepenúltimo puesto en materia de I+D+i? ¿Dónde se va todo el dinero para fomento de estas líneas? ¿Por qué se apoya económicamente a los grandes proyectos y grandes empresas en lugar de a la PYME que es donde se concentra la capacidad de innovar? ¿Por qué no apoyar más los proyectos y dejar que las grandes empresas cobren sobre porcentaje de los beneficios en lugar de por adelantado?

Está demostrado que el software libre (o el código abierto, que no es lo mismo) tiene grandes impulsores en Europa y además funciona, y además con modelos de negocio rentables.

Pongámonos las pilas para hacer proyectos de calidad, pasemos de los centros de investigación rémora y apostemos por los centros de investigación y universidades con ganas de hacer nuevas cosas y de investigar y publicar, exijámosle a nuestros gobiernos un apoyo real, pidamos las cifras de inversiones y veámoslas con ojo crítico, que para eso son nuestras (de todos/as), y - en definitiva - seamos serios con lo que hacemos mientras intentamos disfrutarlo.

Os dejo un enlace a la bitácora de un tal Matt Assay al respecto de europa, la innovación y el software libre: Una llamada a las armas: Europa y el Open Source.