Desarrollo en equipo con SVN, Maven y Nexus (parte I)

Banco de experiencias (V)

El orden es el placer de la razón pero el desorden es la delicia de la imaginación.
-Paul Claudel.

El desarrollo de software aúna una fascinante mezcla de pensamiento divergente (o creativo) con conceptos técnicos y prácticas metódicas. Para que un desarrollador (y especialmente un equipo de desarrollo) alcance los mayores niveles de eficiencia y productividad, las herramientas utilizadas deben garantizar la seguridad del proceso, pero siempre de forma proporcional a la envergadura del proyecto y manteniendo compatibilidad con el proceso creativo sin ahogarlo. Hay herramientas libres que nos ayudan a mantener este este delicado equilibrio entre orden y libertad para todo tipo de proyectos de forma sencilla e impecable.

Éste, como el resto de los artículos de la serie "banco de experiencias", no pretende ser un artículo más de documentación sobre las herramientas aquí comentadas ni encontrarás tampoco el enésimo tutorial sobre el asunto. Hay mucha documentación en la red y a lo largo del artículo suelo ofrecer información y referencias suficientes para que puedas profundizar en el tema. La idea de estos artículos es exponer buenas prácticas y comentar mi punto de vista, basado en mi propia experiencia profesional, sobre la utilidad real y pragmática de los temas abordados. Sin demagogia rimbombante ni publicidad interesada. Simplemente la síntesis de mi experiencia subjetiva.

Subversion

Subversion (también conocido simplemente como svn) es probablemente el mejor sistema de control de versiones centralizado que existe. Sin entrar en la discusión Centralizado vs Distribuido (DVCS), lo que si está claro es que el control de versionado es un aspecto crítico de cualquier proyecto de software.

En todo caso, si has llegado hasta aquí y no has usado nunca un software de control de versionado (VCS) la recomendación es clara: úsalo. Debes usarlo. Aunque tu proyecto sea muy pequeño. Aunque sólo exista un desarrollador. Has de asumir que, de la misma forma y con la misma naturalidad que usas un IDE o un compilador, deberás usar un VCS. Es absolutamente esencial. Si ya tienes claro que hay que usar uno y has decidido usar uno centralizado (o simplemente sueles usar otro, como CVS, por ejemplo), la recomendación también es clara: usa svn. En la wikipedia puedes consultar por qué SourceForge.net, Apache o Google Code lo eligieron, así como la documentación y herramientas disponibles.

Como decía, un software de control de versiones es necesario aunque el proyecto sea pequeño ya que te garantiza un seguimiento de cambios que te puede ahorrar muchas horas de trabajo. Si tienes clara la diferencia entre un editor de texto y un procesador de texto, entenderás enseguida la diferencia de usar backups de tu directorio de código y usar un VCS. No obstante, hay otro aspecto importante de los VCS que no suele ser tan comentado (quizá por obvio) y es su dimensión como herramienta colaborativa. Si de forma individual es extremadamente importante, para un equipo es absolutamente imprescindible. Un equipo no puede trabajar de forma "decente" sin Subversion. La idea de no usar un VCS o de usar uno bloqueante (tipo Visual SourceSafe) es una pesadilla para no dormir: "¡eh, cuidado!, no toquéis que voy a tocar yo" "¡Oh, mierda!, ya ha tocado alguien. ¡A ver ahora cómo lo arreglamos!"... o "¡fulanito, desbloquea el fichero que necesito añadir un método de la clase!" "¡No, espera que termine!"... Qué pesadilla. Me recuerda a aquellas herencias arcaicas de los programas COBOL de no pasarte de la columna 73 y poner los asteriscos en la columna nº 7... Bufff.

Trabajar con svn en equipo es lo más parecido a hacerlo como si estuvieses tú sólo. Si las tareas están repartidas, los conflictos son muy poco frecuentes (para que existan, dos desarrolladores deben haber modificado la misma línea simultáneamente antes del último commit) y cuando los hay, se suelen solucionar en pocos segundos. Es muy gratificante comprobar cómo un equipo numeroso puede trabajar en una aplicacion Web (un tipo de proyecto con un alto grado de colisión y concentración de trabajo) de forma cómoda y fluida sin problemas.

Maven

Aunque llevamos oyendo hablar de Maven desde hace varios años (Maven tiene ya 8 años), la adopción hasta hace cuatro o cinco años ha sido puntual y conceptual. Es desde la aparición de Maven2 (con su nueva arquitectura revisada) cuando realmente empieza a incorporarse (aunque también de forma muy lenta) a los distintos proyectos open source y esto ha hecho que en la comunidad de desarrollo comencemos a interesarnos y a integrarlo en nuestros proyectos. A mucha gente le ocurre que, tras leer sobre Maven y Ant, entiende las diferencias entre ellas, pero no alcanza a concretar por qué es tan importante y para qué le sirve realmente (qué le aporta que no tenga ya). Para aclarar definitivamente este punto simplemente hay que preguntarse cómo realizamos el proceso de construcción (generación de empaquetados y otros artefactos) en nuestros proyectos, y esto nos dará la respuesta. Veamos las opciones:

1. Construimos con nuestra herramienta de desarrollo (Eclipse, Netbeans, etc...).
2. Construimos con un fichero (build.xml) ant que nos hemos hecho nosotros.

Si se trata de un pequeño proyecto de un sólo módulo (un war, un jar, etc...) y/o el ciclo de vida de la aplicación es muy reducido (es una pruebecilla nuestra, una pequeña aplicación de las que se hacen en casa en zapatillas, etc) no importa, claro. ¿Qué más da? La he hecho yo y podré volverla a construir con mi IDE favorito o con mi Ant dentro de un año cuando tenga que hacer un cambio. Incluso aunque cambie el IDE o cambie mi entorno, podré adaptarme a la situación sin más problemas, hacer las correcciones y volver a generar el empaquetado.

Ahora bien, si nos situamos ahora un escenario profesional, el tema cambia mucho. A continuación expondré los problemas que nos encontramos con esas formas de construir aplicaciones. Seguramente ya te habrás encontrado con ellos, y si no, es porque el proyecto no era lo suficientemente grande o, simplemente, es una cuestión de tiempo que te los encuentres.

• Homogeneidad. Cada desarrollador tiene sus costumbres y sus ubicaciones (paths) para sus proyectos, librerías, ubicación del JDK, etc. Es difícil e incómodo homologar a todo un equipo de desarrollo en una única estructura de ficheros. Aunque Sun hiciese su propuesta de convenciones para proyectos (estructura y nombrado) hace mucho tiempo, casi ningún IDE lo respeta al 100%. Además, la heterogeneidad de los distintos Sistemas Operativos no hacen más que complicar la posibilidad de tener una estructura y ubicación homogénea para todo el mundo. Eso hace que los ficheros de proyecto (.nbproject, .project, etc) no puedan ser portados de unos desarrolladores a otros ni compartidos entre distintas máquinas. Esta estructura acaba teniendose que modificar manualmente en los distintos IDE's o en el fichero build.xml de ant. En el caso de los IDE's es particularmente grave, ya que la información de librerías, por ejemplo, descansa en la configuración local del IDE de cada desarrollador, que suele ser distinta para cada uno, con lo cual la construcción se torna algo tremendamente frágil y poco transparente.
  
• Reproducibilidad. Necesitamos realizar tareas forma constante y estable nuestro proyecto: construccion, pruebas unitarias, informes, etc... Repetibles en el tiempo (hoy y dentro de un año) y en el espacio (en mi máquina de desarrollo, en integración, en preproducción...). Necesitamos fijar parámetros que no están implícitos en el proyecto en si y que acaban también fijados en los IDE's o en el script ant: versión de Java, versiones de librerías, destino de cada librería (sólo para compilar, sólo para desplegar con la aplicación, para compilar y desplegar...), ficheros de configuración, etc... Esto dificulta el mantenimiento y oculta información esencial del proyecto. Si el proyecto se sube a SVN y no lo volvemos a tocar en un año, a menudo nos encontramos con que las partes esenciales del proyecto han quedado ocultas en IDE's (o lo que es peor, se han perdido porque eran parte de la configuración local de un miembro del equipo) o permanecen en un script de ant poco amigable para modificar.
  
• Gestión del cambio. Algo tan común como añadir una nueva librería al proyecto o realizar una actualización de una existente tiene demasiado impacto en el equipo hasta resultar ligeramente traumático: todos deben realizar las tareas de la descarga y localización de las librerías, la configuración de su IDE y de su proyecto y/o la adaptación de sus ficheros ant. Incluso un equipo de desarrollo con normas rígidas y paths homologados, además de sufrir esta falta de libertad, sigue estando expuesto a este tipo de problemas.
  
• Gestión de dependencias (externas). Este es sin duda el aspecto más importante, por delicado, y por el impacto de sus consecuencias. Imagina el siguiente proyecto: un EAR compuesto por dos módulos WAR, tres módulos EJB y un par de módulos de de librerías comunes (jar). Uno de los desarrolladores añade al EAR una librería "A" que necesita uno de los módulos EJB y otro desarrollador añade otra librería "B" que necesita uno de los módulos JAR. Ambas librerías tienen sus propias dependencias: la librería "A" requiere de xxx-commons-2.3 y de asm-2.1, la librería "B" de yyy-commons (que a su vez depende de xxx-commons-1.5) y asm-3.0. Ya tenemos el problema servido. Como ya comenté en el artículo "Errores comunes de despliegue JEE", este tipo de problemas algunas veces sólo se presentan aleatoriamente, ya que el problema puede presentarse o no en función de la secuencia de carga del ClassLoader de la máquina de turno. Esto ocurre muchas más veces de lo que nos pueda parecer a simple vista, si bien en la mayoría de los casos los conflictos no plantean problemas porque muchas librerías mantienen una compatibilidad perfecta hacia atrás. En mi experiencia, es habitual que ocurra sin embargo con grandes frameworks tipo Hibernate, Spring, Struts, etc, con consecuencias muy desagradables. Sin Maven, la gestión de dependencias no la hace nadie, o lo que es lo mismo, se hace manualmente si el equipo de desarrollo es muy cuidadoso y está muy bien coordinado.
  
• Gestión de dependencias (internas). Otro aspecto de los proyectos medianos con varios módulos interdependientes entre si es que, además de tener que realizar gestión de dependencias de librerías de terceros tenemos que gestionar nuestras propias dependencias. Por ejemplo, para el caso anterior, si ambos WAR necesitan de los proyectos JAR de librerías comunes, todos los desarrolladores de los WAR deberán tener también que tener los proyectos (código fuente incluído) de dichos JAR, para estar debidamente actualizados... O bien buscar otra forma de distribución manual de empaquetados que también exigirá un esfuerzo adicional de coordinación.
  

Como puedes suponer a estas alturas, Maven es una solución perfecta a todos los problemas comentados anteriormente (salvo para el último punto, para el que se requiere un colaborador, pero eso lo comentaré en la segunda parte). Maven es y sirve para muchas cosas (compilación, paso de pruebas unitarias, control de calidad, etc) pero, fundamentalmente, es la mejor herramienta de construcción posible. Hasta ahora, para una construcción lo más homogénea y reproducible posible necesitábamos unas normas (o convenciones) y ant. Pero ant es un lenguaje específico de dominio para la construcción de proyectos: te tienes que crear tus propios scripts basado en tus convenciones y el esfuerzo de mantenimiento es exponencial a la envergadura del proyecto. Maven ya te aporta ambas cosas: convenciones (sobre disposición de directorios de proyecto, por ejemplo) y todo el trabajo listo para usar sin tener que configurar nada. Con Maven puedes realmente bajarte unos fuentes y ejecutar un "mvn build" sobre el directorio que contiene el "pom.xml". Y tener en poco tiempo todos los empaquetados, un informe de construcción, pruebas unitarias realizadas, etc, etc.. con configuración cero.

No obstante, el punto fuerte (e incluso espectacular) de Maven es la gestión de dependencias: sólo por la gestión de dependencias transitivas que realiza de forma automática, ya merece la pena con creces. En este tema me recuerda a los repositorios de Ubuntu. Cuando quieres una librería, añades la dependencia y la versión que quieres de las disponibles y él se encargará de aprovisionarse de todas las dependencias transitivas adicionales.

Incluso aún respetando las convenciones de Maven (te las puedes saltar si especificas en el pom.xml cuáles son tus directorios) Maven te ofrece toda la libertad posible: permite que un equipo trabaje con IDE's heterogéneos: cada desarrollador con su IDE favorito. Lo único que debes subir a SVN son los fuentes y el pom.xml. Podrás construir el proyecto de forma repetible, independiente del IDE, ejecutar las pruebas unitarias y olvidarte de problemas de librerías.

Obviamente no te vas a olvidar de tu IDE o de ant. Toda esta maravilla de Maven tiene un precio: el rendimiento. Un build con Maven te lleva más segundos de los que estás dispuesto a considerar como aceptables para tu trabajo de desarrollo habitual. No es aceptable desarrollar realizando builds con Maven. Por lo menos para mi. Por eso yo continúo realizando los ciclos de iteración compilación-despliegue-pruebas con mi IDE. Maven lo dejo para realizar las construcciones, para subir a svn proyectos autónomos y autogenerables y para poder realizar las integraciones y las puestas a preproducción de una forma segura y repetible.


En esta primera parte he expuesto 2 de 3 de las herramientas más esenciales para el desarrollo en equipo de proyectos Java (especialmente JEE). En el siguiente artículo cerraré el círculo con la herramienta que falta: un gestor de repositorios de Maven. Y explicaré cómo, con tan sólo esas tres herramientas, tenemos un entorno de trabajo potente y seguro para equipos de tamaño mediano sin rígidas normativas ni procedimiento burocráticos.

Referencias:

• Subversion ya forma parte de Apache
• Libros gratuitos sobre Maven
• Maven en la wikipedia

Alternativas gratuitas a MS Project

“Como nada es más hermoso que conocer la verdad, nada es más vergonzoso que aprobar la mentira y tomarla por verdad”. -Cicerón.

MS Project es un software de administración de proyectos para asistir a administradores de proyectos en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y analizar cargas de trabajo, aunque la verdad es que el uso mayoritario se centra (y de forma generalizada también acaba) en una planificación/cronograma acompañada de un diagrama de Gantt que nunca cabe en el documento de "Plan de Proyecto" y acaba tan reducido que es difícil de apreciar.

El uso de este software y sus artefactos (especialmente los diagramas Gantt) materializan la ficción extendida de las métricas del software a la que me referí en un artículo anterior. Y es que el mundo empresarial, inmerso en sus propios vicios adquiridos autojustificativos, requiere de éste tipo de "justificantes" falsificados, de la misma manera que se recoge un justificante por visita médica: es probablemente inútil, de redacción incomprensible y caligrafía críptica, puede que hasta falso o adulterado... pero se ha hecho necesario para que continúe la cadena de responsabilidad indirecta.

El software en realidad es bastante útil, el problema es que, como explicaba en el artículo comentado, los artefactos generados con el mismo se presentan como una verdad inmutable, como un producto exacto y preciso fruto de la ciencia y la ingeniería cuando en realidad, en el mejor de los casos, son producto de unas buenas prácticas, una experiencia dilatada, un buen equipo, unas acertadas predicciones y una ración de buena suerte. ¿Por qué? Pues sencillamente porque estamos estimando, estamos realizando diversas predicciones del tiempo que tardan varias personas cualificadas en realizar tareas moderadamente complejas y débilmente definidas, teniendo en cuenta una enorme sucesión de suposiciones relacionadas e interdependientes entre sí, y entre esas suposiciones, unos requisitos de proyecto inmutables o congelados en el tiempo: es decir, una conjetura como la copa de un pino, aunque más o menos razonable y convenientemente adornada.

No obstante lo anterior, el software tiene su utilidad para ayudarnos a realizar y gestionar esas conjeturas y tener pronósticos lo más acertados posibles: podemos desglosar las tareas, conocer sus relaciones y dependencias, realizar asignaciones aproximadas, conocer el camino crítico, detectar riesgos, etc... Si esos cronogramas fuesen algo vivo, como lo son los requisitos y el resto de los factores durante el ciclo de vida del proyecto, y se actualizasen y ajustasen periódicamente, podríamos tener una buena herramienta para gestionar nuestras hipót... perdón, quiero decir, tareas.

Dicho esto, vamos al tema que nos ocupa: en muchos casos, el coste de adquisición de este software es desproporcionado con una utilización parcial (digamos al 30% como mucho) y eventual (¿menos de 2 o 3 veces al año?), así que, ¿hay alternativas gratuitas?. Vamos a ello.

OpenProj

Probablemente el más parecido funcionalmente a MS Project y una de sus mejores alternativas. Está disponible para Linux, Unix, Mac y Windows (hecho en Java). Es gratuito, multilenguaje y distribuido bajo licencia CPAL, ha sido elegido para su inclusión en la suite Star Office para Europa.

Como herramienta de trabajo es perfecto. Sólo un inconveniente con respecto a la generación de artefactos: la impresión/exportación del diagrama Gantt y otros informes es sólo personalizable en la versión que se distribuye como Software as a Service (SaaS): Projects On Demand. La buena noticia es que el coste de esta versión es apenas de unos unos pocos 15€ al mes.

Ganntt Project

Esta herramienta cumple con el famoso Principio de Pareto (o "regla del 80-20") en cuanto a la funcionalidad esperada: la mayoría de los usuarios de MS Project (yo diría que mucho más del 80%) apenas utiliza un 20% de su funcionalidad. Esta funcionalidad mínima es la que nos ofrece este software.

Sus capacidades de importación/exportación, así como la generación de artefactos (diagramas e informes) cubren los mínimos necesarios como para que esta herramienta sea suficiente para realizar cronogramas de proyectos pequeños y medianos.

Es totalmente gratuito, multilenguaje, y distribuido bajo licencia GPL 2.0. Como también está desarrollado en Java, está disponible para Linux, Unix, Mac y Windows.

He ido probando cada actualización que hacen al producto y desgraciadamente siempre me he encontrado con ciertas carencias y deficiencias típicas de un producto aún falto de madurez. Ligeramente "tosco" y sin apenas hot-keys, tenía deficiencias editando tareas en proyectos no demasiado grandes, pero con muchas relaciones y tareas jerarquizadas (a la hora de mover tareas dependientes en el tiempo, gestionaba mal las dependencias "fuertes" o "rígidas" dejándolas sin desplazar). Tampoco nunca encontré una forma de realizar una re-distribución de recursos en casos de reasignación.

No obstante, seguiré probando hasta poder disfrutar su madurez definitiva.

OpenWorkbench

Probé la versión 1.1.6 cuando salió, allá por 2006. Realmente quedé impresionado porque era realmente una excelente alternativa a MS Proyect. Especialmente me gustó la facilidad para presentar distintas vistas a modo de hojas de cálculo que permitían obtener costes y realizar cálculos en base a estimaciones con bastante facilidad.

El producto es gratuito y open source (aunque no he encontrado el tipo de licencia exacto) no obstante, no es un proyecto muy activo: no parece haber evolucionado en estos últimos 4 años. Lamentablemente sólo está disponible para para plataformas Windows y yo no uso ese tipo de plataformas desde hace varios años, así que no lo volví a probar desde aquella vez. No obstante, si usas Windows, te animo a probarlo (y sobre todo, a cambiar a Kubuntu, claro ;-).

Nota: es bastante posible que funcione con Wine, pero me seducen más otras opciones... ;-)

KPlato

KPlato es la aplicación para gestión de proyectos de la suite KOffice. Es el más ágil, ligero y fluido de todos los comentados hasta ahora, y tiene el aspecto elegante y sencillo propio de la suite de Office para KDE.

Al igual que comenté en otro post sobre alternativas a MS Visio, se nota que si bien aún no ha alcanzado un nivel de madurez equivalente al OpenProj (en la redacción de este artículo he probado la versión 0.6.3), es equivalente o superior a Ganntt Project en cuanto a funcionalidad y muy superior a todos los demás en cuanto a usabilidad y agilidad. Al igual que con el resto de paquetes de la Suite, KPlato tiene un futuro muy prometedor ya que el roadmap evolutivo del producto nos depara probablemente la mejor alternativa a MS Project completamente gratuita.
Con licencia GPL, y originariamente para Linux, está disponible para muchas plataformas actualmente, incluído Windows.



Como siempre, recomiendo probarlos todos (lo que vale para mi, no necesariamente tiene que valer para ti ;-), aunque yo me estoy apañando perfectamente con los tres. Incluso he llegado a importar un .mpp de MS Project, modificarlo y volverlo a exportar para generar un mini-site HTML con Ganntt Project (del cual podía extraer perfectamente las imágenes de Cronograma Gantt que necesitaba).

La UE aprueba finalmente la adquisición de Sun

Larry Ellison ha conseguido salvar el último obstáculo para hacerse con la totalidad de Sun sin renunciar a MySQL, que era el punto conflictivo tras las objeciones de la UE a la adquisición por la posible vulneración de la libre competencia en Europa en el sector de las bases de datos.

La Comisión Europea ha obligado a Oracle a realizar 10 concesiones y seguir invirtiendo en MySQL durante un tiempo. Este tema relativo a MySQL, aunque muy importante, no ha sido nunca mi mayor preocupación en torno a este tema de la adquisición (como comenté en un artículo anterior) sino, obviamente, aquellos activos de Sun (ahora de Oracle) que me afectan directamente: Java y Glassfish (y en ese orden).

Entiendo que Oracle tiene mucho interés en mantener la tecnología, ya que lleva años basando sus productos en ella. Otro tema serán cómo se afrontará el Java Community Process y los distintos comités por un lado y la gestión de un Servidor de Aplicaciones de código abierto y comercial compitiendo directamente con sus dos actuales: no creo que se vaya a quedar con tres productos equivalentes y en el mismo segmento de mercado.

Y todo esto, de forma contemporánea con la aprobación de la JSR 316, o más conocida como la especificación JEE 6, tras tres largos años de trabajo. Una de las especificaciones más esperadas y con grandes avances en muchos campos que sin duda nos facilitarán las cosas como por ejemplo un tipo específico de EJB para realizar singleton o las invocaciones asíncronas a EJB's.

La implementación de referencia (Glassfish v3) está disponible desde el 10 de Diciembre.

El próximo 2010 será el primer año de Java y Glassfish bajo el control de Oracle, con todas sus interesantes novedades (especialmente en lo que a JEE se refiere). Veremos cómo evoluciona la adopción de estas nuevas especificaciones.

Feliz año 2010.



Si queréis ir echando un vistazo a las novedades de JEE 6:

General

• http://java.sun.com/developer/technicalArticles/JavaEE/JavaEE6Overview.html
• http://www.theserverside.com/tt/articles/article.tss?l=JavaEE6Overview

EJB 3.1

• http://www.dosideas.com/java/528-ejb-31-un-paso-importante-hacia-la-madurez.html
• New Features in EJB 3.1
• New Features in EJB 3.1 - Part 2
• New Features in EJB 3.1 - Part 3
• New Features in EJB 3.1 – Part 4
• New Features in EJB 3.1 – Part 5

Servlet 3.0

• An Overview of Servlet 3.0

Manifiesto en defensa de los derechos fundamentales en internet

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Magnitudes astronómicas

"El hombre es la medida de todas las cosas" -Protágoras de Abdera, s V a.C.

El hombre siempre ha tenido la necesidad de medir el mundo que le rodea: para explorarlo y comprenderlo, para relacionarse con los demás e intercambiar, para prevenir sucesos, pronosticar su devenir y desarrollarse. Como patrones, el ser humano ha utilizado todo tipo de elementos conocidos a su alrededor: su propio cuerpo, elementos de su entorno, fabricados ad-hoc para permitir su duplicación, etc.

Hace casi 2.300 años, Erastótenes determinó el tamaño de la tierra en "estadios" que, como su nombre indica, era una unidad de longitud equivalente a la longitud del estadio de Olimpia [1]. Ya no usamos científicamente unidades antropométricas, pero seguimos necesitando unidades de medida relacionadas con el mundo habitual que vivimos que nos ayuden a comprenderlo y materializarlo comparando con elementos conocidos. Todos podemos representar en nuestra mente o imaginar 1 Kilómetro, porque lo comparamos con distancias conocidas. Podemos también imaginar cientos e incluso miles de kilómetros porque conocemos mapas y el tiempo que se tarda en recorrer esas distancias en diferentes medios de transporte... Pero en lo que respecta a las distancias, nos quedamos ahí. Cifras como millones de kilómetros o años luz escapan de nuestra imaginación porque somos incapaces de compararlas con nada que conozcamos.

Recientemente ví el vídeo a continuación y quedé impresionado por los descomunales tamaños de los distintos cuerpos celestes y cómo unos cuerpos gigantescos se hacen ínfimos con respecto a otros.

Tras ver esto, me puse manos a la obra a intentar "imaginar" esos tamaños comparándolos con elementos conocidos, así que convertí el universo en una diezmilmillonésima de lo que es ahora. Lo que viene a continuación es un nano universo con objetos conocidos (disculpad las imprecisiones y redondeos, pero he primado la visualización de objetos en nuestra imaginación a la exactitud).

En este mundo, la tierra es como una canica grande (de 1,3 cm). La luna, del tamaño de una lenteja pequeña girando a su alrededor a un par de cuartas (casi 40 cm) de distancia. Una unidad astronómica (UA) es, en este mundo, la longitud de tres piscinas olímpicas, así que tenemos a nuestra canica girando alrededor de un sol del tamaño de un Smart (visto por detrás, ya que es más largo que ancho) a unos 150m de distancia. Girando también alrededor de esta esfera de metro y medio hay un guisante llamado Marte a 230m. de distancia y un balón de balonmano llamado Júpiter a unos 780m. Es decir, que si nuestro sol estuviese en la estación de Atocha de Madrid, Júpiter estaría girando a su alrededor al final del Paseo del Prado, por la fuente de Neptuno.

Otras estrellas son gigantescas incluso en este mundo enano. Betelgueuse, la supergigante roja de la constelación de Orion es del tamaño de un monte (480m.). Imaginaos una canica al lado de un monte. Pues eso no es nada, VV Cephei y VY Canis Majoris son esferas inimaginables de 1,5km y 2Km de diámetro respectivamente. Para intentar imaginar esas enormes hipergigantes rojas, deberíamos cambiar de escala, imaginando ahora que nuestro sol es del tamaño de un balón de balonmano y nuestra tierra de un grano de arena: en este caso, VV Cephei es como el Palacio de Comunicaciones de Madrid (en la plaza de Cibeles) y VY Canis Majoris es como el estadio Santiago Bernabéu. Impresionante, ¿no? Al final, como Erastótenes, he acabado también midiendo en estadios.

En fin, mientas pensaba en todo esto y hacía mis cálculos, me entero de la publicación del libro "La Galaxia en un campo de fútbol" [2]. Libro que, por supuesto, ya tengo nuevecito y reluciente a mi lado (muchísimas gracias, Eva, por el regalo). El libro trata de ésto mismo, proponiendo un método y nuevas unidades de medida para comprender el Universo. Os contaré cuando acabe sus páginas en una nueva entrada del blog... pero ya os avanzo que tiene una pinta estupenda.



[1]: Afortunadamente, Cristóbal Colón justificó la viabilidad de su viaje a las Indias por occidente con los datos erróneos de Ptolomeo. Posiblemente, con las mediciones de Erastótenes, el viaje no se habría realizado en aquella época. Seguramente éste sea el error más influyente en la historia de la humanidad y una de las pruebas de que los errores también nos conducen a fantásticos descubrimientos.
[2]: "La galaxia en un campo de fútbol", de Juan Fernández Macarrón, Edita: Equipo Sirius (2009)