domingo, 28 de marzo de 2010

Análisis entre modelo relacional y modelo documental de bases de datos

El origen de las bases de datos va ligado a la necesidad de organizar la cada vez más exigente cantidad de datos que se requieren. En los inicios, la información estaba delegada a los ficheros, como meros depósitos de información y a los que se accedía a bajo nivel para las operaciones más elementales de lectura y escritura. Con el tiempo, la información requerida se hacía mayor, y la complejidad de gestionarla también creció. Se comenzó a aplicar técnicas como índices para accesos más rápidos y para la ordenación de la misma. Pero las aplicaciones debían tratar los ficheros de forma artesanal y personalizada.

Surgieron sistemas que automatizaban las operaciones complejas de gestión de los datos, como los índices, así como las primeras relaciones entre campos clave entre dos o más tablas. Pioneros en estos sistemas fueron (por citar los más conocidos) fueron dBASE y Clipper, pero también empezaban a gestarse grandes bases de datos profesionales, como Oracle o DB2. Estamos hablando de los años 80.

Los dispositivos de almacenamiento eran limitados, así como la capacidad de los sistemas operativos en almacenar y direccionar información, aunque suficientes para la época. Es por ello que la optimización del espacio fuera un un factor vital, y que el diseño de las tablas contemplase el acotar el almacenamiento de cada campo, tener en cuenta el tamaño de cada fila, y prever el tamaño total de los ficheros junto con la previsión de crecimiento de los mismos.


Bases de datos relacionales

El modelo relacional surge ante estas circunstancias, postulado por Frank Codd en 1970. La normalización de los datos permite organizar la información separando en tablas la información más pequeña posible e independiente, para evitar la repetición de la misma. Para acceder a toda la información, las tablas se relacionan unas y otras mediante campos clave comunes, que suelen ser números con un id único.

Este modelo de almacenamiento es organizado y óptimo, define unas reglas que evitan la redundancia de la información y facilitan la consistencia de los datos. Este sistema de ingeniería de la información es el que ha regido las bases de datos durante los últimos 40 años.

Para trabajar con este modelo de almacenamiento, surgió el lenguaje SQL, que facilitó el entendimiento de las relaciones a través de una sintaxis sencilla y asimilable.

Este modelo de almacenamiento tiene las siguientes ventajas:
- Sistema de normalización óptimo en almacenamiento. Idóneo para sistemas con requisitos muy claros y poco dado a cambios.
- Sistema fuertemente estructurado e interrelacionado, formando un esquema.
- Sistema unánimente aceptado y estándar, utilizado en más del 90% de las aplicaciones
- La mayor parte de fabricantes de bases de datos utilizan el SQL estándar en sus productos, si bien puede haber alguna pequeña variación fácilmente subsanable.
- Las migraciones entre bases de datos de diferentes fabricantes no son excesivamente impactantes
- Las consultas SQL tienen funciones agregadas de cálculo asociadas a columnas en los resultados.
- Los sistemas de bases de datos relacionales asumen el trabajo de las complejidades de la integridad referencial, velando por la consistencia de la información y liberando al desarrollador de estas tareas para que se centre solamente en las consultas.
- Multitud de herramientas productivas construídas en torno a este modelo: business intelligence, datamining, ETL, administración, monitorización, etc.
- Eficiente para gestionar datos para automatizar actividades.

Sin embargo, también conlleva algunos inconvenientes:
- La normalización en entidades atómicas no es natural y tiende a complicar su entendimiento y los desarrollos.
- Basar la identificación de los registros y relacionar tablas por códigos numéricos es críptico y poco natural.
- La información, tal y como está almacenada, difiere mucho de cómo es gestionada, y requiere un esfuerzo importante de adaptaciones.
- Sistema rígido y estricto poco tolerante a fallos y que penaliza los cambios.
- La adición de entidades de relación y de campos clave a una tabla ya existente implica complejidad e impacta en los desarrollos actuales.
- Sistema que gana en complejidad a medida que crece. La escalabilidad de la estructura se torna condicionada.
- El desarrollo de las aplicaciones requiere de capacitación para conocer el modelo entidad-relación.
- El almacenamiento de toda la información requiere dividir la información en entidades atómicas y tratar éstas por separado en varios procesos.
- Las consultas requieren tracear la información separada y reunirla. Las joins suelen ser complejas y pesadas, y a veces no son suficientes, requiriendo varios procesos de consulta adicionales.
- La gestión automatizada de la integridad referencial supone una penalización de tiempo de accesos (lectura y escritura) a la información.
- La gestión automatizada de la integridad referencial no evita que el desarrollador preste atención a errores de integridad y su causa. El desarrollador debe asegurar previamente la integridad y controlar si el sistema le informa de alguna violación de reglas de integridad. Por ejemplo, la creación de una categoría de productos. El sistema informará si se está tratando de crear una categoría ya existente, y el programa debería capturar este aviso para advertir al usuario sobre la causa del problema. Otra forma (sin integridad automatizada) sería consultar previamente cuántas categorías existen con ese nombre. Si es mayor de cero advertir al usuario, y si no guardar la nueva categoría. El trabajo en ambos casos (con y sin integridad automatizada) no difiere mucho.
- La información de cada tabla está limitada a una estructura fija de campos o columnas, sean o no necesarios, y tengan o no valores. Si no se utiliza una columna, ésta se almacena de todas formas en cada fila.
- Poco eficiente a la hora de explotar grandes volúmenes de información textual (maneja mejor datos que información).
- Los principales fabricantes de sistemas de bases de datos relacionales las desarrollan de forma propietaria.


Bases de datos documentales

Las bases de datos documentales, a diferencia de las bases de datos relacionales, están libres de esquemas y de estructuras. Por tanto, la información no se divide en columnas fijas y filas, si no en documentos que pueden tener libertad de información, como cualquier cantidad de campos o de tipos de campos, e incluso de contener en el propio campo una lista de valores, un documento o una colección de documentos. La información almacenada en un documento está formado por pares de clave y valor.

La gran ventaja de no poseer esquema (y la consiguiente rigidez de estructuras y relaciones), es que son muy eficientes al trabajar con grandes cantidades de documentos.

Las principales ventajas de una base documental son las siguientes:
- Libre de esquemas. Al no estar sujeta a estructuras ni relaciones, los cambios de diseño son fáciles de adoptar y con un impacto mínimo.
- Al no tener relaciones se facilita la replicación
- Los sistemas de bases de datos documentales ganan rapidez dedicándose más en exclusiva al almacenamiento y la recuperación de la información (no consumen tiempos en la integridad o en la revisión de las reglas o constraints).
- Poseen un lenguaje de consulta natural.
- Sencillez y potencia en escalabilidad.
- Los campos vacíos no se añaden al documento, optimizando el espacio de almacenamiento.
- Cada documento (o “fila”) puede tener estructuras diferentes (más o menos campos, tipos diferentes de datos, etc.)
- Un documento es un objeto que normalmente es mapeado mediante JSON o XML
- Posibilidad en embeber documentos y colecciones dentro de documentos. Esto solventaría joins entre documentos, aunque agregaría complejidad a la estructura del documento.
Los datos almacenados no necesitan adaptaciones por las aplicaciones (tal como se almacenan se pueden gestionar).
- Muy eficiente a la hora de explotar grandes volúmenes de información textual (maneja mejor información que datos).
- Las migraciones entre bases de datos diferentes tienen muy poco impacto, pues comparten el formato JSON o XML.
- La mayor parte de los fabricantes de sistemas de bases de datos documentales, la desarrollan como open source.
- El auge de la Web está mirando este modelo de datos como clave en sus negocios, por su mayor capacidad de escalabilidad, rendimiento y alta disponibilidad, que los actuales sistemas de bases de datos relacionales.

Los principales inconvenientes serían:
- El sistema de base de datos no contempla realizar joins entre documentos.
- Más peso por parte de las aplicaciones para asumir la integridad y la consistencia.
- No posee funciones agregadas para realizar cálculos sobre la información de las consultas.
- Redundancia de la información. Penaliza el espacio de almacenamiento en aras de una mayor rapidez de acceso y de claridad de la información.
- Menos eficiente para automatizar actividades.
- Aunque este modelo de información es anterior al relacional, aún tiene una aceptación muy baja (menos de un 10% del total de aplicaciones funcionando en el mundo).
- No hay muchas herramientas de productividad en torno a este tipo de bases de datos, como Business Intelligence, monitorización, etc.
- Aunque es posible migrar un sistema relacional a un sistema documental, la potencia de la integridad referencial ha de ser restituida por código en las aplicaciones. No merece la pena esto, y sí una restrospectiva en la que se adapte los conceptos a documentos teniendo siempre en mente las ventajas que podría ganarse en la migración.

Safe Creative #1003275854193

martes, 23 de marzo de 2010

Conceptos básicos de MongoDB

Filosofía de almacenamiento en MongoDB

La filosofía de las bases de datos NOSQL suele ser chocante para todos los que llevan años trabajando en bases de datos relacionales. El no tener el concepto de una tabla, o de una integridad referencial con su relación de clave maestra a clave foránea, se hace difícil imaginar cómo puede funcionar y cómo pueden relacionarse y entenderse los datos.

MongoDB tiene el concepto de la información almacenada como clave/valor. Estos pares se almacenan en forma de documento u objeto dentro de una colección. Podemos imaginar un símil entre clave/valor como campo/valor, entre un objeto o documento y una fila, y entre colección y tabla. Este concepto puede ayudar a entender un poco mejor este sistema, pero no hay que olvidar que es un símil, no una equiparación.

Un documento u objeto (los dos términos se refieren a lo mismo), aunque se asemeje a una fila, en realidad no tiene nada que ver, pues en una base de datos relacional, cada fila tiene una organización estructurada común entre todas las filas. En MongoDB, cada fila puede tener su propia estructura, tener más o menos campos, e incluso tener campos que en sí mismos son arrays (contener varios valores) o incluso contener otro documento como valor, o incluso un array de documentos. Esto, entendido bien, nos puede dar una idea de la potencia que ello implica, pues es posible tener en un mismo objeto, de manera incrustada, otros objetos, sin necesidad de implicar a la base de datos en varias tablas, definir claves y relacionar dichas claves. Por ejemplo, imaginemos la clásica relación “Categoría” y “Producto”. En un sistema de base de datos tradicional, se definirían dos tablas:

Tabla categoría:
- idcategoria: integer: PRIMARY KEY
- nombrecategoria: char(30)

Tabla producto:
- idproducto: integer: PRIMARY KEY
- nombreproducto: char(30)
- idcategoria: integer

Internamente, el gestor de base de datos debe estar constantemente velando para que los datos clave sean únicos, no nulos y que no violan las reglas de integridad referencial, realizando complejas operaciones de índices y actualización de éstos. Estas operaciones son transparentes para los usuarios y desarrolladores. Es cómodo, pero sobrecargan los tiempos de CPU y penalizan otras operaciones que pueden ser más importantes.

En una base de datos MongoDB se requeriría únicamente una colección de objetos, cada uno de los cuales puede tener una estructura propia (no tiene por qué ser la misma).

{producto: “Perdiz escabechada”, categoria:[“carne”,”conserva”]}
{producto:”Naranja”, categoria:”fruta”]}
{producto:”Sal”}


De este simple ejemplo se pueden extraer algunas reflexiones:
- El almacenamiento físico gana mucho, al no estar supeditada a una estructura fija y definida. Se pueden omitir claves (campos) si se desea, y los campos de texto ocupan sólo el número de caracteres que contiene, no un tamaño fijo.
- Se prescinde de campos id, que dificultan el entendimiento de los datos.
- Se centraliza todo en una única colección, y no añade la dificultad de las relaciones.
- Un producto puede no estar asociado a una categoría, o bien estar asociado a varias categorías. En este último caso, en una base de datos relacional, requeriría de una tercera tabla intermedia con la colección de relaciones, y el trabajo extra en el código para reconstruir las mismas.
- Si bien el control de la redundancia en las categorías es un esfuerzo por parte del código, en el caso de una base de datos relacional, también habría que hacer un esfuerzo en código cuando se determina si hay redundancia por los errores que emite la base de datos (clave duplicada, infracción de integridad…).
- El modo de almacenamiento es más natural para la máquina y para el humano, pues toda la información está en el mismo documento, en lugar de repartido. Esto evita al código repartir la información (al guardar) y de reunirla (al acceder).
- En un modelo relacional, utilizar id’s reduce el espacio de almacenamiento en tablas extensas (ocupa mucho menos un número que un texto), pero complica el desarrollo y el acceso. MongoDB reduce y optimiza espacio de almacenamiento en los campos de texto, supliendo este espacio e incluso mejorándolo. Asimismo, el código para guardar o acceder a la información es mucho más simple (no hay que realizar relaciones (los típicos join o el uso de varias consultas a varias tablas) ni realizar varias actualizaciones por cada una de las tablas involucradas).

Otro ejemplo de almacenamiento en un documento u objeto sería el siguiente:
{ nombre: ‘Rafael’,
apellidos: ‘Hernamperez Martin’,
fechaingreso: Date(’03-22-2010’),
seleccion: [‘Aprenda MongoDB’,’Flex 4 en una semana’,’AJAX para Dummies’],
comentarios: [{autor: ‘adan3000’, comentario: ‘Buena eleccion’},
{autor: ‘majopero’, comentario: ‘Te has pasado’, puntuacion:5}
]
}


La clave “comentarios” es un array de documentos. Un documento puede contener, asimismo, documentos asociados a una clave. Es lógico suponer que el nivel de anidamiento puede ser tan profundo como uno desee.

El formato de datos utilizado por MongoDB es JSON, una especificación estándar para representar la información. Es similar a la de XML, pero reduce el contenido a expresar y haciendo más legible y natural la interpretación de la información. El último documento en formato XML sería el siguiente:
<documento>
  <nombre>Rafael</nombre>
  <apellidos>Hernamperez Martin</apellidos>
  <fechaingreso>03-22-2010</fechaingreso>
  <seleccion>
    <titulo>Aprenda MongoDB</titulo>
    <titulo>Flex 4 en una semana</titulo>
    <titulo>AJAX para Dummies</titulo>
  </seleccion>
  <comentarios>
    <comment autor=”adan3000” comentario=”Buena elección”/>
    <comment autor=”majopero” comentario=”Te has pasado” puntuación=”5”/>
  </comentarios>
</documento>


Alguno se estará preguntando cómo mantener la consistencia de los datos en las aplicaciones. Por ejemplo, en una aplicación es conveniente evitar al usuario teclear la categoría, pudiendo seleccionar una ya predeterminada en una lista para asegurar que sea unívoca y que no haya multitud de referencias a un mismo valor que esté redundante porque se diferencia en una letra o está mal escrito. Se puede crear una colección de categorías, en un formato muy similar al de una tabla (usando documentos con una única clave), y usar ésta como se haría normalmente, o incluso añadir un documento en nuestra colección cuya clave sea un array de valores posibles. Aunque su estructura no tenga nada que ver con el resto de documentos almacenados en la misma. Se accede a dicho documento dentro de la colección y se extraen los posibles valores. La primera opción es más sencilla y legible. La última es más óptima en cuanto almacenamiento y gestión por parte del motor de base de datos (trabaja en la misma colección y comparte los mismos ficheros). Otra solución intermedia, y a la vez elegante, sería definir una colección exclusiva para almacenar documentos que contengan series de datos maestros (categorías, tipos, etc.)

Otra de las ventajas de utilizar este sistema de información, es que no tienes tantas limitaciones a la hora de escalar la información si los requisitos cambian (cosa que ocurre, pues nadie conoce el futuro). En bases de datos relacionales, añadir nuevos campos a una tabla, o una nueva tabla relacionada o maestra y normalizar una base de datos que lleva ya tiempo en producción, es cuanto menos un engorro y un agujero de problemas.

Una vez se entienden estos sencillos conceptos, el adaptar nuestros desarrollos a este tipo de bases de datos es sencillo, e incluso nos beneficiaremos de una mayor legilibilidad y rapidez.


Paso a paso
El movimiento se demuestra andando, y para aprender a caminar en MongoDB procederemos a realizar, paso a paso, un ejemplo práctico. El propósito del mismo es tener una colección de datos personales llamada “agenda”, dentro de una base de datos llamada “ejemplo”. En el ejemplo se verá cómo crear la base de datos, la colección y los datos, y a continuación se verá como realizar consultas a dichos datos.

Arranque del servidor y de la consola MongoDB

Primeramente, arrancar el servidor de MongoDB desde una consola DOS (para Linux, los pasos son muy similares):

cd c:\mongodb-win32-i386-1.2.4\bin
mongod


A continuación, arrancar la consola de MongoDB (dbShell) en otra consola DOS:

cd c:\mongodb-win32-i386-1.2.4\bin
mongo



Creación de la base de datos y de la colección

Aunque no se haya creado aún la base de datos, utilizar ésta (asumirá que se va a utilizar para ser creada):

> use ejemplo
switched to db ejemplo


A continuación crear un objeto que contendrá un documento, el cual se insertará en la colección “agenda” (aún no creada):

> doc = {nombre: "Rafael", apellido1: "Gonzalez", apellido2: "Martin", telefono: "912406790"}

{
"nombre" : "Rafael",
"apellido1" : "Gonzalez",
"apellido2" : "Martin",
"telefono" : "912406790"
}


El siguiente paso es añadir este objeto (documento) a la colección “agenda”:

> db.agenda.save(doc)

Se puede abreviar el proceso en un solo paso, creando directamente el objeto:

> db.agenda.save({nombre: "Rafael", apellido1: "Gonzalez", apellido2: "Martin", telefono: "912406790"})

Esto equivaldría a la sentencia SQL:

INSERT INTO agenda (nombre, apellido1, apellido2, telefono) VALUES (‘Rafael’, ‘Gonzalez’, ‘Martin’, ‘912406790’)

Automáticamente, MongoDB crea los objetos por asunción. De esta manera, crea la base de datos “ejemplo”, y dentro de ésta crea la colección “agenda”, y dentro de ésta crea y agrega el documento “doc”.


Verificaciones

Para verificar todo lo anterior primero comprobaremos qué base de datos está en uso:

> db
ejemplo


A continuación, listaremos las bases de datos creadas con MongoDB:

> show dbs

admin
ejemplo
local
test


Las bases de datos “admin”, “local” y “test” son las bases de datos que por defecto tiene MongoDB.

La siguiente verificación será comprobar qué colecciones disponemos en la base de datos en uso (“ejemplo”):

> show collections
agenda
system.indexes


La colección “system.indexes” es creada y mantenida de forma automática por MongoDB para el control y gestión de los índices de las colecciones.

Para visualizar solamente las colecciones no internas de MongoDB, se puede usar el siguiente comando:

> db.getCollectionNames()
[ "agenda", "system.indexes" ]


Para conocer a qué base de datos pertenece una determinada colección:

> db.agenda.getDB()
ejemplo


Para conocer qué comandos se puede usar para tratar la colección:

> db.agenda.help()


Consultas a los datos

Para visualizar todos los objetos (documentos) de la colección:

> db.agenda.find()
{ "_id" : ObjectId("4ba8a3be5b3d00000000710f"), "nombre" : "Rafael", "apellido1" : "Gonzalez", "apellido2" : "Martin", "telefono" : "912406790" }


Automáticamente, MongoDB asigna un ID único a cada objeto de la colección (clave “_id”).

Vamos a añadir más documentos a la colección:

db.agenda.save({nombre:"Carlos",apellido1:"Sanchez",apellido2:"Sanchez",telefono:"91240890012",email:"carlosss@hotmail.com"}) db.agenda.save({nombre:"Javier",apellido1:"Cristobal",apellido2:"Nombela",telefono:"925407561",email:"javichuc@yahoo.es"})
db.agenda.save({nombre:"Yolanda",apellido1:"Ballesteros",apellido2:"Lopez",telefono:"925406902"})
db.agenda.save({nombre:"Antonio",apellido1:"Blazquez",apellido2:"Fernandez",telefono:"937607812"})
db.agenda.save({nombre:"Jose Miguel", apellido1:"Carvajal", apellido2:"Gomez", telefono:"983679103", email:"picachu234@gmx.com"})
db.agenda.save({nombre:"Juan Carlos", apellido1:"Blazquez", apellido2:"Gil", telefono:"925403789"})


Lista de todos los objetos de la colección:

> db.agenda.find()
{ "_id" : ObjectId("4ba8a3be5b3d00000000710f"), "nombre" : "Rafael", "apellido1" : "Gonzalez", "apellido2" : "Martin", "telefono" : "912406790" }
{ "_id" : ObjectId("4ba8aac55b3d000000007110"), "nombre" : "Carlos", "apellido1" : "Sanchez", "apellido2" : "Sanchez", "telefono" : "91240890012", "email" : "carlosss@hotmail.com" }
{ "_id" : ObjectId("4ba8ab435b3d000000007111"), "nombre" : "Javier", "apellido1" : "Cristobal", "apellido2" : "Nombela", "telefono" : "925407561", "email" : "javichuc@yahoo.es" }
{ "_id" : ObjectId("4ba8ac3f5b3d000000007112"), "nombre" : "Yolanda", "apellido1" : "Ballesteros", "apellido2" : "Lopez", "telefono" : "925406902" }
{ "_id" : ObjectId("4ba8ac865b3d000000007113"), "nombre" : "Antonio", "apellido1" : "Blazquez", "apellido2" : "Fernandez", "telefono" : "937607812" }
{ "_id" : ObjectId("4ba8acde5b3d000000007114"), "nombre" : "Jose Miguel", "apellido1" : "Carvajal", "apellido2" : "Gomez", "telefono" : "983679103", "email" : "picachu234@gmx.com" }
{ "_id" : ObjectId("4ba8af123433000000003118"), "nombre" : "Juan Carlos", "apellido1" : "Blazquez", "apellido2" : "Gil", "telefono" : "925403789" }


Esto equivaldría a la sentencia SQL:

SELECT * FROM agenda

Cuando la colección contiene múltiples objetos será necesario introducir criterios en la búsqueda. El comando “find” permite pasar como parámetros dichos criterios (en formato JSON), los cuales recogen el par (clave/valor) a encontrar. El siguiente comando localiza todos los objetos en cuyo primer apellido sea “Blazquez”:

> db.agenda.find({"apellido1":"Blazquez"})
{ "_id" : ObjectId("4ba8ac865b3d000000007113"), "nombre" : "Antonio", "apellido1" : "Blazquez", "apellido2" : "Fernandez", "telefono" : "937607812" }
{ "_id" : ObjectId("4ba8af123433000000003118"), "nombre" : "Juan Carlos", "apellido1" : "Blazquez", "apellido2" : "Gil", "telefono" : "925403789" }


Lo anterior equivaldría a la sentencia SQL:

SELECT * FROM agenda WHERE apellido1=”Blazquez”

Mediante el siguiente comando sabremos cuántos objetos tiene la colección:

> db.agenda.count()

En un conjunto de datos, para limitar el número de objetos retornados, se especificaría añadiendo el comando limit():

> db.agenda.find().limit(3)
{ "_id" : ObjectId("4ba8a3be5b3d00000000710f"), "nombre" : "Rafael", "apellido1" : "Gonzalez", "apellido2" : "Martin", "telefono" : "912406790" }
{ "_id" : ObjectId("4ba8aac55b3d000000007110"), "nombre" : "Carlos", "apellido1" : "Sanchez", "apellido2" : "Sanchez", "telefono" : "91240890012", "email" : "carlosss@hotmail.com" }
{ "_id" : ObjectId("4ba8ab435b3d000000007111"), "nombre" : "Javier", "apellido1" : "Cristobal", "apellido2" : "Nombela", "telefono" : "925407561", "email" : "javichuc@yahoo.es" }


El comando count() también se puede añadir a find() para saber cuántos objetos ha retornado:

> db.agenda.find({apellido1:"Blazquez"}).count()
2


En el caso de querer visualizar solamente el primero de un conjunto de datos retornados, se usaría el comando findOne():

> db.agenda.findOne({apellido1:"Blazquez"})
{
"_id" : ObjectId("4ba8ac865b3d000000007113"),
"nombre" : "Antonio",
"apellido1" : "Blazquez",
"apellido2" : "Fernandez",
"telefono" : "937607812"
}


Para especificar más criterios, éstos se separan por comas:

> db.agenda.find({"apellido1":"Blazquez","nombre":"Antonio"})
{ "_id" : ObjectId("4ba8ac865b3d000000007113"), "nombre" : "Antonio", "apellido1" : "Blazquez", "apellido2" : "Fernandez", "telefono" : "937607812" }


Su equivalente en SQL sería el siguiente:

SELECT * FROM agenda WHERE apellido1=”Blazquez” AND nombre=”Antonio”

El comando find() retorna realmente un cursor, el cual puede ser utilizado para un acceso más controlado. El siguiente ejemplo se declara una variable que recoge el cursor del comando find(), situándose antes del primer registro. A continuación se declara un bucle while que se repetirá mientras el cursor tenga elementos o no alcance el final (hasNext()). En este bucle se imprimirá, en formato JSON, el objeto actual sobre el cual está situado el cursor. Mediante el comando next(), el cursor avanzará al siguiente objeto.

> var cursor = db.agenda.find()
> while (cursor.hasNext()) { print(tojson(cursor.next())); }
{
"_id" : ObjectId("4ba8a3be5b3d00000000710f"),
"nombre" : "Rafael",
"apellido1" : "Gonzalez",
"apellido2" : "Martin",
"telefono" : "912406790"
}


El siguiente ejemplo, recoge el cursor y accede directamente al tercer objeto del mismo:

> var cursor=db.agenda.find()
> print(tojson(cursor[3]))
{
"_id" : ObjectId("4ba8ac3f5b3d000000007112"),
"nombre" : "Yolanda",
"apellido1" : "Ballesteros",
"apellido2" : "Lopez",
"telefono" : "925406902"
}


La variable “cursor” se podría ver como un array de objetos, por lo que si se quiere acceder a cualquier clave del mismo, se especifica mediante un punto, como si fuera una propiedad:

> print(cursor[3].nombre, cursor[3].apellido1, cursor[3].telefono)
Yolanda Ballesteros 925406902


Safe Creative #1003235820060

lunes, 22 de marzo de 2010

Primeros pasos con MongoDB

Introducción
MongoDB es una base de datos opensource que está teniendo mucha aceptación por las prestaciones que ofrece en entorno Web 2.0, aunque puede ser utilizada en cualquier tipo de situaciones. MongoDB acerca el sistema de almacenamiento y gestión de datos tipo clave/valor, puliendo la diferencia con respecto a los sistemas de bases de datos relacionales. Este sistema permite una tremenda rapidez y escalabilidad, frente a la funcionalidad de los sistemas de bases de datos tradicionales.

Las principales características de MongoDB son las siguientes:
- Software abierto
- Escalable
- Alto rendimiento
- Alta disponibilidad (puede trabajar en modo maestro-esclavo)
- Orientado a documentos (no es relacional)
- Simplicidad basada en esquemas de tipo JSON
- Consultas dinámicas
- Completo soporte de índices, incluyendo índices secundarios, objetos internos, arrays (cadenas) embebidos, geospacial
- Rápido, actualizaciones in situ.
- Perfilado de consultas
- Almacenamiento eficiente de datos binarios en objetos largos, tales como vídeos o fotografías
- Replicación y soporte a prueba de fallos
- Auto fragmentación para escalabilidad a nivel de nube.
- Agregación compleja mediante MapReduce
- Acceso y gestión mediante drivers en multitud de lenguajes de programación: C, C++, C#, .NET, Java, JavaScript, PHP, Phyton, Ruby, Perl, etc.
- Soporte, formación y consultoría.

En este artículo (que espero sea el primero de muchos), se realiza una pequeña introducción a MongoDB.

Orientación a documentos
La información en MongoDB no se almacena en tablas (con sus correspondiente filas y columnas), si no en colecciones (estructuradas o no) cuyos datos forman parejas de clave y valor. Estos datos se almacenan con un estilo JSON, en formato binario llamado BSON. Un ejemplo de este estilo se puede apreciar en el siguiente documento:

{ nombre: ‘Rafael’,
apellidos: ‘Hernamperez Martin’,
fechaingreso: Date(’03-22-2010’),
seleccion: [‘Aprenda MongoDB’,’Flex 4 en una semana’,’AJAX para Dummies’],
comentarios: [{autor: ‘adan3000’, comentario: ‘Buena eleccion’},
{autor: ‘majopero’, comentario: ‘Te has pasado’, puntuacion:5}
]
}


Una colección sería similar a una tabla, y un documento sería similar a una fila. Habría que distinguir claramente, pues la colección puede tener documentos con estructura similar pero no igual (algunos documentos podrían tener más o menos claves). Asimismo, una única clave podría tener una colección de valores (array o cadena, como en el caso de la clave “seleccion"), o bien podría ser también una sub-colección con sus respectivos documentos (como en el caso de la clave “comentarios”).

La sintaxis en formato JSON es muy fácil de entender, eliminando los problemas de errores que pueden ocurrir en el formato XML (ambos son muy sinérgicos), además de reducir el tamaño de la información a transportar.

Este formato es utilizado no sólo para entenderlos, sino también para gestionarlos y realizar consultas en sus campos internos. Por ejemplo:

db.compras.find({'nombre':'Rafael'})

Nota: si falla, probar con comillas dobles

Esta consulta localizaría todos los documentos dentro de la colección “compras” cuya clave “nombre” tenga el valor “Rafael”.

Otro ejemplo:

db.compras.find({'comentarios.autor':'adan3000'})

Esta consulta localizaría todos los documentos dentro de la colección “compras” cuyo comentario haya sido realizado por el “autor” llamado “adan3000”.


Instalación
Para nuestros propósitos utilizaremos Windows como plataforma de operaciones. También puede instalarse en sistemas operativos OS X, Linux y Solaris (ver instrucciones en http://www.mongodb.org/display/DOCS/Quickstart)

En primer lugar hay que crear la siguiente ruta de directorio: “c:\data\db”. Esta ruta es la ruta por defecto para los archivos de bases de datos.

A continuación descargar el archivo zip (ocupa apenas 13MB) de la siguiente URL:
http://www.mongodb.org/display/DOCS/Downloads
y descomprimirlo en la ruta que deseemos (por ejemplo en C:\ donde creará un subdirectorio llamado “mongodb-winxx-xxxx”).


Arrancar un servidor MongoDB
MongoDB se ejecuta principalmente en su consola. Para ello se accede al modo consola DOS de Windows (pulsar AltGr+R, escribir “cmd” (sin las comillas) y Aceptar).

Acceder al directorio “bin” de donde se descomprimió el fichero zip (ejemplo):

cd c:\mongodb-win32-i386-1.2.4\bin

Ahora, para lanza MongoDB por defecto, ejecutar el ejecutable:

mongod

Con esto, MongoDB accederá a las bases de datos almacenadas en el directorio
c:\data\db y usando el puerto 27017. Si se desea cambiar el directorio de ficheros de bases de datos o el puerto, usar los siguientes parámetros:

mongod --dbpath [rutadirectorio] --port [puerto]

Si acaso saltase el cortafuegos, desbloquear el acceso para poder usarlo.

Para parar la base de datos, pulsar Ctrl+C. Con ello, MongoDB esperará hasta que todas las operaciones se hayan completado, guardando las últimas transacciones y cerrando los ficheros.

Existen otros parámetros que pueden ser usados por el motor de MongoDB:
-h (--help): Muestra información sobre los parámetros permitidos
--logpath rutafichero: Especifica fichero de log
--logappend: añade al log, en lugar de sobreescribirlo
--cpu: log periódico de la CPU y de los tiempos de entrada/salida
--fork: ejecución como demonio
--auth: Activa la seguridad
--noauth: Desactiva la seguridad (por defecto)
--nohttpinterface: Desactiva la interfaz http (localhost:27018)
--master: Designa este servidor como maestro (entorno de alta disponibilidad)
--slave: Designa este servidor como esclavo (entorno de alta disponibilidad)
--autoresync: Resincronización automática del servidor esclavo.
--source servidor:puerto: Para un servidor esclavo especifica dónde está el servidor maestro para la replicación

Una forma sencilla de arrancar el servidor MongoDB sin repetir los parámetros, es añadiendo éstos a un fichero de configuración. El formato del fichero sería el siguiente:

#comentario
parametro1 = valor1
parametro2 = valor 2


Para lanzar el servidor usando este fichero, ejecutar:

mongod –config ficheroconfiguración
mongod –f ficheroconfiguración


Consola de MongoDB
Una vez arrancado el servidor, podemos utilizar la consola de MongoDB para interactuar con las bases de datos. Para ello, acceder al modo consola DOS de Windows (pulsar AltGr+R, escribir “cmd” (sin las comillas) y Aceptar).

Acceder al directorio “bin” de donde se descomprimió el fichero zip (ejemplo):

cd c:\mongodb-win32-i386-1.2.4\bin

Ahora, lanzar la consola de MongoDB:

mongo

(nótese que no tiene la "d" final).

En esta nueva consola, nos permitirá escribir los comandos necesarios para interactuar con el servidor (mongod), de tal forma que podamos gestionar documentos y estructuras o acceder a la información (entre muchas acciones). Cada comando ha de estar acompañado por un “Enter” para su ejecución.

Por defecto se conecta a una base de datos llamada “test” (por defecto).

Para mostrar la base de datos en uso:
db

Para autentificar un usuario (sólo cuando se ejecuta el servidor en modo seguridad):
db.auth(usuario,contraseña)

Para salir de la consola MongoDB, escribir el comando
exit

Para conseguir ayuda sobre los comandos disponibles, escribir el comando
help

Para mostrar las bases de datos disponibles:
show dbs

Para mostrar las colecciones de la base de datos actual:
show collections

Para mostrar los usuarios de la base de datos actual:
show users

Para utilizar una base de datos:
use nombrebasedatos

Para mostrar ayuda sobre los métodos de base de datos:
db.help()

Para mostrar ayuda sobre los métodos para la colección foo:
db.foo.help()

Para mostrar los objetos en una colección foo:
db.foo.find()

Referencias
Sitio oficial de MongoDB: http://www.mongodb.org


Safe Creative #1003225810323

Habemus Flex 4

Ya está disponible la esperada versión 4 de Flex, un framework opensource para desarrollo de aplicaciones RIA.

http://www.adobe.com/products/flex/

sábado, 20 de marzo de 2010

Metodologías tradicionales versus Metodologías ágiles

Durante muchos años he estado gestionando proyectos TI aplicando diferentes metodologías. En las últimas semanas estoy haciendo una toma de contacto con metodologías ágiles, concretamente con Scrum y sus sinergias con TDD y XP (eXtreme Programming). Voy a comentar mis puntos de vista desde un punto de perspectiva crítica y constructiva, producto de años de experiencia como gestor de proyectos TI, comentando puntos fuertes y débiles de ambos tipos de metodologías. He de reconocer, antes de empezar, que aún no he aplicado Scrum a ningún proyecto, tan sólo me he informado sobre la metodologías y algunos casos de éxito a través de manuales, foros y comunidades.

Es obligado hacer una retrospectiva para conocer lo que es una metodología y para qué sirve. No sólo se aplican al mundo del software, sino también a la industria en general y a todo lo que conlleve un proyecto o servicio. Comenzaron a gestarse sobre los años 50, en el ejército estadounidense, como una forma de reducir las consecuencias caóticas de proyectos que se descontrolaban, generando demoras en las agendas, el descontrol de los costes, las sorpresas de riesgos no previstos, la entrega de productos no terminados o de baja calidad y eficiencia. Para ello, se fueron definiendo mejores prácticas, fases bien definidas y normas de obligado cumplimiento. Con ello se pretendía (se pretende), que todo siga un orden establecido, en donde se involucran a ciertos responsables, se recoge una entrada de tareas y documentos, se definen unas tareas clave, y se obtienen unos resultados determinados, imponiendo qué y cómo ha de hacerse.

Han ido apareciendo metodologías a lo largo de las décadas para ir haciendo frente a una cada vez mayor y exigente industria. Así tenemos las ISO, PMI, CMMI, Prince2, Métrica o ITIL.

A lo largo de mis 25 años de experiencia en TI, he aplicado en mis proyectos todas ellas (y alguna propia del cliente), a excepción de ITIL. El resultado ha sido más o menos bueno, ya que si una metodología puede ser buena, puede no serlo el enfoque de qué metodología aplicar y el alcance de la misma. Hablo concretamente de la omisión del "tailoring" (traje a medida). Esto significa que se aplica toda la metodología indistintamente a proyectos pequeños y a proyectos grandes. Así, si un proyecto, en condiciones normales, hubiese durado un mes, al final termina durando dos o tres meses, con un sobreesfuerzo desorbitado en cuanto a documentación y a rectificaciones constantes de los entregables.

Asimismo, aún haciendo "tailoring", las normas y tareas pueden resultar excesivas para lo que realmente se necesita. En este sentido, se está haciendo más trabajo y esfuerzos en documentación, reuniones, actas, etc., que lo que es realmente el trabajo a realizar. Esto llega a desesperar, especialmente a los gestores de proyecto.

Otro problema importante es que en las planificaciones no suele incluirse el tiempo o los esfuerzos de aplicación de las metodologías, tan sólo el trabajo que se requiere para desarrollar el producto. Ello se debe a que muchas veces los clientes se niegan a ver ese trabajo en el project, o que no se prevé o que para ajustar los costes para ganar la oferta se omite este trabajo que puede llegar a ser el mismo o superior al del trabajo de desarrollo.

Otro añadido es que se asume que el jefe de proyecto es también el gestor del proyecto y el que aplica la metodología. Esta es una sobrecarga de trabajo que no se suele tener en cuenta. No es extraño ver un project en el que el jefe de proyecto tiene una dedicación de un 50%, pero en realidad tiene que llevarse trabajo a casa porque se le complica con las otras tareas y no llega a los hitos impuestos.

Lo anterior son sólo algunos inconvenientes de una metodología intransigente, estricta y vetusta, y que sin embargo es impuesta por las empresas para "asegurar la calidad", cuando en realidad es por imagen, creando una "burrocracia" innecesaria, molesta y lapidaria. Las cifras a lo largo de la historia del software están ahí, y aún mejorando las expectativas, hoy en día, tan sólo un tercio de los proyectos acaban en tiempo, y la calidad final siempre es la esperada o la prometida. El resto son proyectos que no acaban, o son ruinosos, o los costes se superan, o se extienden en el tiempo, o el producto es defectuoso, o la calidad no se cumple... ¿Qué ocurre entonces? Las metodologías, aún aplicándose no garantizan completamente el propósito para el cual fueron creadas. ¿Cómo es posible ésto? Si las mejores prácticas definidas en la metodología son recogidas de proyectos que tuvieron éxito. Si la idea de las prácticas son buenas, y está demostrado que funcionan.

Hay explicaciones que pueden ser más o menos discutibles. Una práctica, de forma aislada, puede funcionar en un proyecto, pero en otro proyecto puede no funcionar o funcionar a medias. También influye lo que apunté antes, y es que en la planificación no se incluyen las tareas de la metodología, y si las tareas del desarrollo ya están infradimensionadas para una oferta ganadora, estamos hipotecando el tiempo y el esfuerzo real a costa de tiempo y esfuerzo extra que no es pagado ni agradecido. Las prisas y la sobrecarga no son buenas, y muchas prácticas se omiten o se realizan parcialmente o mal para poder llegar a los hitos.

Voy a comentaros una anécdota que me pasó hace unos años en un importante banco que impone su propia metodología, y tienen a todo un departamento velando por esta metodología. Estaba con un diseño conceptual de nuestro aplicativo. Este diseño fue rechazado cinco veces en una semana, una vez cada día, porque no cumplía los requisitos de calidad de la metodología, la cual había sido cambiada sin avisar ese mismo día o la tarde anterior, mientras adaptaba el diseño a los nuevos requerimientos. Obviamente, eso retrasó mi proyecto una semana más, con el consiguiente cabreo mío, de mi equipo y del responsable del proyecto en el cliente. Se convocó una reunión a un alto nivel, con la protesta de estos hechos. Increíblemente, la cabeza de la organización dictaminó que el departamento de metodología tiene prioridad sobre las decisiones, y que la calidad era la filosofía suprema de la entidad, y que había que bailar a su son, nos gustase o no. Por tanto, nuestro aplicativo o cualquier aplicativo debía ceñirse a los últimos requisitos de la metodología. Entonces dije algo por lo cual me crucificaron: "bien, entonces, ¿cuántos aplicativos que se realizaron el año pasado, o hace dos años, o a lo largo de los últimos cuarenta años en la entidad, cumplen con esos requisitos? Por esa regla de tres, hay que adaptar todos los aplicativos del banco para que cumplan con la metodología liberada esta misma mañana, porque no la cumplen". No hay nada peor que tener a un rebelde que tiene razón.

Si bien el concepto y la idea de estas metodologías son buenos, lo son en proyectos y productos estables en el tiempo, tales como una construcción, como un edificio, un puente, un túnel, etc.

Para la industria de TI, supone un lastre muy importante, ya que el software y el hardware son muy dinámicos e innovadores, cada día aparecen nuevas tecnologías y proyectos, y los productos tienen un período de vida muy corto. Hoy en día no hay muchos proyectos que duren más de un año. Suelen ser proyectos de muy corta duración, de apenas unos meses. Y no es sólo por la tecnología, sino también por la dinámica del negocio, que requiere nuevas ideas y prácticas para llevarse a cabo. En proyectos tan cortos, demorarse un sólo día impacta de forma importante en los costes y en el margen de beneficio. Asimismo, la sobrecarga de una metodología tradicional puede exasperar hasta lo indecible, pues cuanto más corto es el proyecto, más porcentaje de dedicación requiere la metodología. Para que no haya malentendidos con este último argumento, imaginaros un proyecto de apenas un mes. Aplicar una metodología a rajatabla, puede llegar a superar el 50% de esta dedicación.

Entonces uno se plantea si no hay algo más flexible y ágil para aplicar a los proyectos actuales. Indagando uno encuentra las metodologías Agile, entre las que se encuentra Scrum. Cuando alguien acostumbrado a metodologías tradicionales toma contacto con Scrum puede sorprenderse e incluso ser reacio a las ideas y prácticas que profesan, pues suponen un cambio importante. Con una mente abierta, uno descubre que realmente son ágiles y flexibles, y que van directamente "al tajo", en lugar de entretenerse en cosas que no aportan mucho o nada. A mí, por lo menos, me parecen de sentido común, y si me diesen la oportunidad, recomendaría este tipo de metodologías.

Voy a dar un repaso somero a algunas de sus características sin entrar en detalles. Ante todo, en estas metodologías prima la sencillez y el sentido común. Por ejemplo, en el caso de Scrum, se realizan sprints o períodos de trabajo y entregables cortos, de apenas 3 semanas. Al principio de un sprint se reúne todo el equipo con el dueño del producto y el cliente, donde se revisan las historias (actividades funcionales), se establecen las prioridades de las mismas y los puntos (días de esfuerzo) de las mismas. Los puntos son estimados exclusivamente por los componentes del equipo. Se estiman cuántos puntos se pueden realizar durante ese sprint, y se deciden qué historias formarán parte en ese sprint. Cada sprint tiene al final una demo con las historias comprometidas.

Cada día, el equipo tiene una reunión muy breve (media hora, quince minutos), y sobre una pared se van actualizando el estado de las historias: cuáles están pendiente de acometer, cuáles están en curso y cuáles están terminadas. Asimismo, se va ajustando la estimación de las tareas de la historia, y en un gráfico de tipo breakdown, se va observando las desviaciones. Todo es muy participativo y colaborativo. En el equipo, no hay distinción jerárquica típica. Todos hacen algo y participan en los problemas y decisiones.

Quizá más de uno piense que si sólo se desarrolla, no hay documentación, o que la calidad puede ser pésima. Ese fue mi primer pensamiento, pero no es así. Se desarrolla la documentación suficiente, pero no una documentación excesiva como ocurre en otras metodologías. En cuanto a la calidad, aquí entra lo que se conoce como TDD, un framework que permite definir antes de tirar una sola línea de código, los ejemplos que han de cumplir las historias. Esto es, que en lugar de un análisis funcional extenso, redundante, excesivo y lleno de interpretaciones dispares, se define qué cosas debe hacer el aplicativo y en posibles escenarios. Esta información se centra en el qué y no el cómo. No se va al detalle de la interfaz de usuario ni en el modelo de datos. Se escribe un lenguaje de frases de pocas palabras, que va directo al grano ("se añade el producto seleccionado al carrito", "búsqueda combinatoria con el tipo de producto y el precio máximo", "al superar el saldo da mensaje 'no tiene saldo suficiente'). Estos ejemplos definen las funcionalidades que se necesitan así como los factores a cumplir que sirven como base para un plan de pruebas. No hay un lenguaje o una jerga. El desarrollador entiende estas especificaciones, y el usuario también. Ahora el desarrollador crea el código para que estos ejemplos se cumplan, y se definen los recursos de pruebas automatizados para llevarlo a cabo. Una vez el código se realiza y cumple con los ejemplos (y pruebas), se realiza una refactorización del código, eliminando ambigüedades y partes repetidas, optimizando el código para que cumpla nuevamente con dichos ejemplos. Posteriormente, si hay tiempo se realiza una retrospectiva para afinar aún más.

Así pues, al final del script tenemos un producto sólido, estable y de calidad (también se aplican pruebas de caja negra, de estrés, etc.), con lo que se pueden acometer nuevas historias con la seguridad de que lo entregado cumple en su mayor parte con los requisitos de calidad. Obviamente, no todo el código es perfecto 100%, y que el usuario pueda encontrar errores a posteriori. Estos errores son mínimos (situaciones no previstas en los ejemplos) o mejoras, y el desarrollo continúa mientras las historias entregadas pueden ser ya utilizadas por los usuarios, en lugar de esperar varios meses para una entrega final.

¿Qué ocurre con los diseños? Bueno, los diagramas de clases, por ejemplo, se crean al final, con el código ya funcionando y libre de errores, realizando una ingeniería inversa. Por experiencia, coincido con todos los gestores de Scrum, en que el diseño preliminar ralentiza el desarrollo, y que un diagrama de clases va a estar contínuamente cambiando a medida que se desarrolla, ralentizando aún más nuestras tareas y con el riesgo de terminar con una documentación desactualizada o imprecisa. Veo bien hacerlo a la hora de refactorizar, pues se ve claramente dónde se puede mejorar y optimizar el código, y además el desarrollo es reciente, con lo que las peculiaridades y detalles son frescos.

Existen muchos detalles interesantes acerca de este tipo de metodologías. He expuesto quizá las que me han parecido más interesantes y prácticas. Desde luego, puede chocar con nuestra tradicional forma de pensar, pero si abrimos nuestra mente veremos las posibilidades y los beneficios de estas prácticas. Sobre todo, se busca agilidad y flexibilidad.

Siendo crítico, se pueden encontrar algunas pegas. La primera de ellas es que normalmente los clientes son los que exigen la metodología a aplicar, e intentar convencerles de que cambien a Scrum puede llevarnos a distanciarnos y a perder proyectos en el futuro. Hay que adaptarse a sus metodologías, nos guste o no.

Otro problema que veo es que aún no exigiendo la metodología a aplicar, si proponemos Scrum hay que argumentar todos los beneficios en las ofertas. Si otros licitadores proponen una metodología tradicional y reconocida, es más que probable que opten por ésta por la "tranquilidad" y la "garantía" que da una metodología ya consagrada y extendida.

El cambio de mentalidad o de ideas choca, y ese es un obstáculo. Veo más viable implantar una metodología Scrum en un cliente que no sea exigente en este sentido, o que el cliente conozca esta metodología y la desee aplicar.

Otro punto muy importante y a considerar, es que para llevar a cabo los sprints, previamente hay que tener muy bien definidas las historias, y que éstas estén muy claras para el dueño del producto y el cliente, para no llevarnos la sorpresa de cambios de cosas que no se han tenido en cuenta. Esto no suele ser así ni en la metodología tradicional, donde incluso teniendo el documento de requisitos, el documento funcional y el documento técnico y una demo de interfaz de usuario, encontraremos cambios de especificaciones, errores y mejoras durante el desarrollo o durante la fase de pruebas.

Aunque expertos en Scrum coincidan en que el desarrollo sin preocuparse por la arquitectura, yo creo que no hay que ir del extremo de tener una arquitectura robusta y fuerte antes de plantear el proyecto, al extremo de ir desarrollando sin arquitectura definida, y montar ésta a medida que va surgiendo. Hay que tener por lo menos una arquitectura mínima prediseñada y definida, y sobre ella ir construyendo el resto. No es bueno ir haciendo las cosas sobre la marcha, ya que no se prevén riesgos, algo crítico y fundamental en todo proyecto. Las metodologías tradicionales en este punto son muy buenas, aunque por exceso demoren el inicio real del desarrollo. En Scrum hay una previsión mínima, y lo acertado de esta previsión y no llevarse sorpresas dependerá de la experiencia y de los conocimientos de la arquitectura y de las tecnologías que tenga el equipo. En este punto sobresale Scrum, pues la participación del equipo puede discernir riesgos que un jefe o un gestor de proyectos pueda no abarcar. Pero, repito, el equipo Scrum debe tener mucha experiencia en esa arquitectura y en esa tecnología, y yo lo desaconsejaría en caso de tener un equipo nuevo, no hay capacitación suficiente, o el escenario de arquitectura y tecnología son nuevos.

Algo que podría rechazar un cliente es que la documentación no sea tan elaborada y tan extensa como la de una metodología tradicional. Si terminado el proyecto surge algún problema o un cambio fuera de garantía y ya no hay relaciones con nosotros, y hay que tirar de otra empresa, ¿va a ser suficiente la documentación "básica" que hemos generado como para que el legado no sea problemático? Esa duda es un punto crucial a la hora de que un cliente pueda optar por Scrum, ya que PMI o Métrica (por poner algún ejemplo de metodología) genera una documentación abundante. En este punto hay que ser cuidadoso, pues si bien una documentación excesiva es hasta contraproducente (por la interpretación y el tiempo que requiere su estudio y capacitación), una documentación menos extensa debe ser más concisa y libre de interpretaciones. Esta documentación, aún siendo buena, podría chocar si en el futuro el legado lo recoge un equipo que no haya trabajado con Scrum y siga trabajando a la antigua usanza. Bajo mi punto de vista, al igual que se incorpora un rol especial para las pruebas en un equipo Scrum, el rol de documentador estaría bien para dar más consistencia en este sentido. Una idea interesante, para no aburrir, es alternar en cada sprint este rol a un miembro del equipo.

En los últimos tiempos hay una modalidad de trabajo en la que Scrum podría apoyar de forma significativamente, incluso mejor que las metodologías tradicionales. En algunas organizaciones se prevé un presupuesto anual, donde el responsable de cada departamento lo invierte en el desarrollo de actividades que libera una oficina de proyectos. Este presupuesto se puede invertir en bolsas de horas. El trabajo está dirigido principalmente a las tareas a abordar por un equipo a lo largo del tiempo, de forma constante. El trabajo se extraería de una pila de actividades (puede ser de varios proyectos), definiendo historias, y con arreglo al ritmo de puntos a acometer por presupuesto y tiempos, poder ejercer Scrum. En este sentido, Scrum sería el mejor candidato.

Las metodologías nos ayudan a ejecutar un proyecto o un servicio con mayores garantías de éxito. Son una herramienta, y conocer dicha herramienta y usar debidamente dicha herramienta es responsabilidad nuestra. Usar una metodología sin tener en cuenta las necesidades reales del producto a elaborar, nos llevará a deformar las expectativas de la planificación, bien demorando los tiempos, incrementando los costes y generando un producto con errores o de baja calidad.

Una metodología puede no ser mejor ni peor que otra. Es nuestra visión de cómo plantear y desarrollar el proyecto la clave para optar por una u otra metodología. Si el proyecto es corto o se requieren entregables constantemente, Scrum, desde luego, es una opción muy buena. En un proyecto muy extenso también recomendaría Scrum, ya que ahorraría en tiempos de ejecución y en costes, pero podría caer en el riesgo de crear un producto insuficiente al estar realizado casi sobre la marcha. Para ello, una metodología tradicional define bien desde el principio el producto y los controles necesarios para asegurar de forma constante que el producto se realiza acorde a ese diseño.

Lecturas recomendadas
Scrum y XP desde las trincheras. Por Henrik Kniberg
Flexibilidad con Scrum. Por Juan Palacio
Diseño ágil con TDD. Por Carlos Blé Jurado

Safe Creative #1003205787195

miércoles, 17 de marzo de 2010

Naturaleza por los números

Espectacular vídeo que muestra las relaciones entre la naturaleza y las matemáticas. Entre ellas se encuentra la espiral Fibonacci, la proporción Áurea (creo que la usaban los renacentistas, especialmente Leonardo DaVinci), el ángulo áureo o las telesaciones de Voronoi.



La explicación de la animación la encontrarás en: http://www.etereaestudios.com/docs_html/nbyn_htm/about_index.htm

NOTA: Sería interesante encontrar algo similar sobre Möbius

martes, 16 de marzo de 2010

Conferencia Agile-Spain 2010

El próximo 10 de Junio tendrá lugar en el Campus E.U. Informática de la Universidad Politécnica de Madrid, la primera Conferencia sobre Agile en España. Es una cita muy interesante para conocer las metodologías ágiles, intercambiar experiencias con otros profesionales o conocer a expertos.



Para más información: http://conferencia2010.agile-spain.com/

Humanum est

Si quieres conocer a una empresa, fíjate en sus empleados. Si su conserje o su señora de la limpieza están alegres, sin duda alguna esa empresa es un lugar donde prosperan las relaciones humanas, donde respeta al individuo, donde se generan ilusiones y grandes ideas, donde el trabajo no sólo será de calidad, si no también productivo. Si eres un proveedor o un cliente, este indicio te dará cierta garantía y tranquilidad de una empresa honesta que dará pocos problemas, y cuya colaboración en los negocios será fructífera.

Una empresa es un ente que ha de relacionarse y convivir con otros entes (clientes y proveedores), colaborar en proyectos y crecer al unísono. Al igual que un ente vivo, está formado por empleados cual células. El estado de salud interno se propaga hacia afuera y viceversa.

Al igual que un cuerpo con sus miembros y sus órganos, la empresa está formada por divisiones, secciones, departamentos y/o unidades de negocio. La salud de cada una de estas partes afectará de forma directa al resto. Si tienes una lesión en una mano, podrás seguir viviendo con el resto, pero no estarás al 100%, a no ser que penalices al resto con un sobre-esfuerzo para suplir el trabajo de esa mano.

Habrá momentos en que alguna célula tenga algún problema, y dicho problema será sentido en diferentes grados en el resto del cuerpo. Otras células tendrán que hacerse cargo de sus tareas, y ese sobre-esfuerzo afectará a su rendimiento y, por ende, al resultado final (retraso en tareas, calidad de las mismas, etc.)

Esta pequeña introducción metafórica destaca que todo está relacionado. No estoy contando nada nuevo, tan sólo haciendo un repaso para después plantear algunas reflexiones.

En todo proyecto hay un grupo de personas involucradas. El éxito del proyecto es un porcentaje equilibrado de conocimientos y/o habilidades de sus miembros, de las relaciones interpersonales de dicho grupo, y de agentes externos. La aportación de todas estas personas es primordial, desde la señora de la limpieza, el técnico que cambia las bombillas o arregla el aire acondicionado, hasta el mismísimo presidente.

Muchas veces se ve sólo negocio y números. Un empleado es un número. Un sueldo es un número en rojo o negativo, y el rendimiento o la productividad de su trabajo debe superar con creces ese color para poder producir negocio. Cuando se genera negocio, la empresa gana dinero, y si gana dinero, puede pagar la nómina, con lo que el empleado también gana.

Pero la empresa necesita al empleado para poder generar negocio, porque para crear negocio se requiere de sus conocimientos y habilidades, desarrollando un producto o un servicio que los clientes compran. El empleado es, pues, una herramienta para producir negocio. Sin esa herramienta no se produce producto o servicio. Sin ese producto o servicio no hay razón para que el cliente pague algo. Como toda herramienta, ha de ser utilizada comedidamente. Hay quien utiliza la herramienta sin miramiento, machacándola y destruyéndola en muy pocos usos. Hay quien cuida de su herramienta, sin forzarla, usándola cuando es necesario, cuidándola.

Hay casos en las que para conseguir una mayor productividad, margen de beneficio o una mayor reducción de costes, un empleado es espoleado hasta la humillación. Se pierde el respeto hacia esa persona, se la rebaja, se la anula, se la menosprecia. Estas prácticas son extremas y, por suerte, no son muy habituales, y suelen ser aplicadas por jefes que sufrieron o sufren el mismo tratamiento, y que no tienen una personalidad propia o ésta es muy débil y sumisa. Además de la tensión, esta situación produce cansancio, bajo rendimiento, baja productividad, deslealtad hacia la empresa, mala publicidad, y que en cualquier momento ese empleado abandone de la empresa dejando todo sin terminar. Lo peor de todo: el "mal rollo" es contagioso, y se extiende a otros compañeros que, o bien sufrirán el mismo tratamiento, o bien estarán afectados por empatía o por la rumorología, o terminarán cambiando de empresa.

En el sector de las consultoras se suele externalizar a los empleados. Éstos se sienten abandonados en las oficinas de un cliente, donde el trabajo se lo da el cliente y con quien trata es con el cliente. La empresa que le paga la nómina no tiene presencia, y solamente se tiene contacto con ella cuando una vez al mes se pasa alguien (un gerente o un compañero) con la nómina, o mediante algún correo extraordinario o para el kick off anual. Aunque te digan: "puedes contar con nosotros para lo que quieras, y si hay algún problema llámanos"; en realidad sólo se preocupan si se pierde al cliente, o el contrato. Ese empleado se siente abandonado, y se identifica únicamente con el cliente, que en muchos casos, al ser quien paga, va a ser quien te exija que eches horas "by the face" y que saques más por menos.

Sin embargo, la mejor productividad viene por parte de un empleado satisfecho. Y dicha satisfacción se logra mediante el respeto y mediante unas relaciones interpersonales buenas. El ambiente en el trabajo es muy importante, así como el compañerismo y un líder que sepa canalizar las inquietudes de los empleados en su ámbito profesional. Lo mejor de todo: el entusiasmo también es contagioso.

El éxito de una empresa no es sólo de una cabeza pensante, de un director, de un gerente o de un comercial. El éxito de una empresa es el conjunto de pequeños éxitos individuales, pero, sobre todo, colectivos. Házlo por los demás y por ti. Si tú ganas, yo gano y ganamos todos. Ese es el espíritu.

Para conseguir ésto, el empleado no es una simple herramienta. Es una persona, es un compañero, es un ser con el que convives muchas horas cada día. Como tal, no hay que utilizarle ni manipularle para conseguir algo, si no convencerle para que se sienta parte del proyecto, que su aportación es importante, que él es importante, y que va a tener la oportunidad de demostrarlo y de crecer profesionalmente.

Esto se cultiva en el día a día. Acordarse de su cumpleaños, o preguntar por su hijo enfermo, o dar el pésame por una pérdida, o qué tal le fue el fin de semana, o qué tal su viaje a Toledo... Estas pequeñas cosas hacen grande a quien lo recibe, y aún más a quien lo emite. Se gana confianza y lealtad, y son sólo unos pocos minutos de tiempo, pero que causan en efecto motivador muy importante.

En lo profesional yo suelo tener mucha comunicación con mis compañeros. Antes de empezar un proyecto hago una reunión para darles a conocer el mismo, cómo se ha planteado, cómo lo ven, qué podemos hacer para mejorar, qué riesgos podemos detectar, qué herramientas o técnicas podemos poner en marcha para poder conseguir los objetivos, qué ideas pueden aportar, etc. Una vez a la semana, reunión de seguimiento donde cada uno expone lo que hace y cómo avanza, si ha detectado problemas, o aporta experiencias o ideas para solucionar problemas de algún compañero, ver qué tareas quedan, cómo va el avance en general, si un compañero puede echar una mano a otro compañero, etc. Aquí lo importante es ver que todos somos útiles, y cómo podemos ser útiles a los demás.

Un elogio sincero siempre es bien recibido, y la motivación crece. También ayuda, de vez en cuando, asignar alguna tarea importante a algún compañero del equipo, para darle la oportunidad de hacer algo nuevo y estimulante, de crecer profesionalmente, de ser importante y bien considerado, que se confía en él. Esto es recíproco, y esa persona motivada va a ser productiva, realizará un trabajo de calidad y aportará valor añadido con nuevas ideas. Un axioma que siempre cumplo: los elogios y el reconocimiento en público, y los "malos rollos" en privado.

A veces, lo estrictamente personal puede afectar a lo profesional. Al igual que los problemas profesionales pueden entrar en casa, los problemas personales también pueden entrar en la empresa, afectando a la actitud del empleado, y por consiguiente a su ánimo en el trabajo y a su rendimiento, contagiándolo al resto del equipo y al proyecto. A muchos les sorprende que cuando detecto un problema de este tipo mi reacción no sea drástica. Entiendo que cuando uno pasa una mala racha lo primero que necesita es comprensión. Por ello, suelo reunirme en privado con él, y le explico que he detectado un problema por su parte que está afectando al resto de compañeros y al proyecto, que si es un problema en el que pueda ayudarle o si necesita algunos días para ordenar su vida que lo pida. Ante todo se le manifiesta que hay un problema, que se le entiende y que se le da una oportunidad para solucionarlo. Si el problema persiste, la siguiente reunión es más seria, exponiéndole que el problema persiste y que se le ha dado una oportunidad y tiempo para solucionarlo. Se le vuelve a insistir en que si necesita alguna ayuda para resolverlo que puede contar la empresa, y que se le vuelve a dar una nueva oportunidad con el mensaje claro de que no se le va permitir que el proyecto se exponga a peligro, ni que se genere "mal rollo" entre los compañeros por su actitud. Si el problema persiste... bueno, se pone en práctica las medidas necesarias para atajar el problema y poder continuar el proyecto sin el problema.

Como persona me gusta sentirme bien con los demás, y que los demás se sienten bien conmigo. En el trabajo me gusta sentirme importante, que lo que hago es en beneficio de todos y de mi mismo. Me gusta la oportunidad de poder demostrar lo que puedo llegar a hacer, de ser creativo, de tener ideas interesantes que puedan ponerse en marcha, de que mi opinión sea importante y tenida en cuenta, de que reconozcan y valoren mi trabajo, de tener la oportunidad de aprender nuevas cosas y de crecer profesionalmente. Con estas pequeñas cosas, mi sueldo me parece secundario, que mis funciones no sean las que me gustaría llegar a tener, así como el hecho de trabajar a cuarenta kilómetros de casa e invertir dos horas de viaje todos los días. Con estas pequeñas cosas es como si me sintiera en un hogar al que me motiva ir todos los días, donde volver a reunirme con personas a las que aprecio y que me aprecian, donde realmente uno es feliz, más que haciendo lo que me gusta, gustándome lo que hago.
Safe Creative #1003165759447

lunes, 15 de marzo de 2010

jueves, 4 de marzo de 2010

Producción social como una nueva fuente de creación de valor económico

Desde opensource.com leo un interesante artículo sobre el beneficio de la producción social en la economía y en la sociedad, donde el software libre y el código abierto aportan su mayor potencial. El vídeo, aunque esté en inglés, es bastante claro y elocuente.



En este corto vídeo, Yochai Benkler expone un enfoque útil de lo que él denomina "producción social".

Benkler expresa que, en el pasado, los prominentes marcos transaccionales para intercambio eran largamente categorizados como:
- Precio del sistema: un sistema de intercambio basado en el mercado, descentralizado.
- Jerarquía firme: un sistema de intercambio basado en el mercado, centralizado
- Gobierno/sin beneficio. Un sistema de intercambio no basado en el mercado, centralizado.

Antes de que el coste de la comunicación cayera precipitadamente, Benlker sugiere que era demsaidao caro tener un sistema de intercambio de producción social descentralizado. Hoy, sin embargo, citando proyecto de código abierto como SETI y Apache, él reivindica que el compartido social y el intercambio está emergiendo como un factor significante y sostenido de producción.

Aún más, la producción social crea una nueva forma de competición para firmas que operan en el marco centralizado basado en el mercado.
- Compartir creaciones (en ficheros) mediante punto a punto (peer-to-peer) está compitiendo con la industria de grabación.
- El sofware libre y el código abierto están compitiendo con las compañías TI tradicionales.
- La telefonía IP está compitiendo con la industria de telecomunicaciones tradicional.

Lo que nosotros estamos dando aquí como testimonio es la emergencia de la producción social como un cuarto marco transaccional.

Benkler expresa que la producción social no es una moda pasajera: es un hecho. Mientras representa una nueva forma de competitividad de incumbencia, también representa una nueva fuente de oportunidades para todo el mundo.

La cuestión que él nos deja es esta: ¿Cómo se desarrolla la economía de este nuevo modelo de producción social al lado de la de la industria de la información tradicional?




Título original: Social production as a new source of economic value creation
Autor: Toni O'Driscoll
Artículo original: http://opensource.com/business/10/2/social-production-new-source-economic-value-creation

martes, 2 de marzo de 2010

Aplicaciones libres para PYMES

CESLCAM (Centro de Excelencia de Software Libre de Castilla la Mancha), junto con la Junta de Comunidades de Castilla-La Mancha, han publicado una lista de software libre para las PYMES, que me ha resultado muy interesante:

OFICINA

Suite ofimática
OpenOffice

Organizador de información
Sunbird

Visor y generador de documentos
Evice
pdfCreator

Retoque de imágenes
Gimp


HERRAMIENTAS EMPRESARIALES

ERP (Gestión integrada)
Abanq
Oasis
OpenBravo

CRM (Seguimiento de clientes
SugarCRM
vTiger

Comercio electrónico
OsCommerce

Gestor de tareas
OpenProj
Planner

Herramientas colaborativas
Zimbrz
Egroupware

Gestión de proyectos
Redmin
DotProject

Gestor de contenidos
Joomla
Typo3

Gestor documental
Alfresco
Nuxeo


SEGURIDAD

Antivirus
ClamAv Antivirus
ClamWin

Copias de seguridad
rsync
Bacula


COMUNICACIONES

Navegadores
Firefox

Correo electrónico
Thunderbird
Evolution

Mensajería
Pidgin
aMSN


UTILIDADES

Grabación CD/DVD
Brasero
Infrarecorder

Reproductor Multimedia
Mplayer
VLC

Twitter migrará de MySQL a Cassandra

Leo en Kushelmex la siguiente noticia

"Ryan King es ingeniero de Twitter y le dijo al blog MyNoSQL que están planeando cambiar su bases de datos en MySQL por una base de datos Cassandra debido a la escalabilidad y a la gran comunidad de desarrolladores .

Actualmente Twitter funciona en un cluster de servidores MySQL con un sistema de cache que cada vez es menos efectivo debido a su crecimiento. Necesitan un sistema para crecer de forma mas automática y de alta disponibilidad (¿no mas fail wail?).

El crecimiento en el numero de tweets en comparación al año pasado ha sido de 20 veces subiendo de 2 millones al día a 50 millones por día en enero de este año.

La idea de cambiar de base datos también lleva de la mano el disminuir el downtime que en los últimos 12 meses sumo 23 horas con 45 minutos (por los 12 meses). En comparación al 2008 el downtime llego a 84 horas convirtiéndose en un récord negativo en comparación a otras redes sociales.

Cassandra fue desarrollado en un principio por los de Facebook y es un repositorio hecho en Java, la tecnología es similar a la ofrecida por otras bases de datos NoSQL como MapReduce y Hadoop.

Otro que esta dejando las bases de datos MySQL es Digg que también estara migrando a Cassandra. Estas bases de datos también son utilizadas por Cisco Systems, Rackspace e IBM.

Actualmente Twitter esta migrando su tabla mas grande que es la de status donde se almacenan los tweets y retweets de todos los usuarios, para evitar problemas estarán implementando nuevos recursos sobre ambas bases de datos para no caer en imprevistos. Cuando ya no encuentren bugs exportaran la BD y la importaran de lleno en Cassandra.

Todos los cambios se están realizando en ambientes de prueba , hasta que no encuentren mas fallas podrán poner la BD Cassandra en producción."



Hace algún tiempo (http://rafinguer.blogspot.com/2009/11/movimiento-nosql-la-alternativa-las.html) analicé la tendencia de las bases de datos NoSQL, como una alternativa a las bases de datos relacionales, debido a su potencia y escalabilidad en grandes sistemas, especialmente los que requieren sites populares de internet, tales como Amazon, Facebook, etc.

Software por la patilla

VideoPad
Sencilla y práctica herramienta para crear tus vídeos, mezclando imágenes, clips y música. Para Windows.


DVD Styler:
Sencilla y práctica herramienta para crear tus propios DVD's, permitiendo montar tus menús; tus películas en MPEG2, MPEG3, divX, XVid; y mezclar sonido en formato MP3, MP3 y AC3. Para Windows y Linux.


Videolan:
Para muchos, el mejor reproductor de vídeo y audio que existe, que no necesita de codecs terceros. Para Windows, Linux y MacOS


CDBurnerXP Pro:
Fantástica utilidad para grabar en CD, DVD, BlueRay y HD-DVD información de datos, de audio o imágenes. Para Windows.


Terragen:
Espectacular aplicación para generar paisajes realistas en 3D.


pCon-Planner:
Estupendo programa para diseñar decoración de interiores. Para Windows.


PortableApps
Lleva contigo siempre tus herramientas imprescindibles en un pendrive: navegador web (Mozilla Firefox), cliente de correo electrónico (Mozilla Thunderbird), cliente FTP (Filezilla), mensajería instantánea (Gaim), ofimática (OpenOffice), procesador de textos (AbiWord), gestor de tareas (Sunbird), etc.


WinUtilities Free:
Completo conjunto de herramientas imprescindibles para el mantenimiento de tu PC: limpiador de disco duro, registro de Windows, accesos directos, historial de Windows e historial de navegadores; buscador de archivos duplicados, desinstalador de programas, defragmentador de disco, optimizador de memoria, limpiador de archivos en el inicio de Windows, eliminador de BHO (objetos añadidos al navegador), borrado seguro de archivos y recuperador de archivos borrados.


Auslogics Boot Speed
Herramienta imprescindible que permite, entre muchas otras cosas, acelerar el arranque del ordenador, la velocidad de Internet, optimizar el navegador, reparar y limpiar el registro de Windows; limpiar, liberar espacio y defragmentar los discos, controlar los recursos del sistema o proteger la privacidad. Casi nada. Para Windows.


Auslogics Disk Defrag Screensaver
Excelente y original utilidad que te permite defragmentar el disco duro a modo de salvapantallas. La defragmentación permite organizar la información de los archivos del disco, siendo más rápido y accesible. Para Windows.


Auslogics Registry Cleaner
Imprescindible herramienta para limpiar, reparar y defragmentar el registro de Windows.


Back Track Linux:
Excelente distribución de Linux que permite auditar la seguridad de los equipos y de la red.


System Rescue CD:
Excelente distribución de Linux en LiveCD, que permite recuperar sistemas y datos. Entre sus muchas utilidades, permite recuperar y gestionar particiones o realizar backups.


Notepad++:
Sin duda alguna, uno de los mejores editores de texto, imprescindible para programar, ya que tiene características de autocompletado, WYSIWYG, coloreado de sintaxis, multidocumento, expresiones regulares, zoom, marcado, macros y soporte para multitud de lenguajes de programación. Para Windows.

lunes, 1 de marzo de 2010

Tras las bambalinas del software libre

Este artículo va a dar qué pensar y seguramente provoque algún tipo de polémica, especialmente entre los fanáticos del software libre. Mi anticipado aviso, y mi anticipado deseo de hacer crítica constructiva y expresar mi opinión desde mi humilde experiencia y la de otros compañeros. Con este artículo no deseo descalificar algo que amo, si no plasmar y mostrar algo de la parte que nadie ve o que no quiere ver en el mundillo del software libre. Que no guste lo que aquí se explique no significa que sea mentira, y ocultarlo es un error.

Sirva de antemano que amo el software libre, y mi segunda recomendación es su uso. La primera recomendación se basa analizar qué utiliza un usuario, con qué se siente a gusto, qué sistemas utiliza, y si un cambio a un producto de software libre no le va a impactar mucho. En la mayor de las veces, suelo hacer combinaciones entre software propietario y software libre, cosa que impacta lo mínimo en este sentido, y cuyas integraciones son hasta beneficiosas. ¿De qué sirve ahorrar dinero en licencias, si luego el usuario se lía y no sabe usar el nuevo software o no le gusta o no se siente a gusto con el mismo? ¿Para qué cambiar a un producto libre si el de pago a lo mejor es más estable, tiene más funcionalidades y tiene un soporte mucho mejor? En algunas ocasiones, tras implantar un sistema libre, el usuario tras su formación y su experiencia, me ha pedido volver a un sistema que ya conocía, fuera de mejor o peor calidad, o más caro o más barato. Hay que contar primero qué es lo mejor para un cliente, y qué es lo que quiere, no sólo a corto plazo, si no también a largo plazo.


Algunos casos

Con esta introducción, voy a meterme en harina. Comenzaré con un episodio que recientemente he vivido por parte de una nueva empresa que predica con el software libre. Desde hace un año estoy desarrollando una aplicación para el negocio de mi hermano. Visto el interés que puede suscitar y que hay poco en este nicho, he estado promocionando y generando sondas y expectativas sobre el mismo (marketing). Esta empresa ha sabido de mi aplicación, y se ha puesto en contacto conmigo para llevar dicha aplicación a su zona geográfica, y que tiene un filón de cerca de medio centenar de clientes interesados en el mismo. Dicha empresa ha querido cambiar la arquitectura de mi aplicación para adaptarlo a su arquitectura ideal libre. Ha criticado mi decisión de utilizar Flex por ser "propietario", cuando en realidad es libre y abierto (el motor Flash no es abierto, pero se utiliza y es aceptado en más de un 90% de los navegadores, y no hay que pagar por él. En lo puritano, también se podría esgrimir que el 100% de todas las aplicaciones al final ejecutan instrucciones máquina que no son libres, en microprocesadores que no son libres y apoyándose en BIOS que tampoco son libres). Aún así, uno puede desarrollar una aplicación en un lenguaje propietario, y liberar y abrir el código de su aplicación. De hecho, ésto se lleva haciendo durante muchos años en Windows y en Mac.

Pero ahí no acaba la cosa, pues además de querer hacerme cambiar de arriba a abajo un proyecto mío, querían que abriera el código para migrar la interfaz a otro lenguaje que era libre, aprovechar la lógica de negocio y la base de datos, y esta nueva versión abrirla mediante GPL. Asimismo esta empresa se ofrecía voluntaria para dar el soporte y mantenimiento en su zona. Eso sí, todo con un argumento muy libertario pero crítico al software propietario, con un cebo comercial muy goloso para ellos, no para mí, que al fin y al cabo tuve la idea y la desarrollé.

De esta anécdota se aprende que muchos esgrimen el software libre únicamente para sus propios intereses. ¿Para qué voy a desarrollar una aplicación si ya otro lo tiene hecho, y encima lo consigo "by the face", con lo que la inversión es cero y los beneficios absolutos?. ¿Que no me gusta que la interfaz esté hecha en X? Pues dáme el código y lo hago en Y, que es 100% libre y de código abierto. ¿Para qué un mestizaje?. Volvemos a la raza aria y pura, sin importar si ese mestizo es un hombre santo, un genio o una gran persona.

Mi intención con mi aplicación es liberarlo, permitiendo su libre distribución y copia, sin cobrar licencias por su uso ni por máquinas ni por tiempo. Pero mi intención no es abrir su código hasta haber rentabilizado mi inversión (tiempo, esfuerzos y dinero). No es algo egoísta, si no de sentido común. De momento lo estoy realizando para dos clientes seguros que tengo (uno es mi hermano y otro un amigo). Una vez rentabilizado, si el producto tiene demanda, es de interés general, está estable, sin bugs y funciona, lo abriré teniendo una ventaja competitiva, como hacen la mayoría de las empresas, con vistas a seguir generando negocio y evolucionar mi proyecto.

Os contaré otra historia. Hace cosa de cinco años, desarrollé una aplicación para monitorización de bases de datos. Desde un principio liberé y abrí la aplicación, con dos objetivos: uno para contribuir al software libre, y otra para que mi empresa (la que me contrató), no se aprovechase de mi trabajo, ya que lo usaba para hacer negocio. Surgieron multitud de empresas y personas que querían mi aplicación, y todas ellas me empezaron a pedir nuevos requisitos, nuevas funcionalidades y premura en fechas para su consecución. Cuando empecé a hablarles de cobrarles por ese trabajo que me pedían, quedaban absortos preguntándose, ¿pero no es software libre?. A lo que cuando le contestabas: sí, es libre, pero no gratis, y el trabajo que requiere hacer esto para ti, cuesta tanto. Entonces se molestaban y no volvías a saber nada de ellos. Lo curioso de todo es que muchos de estos interesados eran empresas con el slogan "I love open source", y al tener mi software abierto no contribuían desarrollando y aportando sus necesidades, si no que te las pedían para después vender los servicios de mi software ya adaptado a sus clientes. Este producto, al final, terminé por descontinuarlo y dejar de darle soporte, y nadie, absolutamente nadie, recogió el testigo.

De esta anécdota se aprende no sólo de los intereses, si no también de que en el concepto de código abierto, en lugar de contribuir con esas ideas o esas funcionalidades, de desarrollarlas y aportarlas al proyecto en beneficio de todos, te lo piden y lo exigen, aprovechándose de ello. No es una generalidad, aunque en esta experiencia personal fue el 100% los interesados. En proyectos más importantes y populares, esto suele no ocurrir, y pueden existir desarrolladores con espíritu colaborativo, que en lugar de pedir, solicitar o exigir, pasan a la acción: lo desarrollan y lo comparten.

Otra lección que se aprende es que hay miles y miles de proyectos de software libre que terminan en el olvido. Mi caso es uno de ellos. Y conozco otros muchos casos de compañeros cercanos que les ha pasado lo mismo, tras la desmotivación que le sigue a haber empezado con una iniciativa colaborativa y que al final termina uno en solitario y con demandas a modo de carta de los Reyes Magos, donde al final se aprovechan de ello para beneficio lucrativo. Los parásitos acaban consumiendo muchas ideas.

Estas dos historias son las más típicas. Pero hay historias más interesantes. Comentaré la de un amigo mío, que desarrolló una aplicación CRM muy simple y específica, y que liberó con todo el amor del mundo. Un día le llegó una demanda judicial por parte de dos empresas por los problemas financieros que le había producido un mal funcionamiento de su aplicación. Cuando llegó el juicio, y tras la argumentación de los abogados de las empresas, aparece algo que suscitó sorpresa en mi compañero, pues el problema en cuestión surgió de una funcionalidad que no tenía la aplicación. Una empresa de servicios informáticos había utilizado el software de mi amigo, añadiendo funcionalidades. Al surgir este problema, dicha empresa culpó al software de mi amigo, y los clientes afectados interpusieron la demanda. Le costó esfuerzo demostrar ésto, pues en España aún no hay mucha cultura en delitos informáticos ni conocimientos por parte de fiscales, abogados y jueces.

En alguna que otra ocasión me ha inspirado el espíritu de la contribución a algún producto de código abierto, como muestra de mi satisfacción a dicho producto y de que siga ahí vivo, con nuevas ideas y con mejoras. Sorprendentemente, a veces me han pedido donar dinero como muestra de colaboración. En otros casos, curiosamente, la organización es de andar por casa, o el desarrollo está restringido a un grupo de amigos que iniciaron el proyecto y es como un club privado, donde las ideas, el alcance funcional y el desarrollo son supervisados, censurados y controlados. ¿Dónde está la libertad del software? ¿En qué se diferencia de otros proyectos de software libre pero no de código abierto, o incluso de muchos proyectos propietarios?

En otras ocasiones, desde mi afán colaborativo he contribuido con ideas, o con comentarios, o notificando bugs. Tras enviar la notificación, no he recibido nunca una respuesta, ni tan siquiera un agradecimiento. Aunque parezca que esto no tiene importancia, como usuario me da desconfianza una organización en la que parece que no hay nadie detrás. ¿Qué tipo de soporte puedo esperar recibir si tengo algún problema con su producto?

El software libre es también un mercado (lo cual es loable y hasta necesario), y en dicho mercado también existe la ventaja de la escasez. Recientemente, en mi empresa necesitábamos un producto de business intelligence de bajo coste para uno de nuestros proyectos. Tras analizar los productos del mercado, el soporte no era nada barato ni de garantía, en comparación con el de otras soluciones propietarias que eran mucho mejores. En este nicho, y en otros nichos de escasez, el software libre aún no es una alternativa real, pero poco a poco se va ganando terreno.


Ahora van mis reflexiones:

En las líneas anteriores he desvelado una pequeña parte de lo que hay detrás de esta "religión" del software libre. Al igual que las teologías, el concepto de software libre es una ideología y un pensamiento puro en su nacimiento, pero corrupto en su evolución, utilizado por intereses personales y comerciales. Hasta el mismo Richard Stallman (padre del GNU), a modo de sorna se viste de túnica como un santo, se pone la aureola de un disco duro, predicando sobre su iglesia. Aunque sea un acto teatral, encierra un curioso reflejo de la realidad. Este párrafo suena duro y crítico, y aunque no sea una generalidad no está carente de verdad.

La historia es la sucesión sucesiva de sucesos sucedidos sucesivamente, y en el software libre está volviendo a suceder. Están surgiendo fanatismos y "sectas", en las que se alzan profetas y seguidores enfevercidos y exaltados, defendiendo su posición como absoluta y cierta con respecto a las demás, provocando enfrentamientos, insultos y amenazas de todo tipo: si no estás conmigo estás contra mi, y lo mío es la verdad absoluta y tú tienes que abrazar mi religión y mi fe, o estás condenado a extinguirte. ¿Os suena de la película "Ágora", cuando los primeros cristianos toman Alejandría de este modo? La visión de Jesús de Nazaret fue pura, humilde y buena para todos, pero surgieron después intereses e interesados, tergiversando aquella visión y terminando en aquello contra de lo que profesaban.

El software libre no es lo mismo que código abierto. Es un concepto que se suele confundir, y que muchos dan por hecho de que si es libre, tiene que abrir también su código.

El software libre es un concepto noble y solidario, que une culturas y países. Es un bien de la humanidad. Sus beneficios son incuestionables: promoción, accesibilidad, reducción de costes de distribución y logística, reducción de costes de licencias, libertad para copiar e instalar, etc. Asimismo genera negocio al ser más económico, especialmente en estos tiempos de crisis. ¿Y dónde está el negocio? En los servicios derivados: el soporte, el mantenimiento, la adaptación a necesidades específicas, la formación, la instalación, la integración con otros sistemas, etc.

El concepto del código abierto es también noble y solidario, y tiene la ventaja principal de poder acceder al código de un producto y realizar los cambios que necesites o adaptarlo a tus necesidades. Es inestimable en cuestiones de interés general, donde los intereses económicos no son importantes ni triviales, tales como la investigación, la educación, los lenguajes de programación, las bases de datos, etc. Cada vez más empresas deciden abrir su código para ganar competitividad o para frenar la competencia. A niveles más especializados puede ser interesante para promoción profesional de uno mismo. Por contra, también tiene un filo agudo y cortante, pues hay algunos que se aprovechan y se lucran de ello en detrimento de aquellos que desinteresadamente lo promueven sacrificando tiempo de sus vidas, ilusiones, esfuerzos y dinero.

Más de uno se preguntará qué se gana con el software libre, si es tan accesible y económico. Bueno, como comenté al principio, una empresa libera su software cuando ha rentabilizado su inversión y quiere ganar ventaja competitiva o frenar a la competencia. La fácil accesibilidad a este software incrementa las posibilidades de negocio mediante los servicios derivados, que son la clave comercial. Puede que a nivel personal no se contrate un soporte, pero una empresa querrá asegurar el funcionamiento del sofware, pues su negocio se basa o gana con ello.

¿Y es malo que una empresa no libere su software nada más desarrollarlo? No. Una empresa gasta mucho dinero en proyectos, pagando sueldos, inmuebles, impuestos, energía, etc. Liberar un software sin un ROI (retorno de la inversión) puede ser un error, pues entonces habría que despedir a las personas y cerrar la empresa. Muchas empresas desarrollan un proyecto con un cliente que lo amortice. Tras obtener la remuneración del proyecto, puede liberar su software para futuros proyectos con otros clientes.

¿Y abrir el código? Dependerá de las necesidades y de los intereses a nivel general o a nivel personal. Si el software es de gran interés general, abrirlo no sólo beneficiará al resto, si no también a nosotros mismos, que reconocerán nuestra noble acción.

¿Y de todo ésto, otras empresas se pueden aprovechar? Es posible, y aunque el código sea abierto, el mejor especialista sobre nuestro software somos nosotros mismos. La mayor de las veces, estas empresas nos contratarán soporte, haciendo de intermediarios, o incluso nos solicitarán modificaciones, adaptaciones o nuevas funcionalidades, pagando por ello. Si otros hacen modificaciones, normalmente contribuyen a nuestro proyecto, aportando la colaboración. Si estas modificaciones se convierten en un fork (una versión adaptada de un original), se conoce cuál es la fuente (nuestro software) y qué es lo que el fork añade (diferencia). De todas maneras, el interés en modificar el código de un producto estable y que funciona es muy ínfimo, y para ganar tiempo se suele contratar a quien lo creó.

¿Y qué ocurre con la crítica del principio? He expuesto algunas experiencias que vienen a aportar una visión no tan idealista sobre el software libre. Por desgracia existen numerosos casos de este tipo, que no hay que pasar por alto. Como comenté al principio con el símil de la religión, una ideología o una filosofía positiva va acompañada de factores negativos para equilibrarla. No todo es tan bonito, y conocer este lado nos dará nueva una amplitud de conocimientos y de posibilidades, así como una perspectiva no tan extremista y sobre cómo proceder en estos casos.

Participo en múltiples foros de software libre y de Linux. A veces veo auténticos fanáticos con una visión absolutista, que increpan duramente al resto. Parecen zelotes, y no aceptan un mundo con variedad de posibilidades. Hay también fanáticos del otro lado, con una visión también absolutista del software propietario. Ambos extremismos no son buenos para nadie, y lo único que hacen es forjar distanciamientos. ¿Os imagináis (es un ejemplo), una guerra entre cocineros a favor de abrir y compartir sus recetas, y de los que son absolutamente cerrados y exclusivos? Separar a los degustadores en uno u otro bando hace que unos se pierdan lo bueno que ofrecen los otros. Yo soy de buen llantar, y amo todo tipo de platos, ya sean abiertos o cerrados, y valorar lo mejor ambos.