Media Net Software KIT Blog

Como sabeis, cada año se celebra en Amberes el Devoxx (antes conocido como JavaPolis). Como Medianet no se pierde una, este año me ha tocado a mí representarnos en este evento que ,sin duda, es el más importante en Europa relacionado con el mundo java. devoxx.com

Los días se repartían en dos bloques, los University days (lunes y martes) y los Conference days (resto de la semana).

En el primero de ellos, las charlas eran de tres horas de duración y estaban orientadas al aprendizaje, al estilo de clases magistrales impartidas por algún experto.

Algunas de las mejores charlas a las que asistí tuvieron que ver con Java EE 6 y SOA. En la primera de ellas, Antonio Goncalves se marcó una serie de demos para presentarnos las novedades de Java EE 6, os pongo algunas de las características que más me llamaron la atención:

- Servlets 3.0: Presentó las nuevas anotaciones @Servlet que, por ejemplo, eliminan la necesidad de declarar y configurar el servlet en el web.xml. Además, ahora, los servlets tienen soporte para peticiones asincronas.

- EJB 3.1: La principal novedad residía en lo que han llamado EJB Lite, que permite empaquetar un EJB dentro de un WAR. con ciertas limitaciones. También se ha simplificado el tema de las interfaces, ya que si no se usan no es necesario crearlas. Otro punto a favor es que ahora los EJBs de sesión pueden tener métodos asincronos simplemente usando la anotación @Asynchronous sin necesidad de hacer nada más. Por último han creado un nuevo servicio que llaman “Time Service” que usando la nueva anotación @schedule permite programar ,como si de un video se tratara, el EJB para lanzar sus métodos en un momento determinado, al estilo del comando cron de Unix.

- JPA 2.0: Se ha enriquecido JPQL para dar soporte a joins en subqueries con la clausula FROM. También se ha incluido un nuevo nivel de cacheo que se puede usar con la anotación @cacheable. Se han incluido nuevas posibilidades para realizar los bloqueos (Lock, Read and Lock, Lock and Read…)

- JSF 2.0: Ahora JSF 2.0 está integrado en Java EE 6.

- BeanValidation 1.0 : Este nuevo paquete presenta funcionalidad para validar beans usando notaciones del estilo @NotNull, @size, @valid…. Se integra con JPA 2.0 y JSF 2.0

- JAX-RS 1.1: Ahora soporta RESTFul services. Añade notaciones para especificar diferentes tipos MIME (@Produces(”image/jpeg”), @Produces(”text/plain”)…)

Si quereis ver una lista completa y detallada de todas estas novedades podeis hacerlo en http://java.sun.com/javaee/technologies/javaee6.jsp

Ahora mismo, el único servidor que soportará el 100% de la nuevas características de Java EE 6 es Glassfish (implementación de referencia) que estará disponible en versión v3 el 10 de Diciembre. Ya podeís estar atentos. https://glassfish.dev.java.net/

Como he comentado más arriba, otra clase magistral que me gustó especialmente por su claridad y por el enfoque, fue la impartida por Sang Shin evangelista de SUN.

Estuvo presentando, con multitud de ejemplos, los fundamentos de SOA. Desde lo que era un WSDL hasta las tecnologías que permitian orquestar e integrar los distintos servicios BPEL y JBI. Usando para ello Glassfish ESB y NetBeans 6.7.1, este entorno proporciona unos muy buenos editores para hacer el trabajo con estas tecnologías algo más sencillo. Incluso, al final le dió tiempo a montarse un Single Sign On federado usando OpenSSO.

Si quereis seguir esta charla y aprender más sobre un montón de temas relacionados con el mundo java podeis hacer sus estupendos tutoriales en javapassion.com

Google ha anunciado que está desarrollando un Sistema Operativo diseñado especialmente para portatiles netbooks. El Sistema Operativo tendrá el nombre de Google Chrome Operating System.

Lo han definido como un sistema operativo ligero diseñado para que corra en procesadores x86 y ARM utilizando un núcleo Linux.

El enfoque es disponer de un sistema ligero que arranque muy rápidamente y que permita a los usuarios un acceso prácticamente inmediato a sus datos, que vivirán en la nube (Cloud Computing)

La lista de partners de Google para el proyecto Chrome OS es la siguiente.

* Acer
* Adobe
* ASUS
* Freescale
* Hewlett-Packard
* Lenovo
* Qualcomm
* Texas Instruments
* Toshiba

Aunque falten algunas empresas importantes, no quiere decir que no participen ya que irán ampliado la lista en el blog de Google Chrome.

Habrá que ver la evolución del proyecto y la aceptación por parte de los usuarios finales pero sin duda ayudará a la distribución del software libre y dado que será gratuito hará que aumente el uso de las aplicaciones de google.

Las supuestas primeras imágenes han aparecido en ChromeOSleak. Según la descripción hecha en el sitio de la filtración, la instalación de Chrome OS sería expedita y habría tomado solo 10 minutos, incluido un nuevo inicio de un PC portátil Acer Extensa 4620Z. Según la fuente, Chrome OS sería sorprendentemente rápido, aún en su actual etapa beta.

El pasado martes Pablo Martínez nos comentó a todos los rudimentos de Ruby y su framework Ruby On Rails.
Aunque evidentemente no fue más que arañar la superficie, si fue muy interesante ver como en apenas un cuarto de hora fue capaz de montar una aplicación con las funcionalidades básicas que podría tener un blog, haciendo notoria la velocidad de desarrollo que se puede alcanzar con esta herramienta.
Como conclusiones de la sesión podemos destacar las siguientes:

- Ruby/Ruby On Rails proporciona una gran velocidad y flexibilidad (Convention-Over-Configuration) al proceso de desarrollo
- Ruby/Ruby On Rails proporciona una gran número de componentes/librerías a través de sus Gems
- Ruby/Ruby On Rails tiene ciertos problemas de escalabilidad que se esperan solucionar en próximas versiones, aunque existen formas de paliar esta cuestión.
- Ruby/Ruby On Rails se encuentra en gran crecimiento como lo demuestran:
** La aparición de los primeros IDEs (RubyMine-Jetbrains, Eclipse RDT o Netbeans Ruby)
** Comienza a venir instalado con algunos sistema opetativos como Mac OS X Leopard … apps para IPhone en Ruby-Cocoa?
** El gran número de aplicaciones que están apareciendo basadas totalmente o en parte en esta plataforma, por citar algunos ejemplos:
—- Basecamp - 37 Signals
—- BumperSticker - una FaceBookApp de LinkedIn
—- o Twitter, originalmente completamente, y últimamente solamente el GUI y alguna otra cosa.
** La posibilidad de llevar las aplicaciones al “Cloud”:
—- bien con proveedores “especializados” como Joyent o EngineYard o
—- más generalistas como Amazon WS o GoogleEngine App (en este caso a través de JRuby)

Resumiendo, que aunque tal vez no sea ajustado a todos los casos, sí es algo a no perder de vista.

Ayer en la charla del Kit cuando comentaba la restricción que pone Silverlight a la hora de consultar servicios externos al dominio donde está alojado nuestra aplicación, surgieron muchas dudas acerca de si este era realmente el funcionamiento. Con este artículo pretendo dejar claro el funcionamiento de este mecanismo.

Todo esto viene de Flash, creadores de los ficheros crossdomain.xml, ficheros que especifican si un servicio o recurso es accesible o no por clientes que provienen de otros dominios. Este fichero debe estar en la raíz del dominio donde están alojados los servicios o recursos. La estructura de este fichero se puede consultar aquí: Cross-domain policy file specification

Silverlight hace uso de este tipo de ficheros de la misma forma que Flash, además que incluye también un nuevo tipo de fichero clientaccesspolicy.xml. Silverlight primero tratará de descargar este fichero y si no existe, tratará de descargar crossdomain.xml.

¿Qué ocurre con servicios que no son nuestros?

Es es la primera pregunta que nos puede surgir. Si yo quiero conectarme a los servicios web de Google, Flickr o Twitter, ¿les tengo que decir que me pongan ese fichero? Lo cierto es que todos los grandes servicios tienen ya este fichero configurado para acceso de forma general.

• http://api.google.com/crossdomain.xml
• http://api.flickr.com/crossdomain.xml
• http://www.twitter.com/crossdomain.xml
• http://www.amazon.com/crossdomain.xml
• http://www.youtube.com/crossdomain.xml

¿Y cuando no existe y no puedo hacer que lo ponga?

Para este caso existen alternativas.

Una de ellas sería hacer uso de la API de integración con el navegador para acceder al objeto JavaScript XMLHttpRequest y consultar a través de él el servicio en cuestión. XMLHttpRequest no hace esta comprobación de ninguno de estos ficheros Xml, aunque podríamos tener problemas con otras características de seguridad que implementen los navegadores para evitar XSS.

Otra alternativa es hacer que nuestro servidor nos haga de Proxy con el servicio o recurso del otro dominio. El problema de esta solución es la posible sobrecarga de nuestro servidor.

+Info

• (MSDN) Making a Service Available Across Domain Boundaries
• (MSDN) Network Security Access Restrictions in Silverlight 2

Al parecer, y según el siguiente articulo publicado en bloomberg
Google y Microsoft también se verán las caras en el cuadrilatero de los netbooks.

La nueva estrategia de Asus para sus nuevos netbooks es la de dotarlos con el sistema operativo Android, que hasta el momento tan solo era rival de los SS.OO. para moviles de Apple, Microsoft o Nokia.

Bien mirado, la apuesta de Asus por Android resulta completamente lógica. Buscaban un S.O. abierto (opensource), barato (gratis), y ligero (pensado para teléfonos móviles). La guinda del pastel la ponen la compatibilidad con las miles de aplicaciones creadas para Android y con los teléfonos móviles que en un futuro lleven este sistema operativo. ¿A quien no le gustaría tener en su teléfono móvil el mismo sistema operativo que lleva en su portatil?

Descubro via Chema Alonso( MVP Seguridad ): Link que el pasado 25 de Diciembre se cumplieron 10 años del paper donde se expone la técnica que más adelante pasaría a llamarse SQL Injection.
Link al paper original

¿ Que no sabes qué es Sql Injection ?. Resumiendo al máximo: es una técnica para atacar una aplicación que maneja sin cuidado la generación de consultas a BD, inyectando sentencias SQL en lugar de los valores esperados.

Según la Wikipedia: Wikipedia

Por poner un ejemplo claro y clásico:

Código de LogIn en la aplicación pide Usuario y Contraseña, accede a la BD y comprueba si existe una fila en la tabla Usuarios con los datos introducidos, si es así el usuario accede a la aplicación.

Si la generación de la consulta se realiza como sigue: ( Quien no lo ha visto en todos los lenguajes de programación posibles?, salvo en LINQ, claro ).

string sql = "SELECT Count(*) FROM Usuarios WHERE NombreUsuario = '" + textBoxNombreUsuario.Text + "' AND Contrasenya = '"+ textBoxContraseñaUsuario.Text + "'";

Bien, si el usuario de la aplicación, espabilado él, introduce por ejemplo, como nombre de usuario: MiUsuario’ OR 1=1 — la consulta resultante sería:

string sql = "SELECT Count(*) FROM Usuarios WHERE NombreUsuario = 'MiUsuario' OR 1=1 -- AND Contrasenya = 'cualquier cosa que ponga'";

Donde “–” en SQL comenta el resto de la línea… por lo que la consulta va a evaluar solamente las filas cuyo usuario sea ‘MiUsuario’ OR 1 sea igual a 1…. que suele serlo

Éste es el ejemplo más simple, recordad que SQL permite realizar operaciones en batches, separando cada consulta por ‘;’, con lo que en casos tan extremos como el anterior se pueden llegar a inyectar acciones DML tan “simples” como pueden ser DROP TABLE o DROP DATABASE: MiUsuario’ OR 1=1; DROP TABLE Usuarios —

Evidentemente para que pudieran realizarse operaciones de DML en la Base de Datos el usuario que ejecuta las consultas tendría que tener esos permisos… y no debería tenerlos, debería lo menos crearse un usuario con los menos permisos posibles para ejecutar las consultas de la aplicación y otro administrador para gestionarla … pero igualmente no se deberían crear las consultas dinámicas que estamos viendo, así que mejor verlo junto

A partir de aquí surgen distintas variaciones de la técnica, basándose en la información que se puede obtener de la página, como por ejemplo:

-Time-Based SqlInjection: Inyectar queries en las que si se cumple la condición que esperas se ejecuta un delay con el que poder distinguir basándonos en el tiempo de respuesta si la condición se ha cumplido o no. El ejemplo básico sería deducir una password a base de ir encontrando cada caracter, sabiendo si es válido porque cuando lo es la ejecución de la página es más lenta debido a la query inyectada. En TechNet hay un artículo, también de Chema, al respecto: link

Además de las neuronas de quien pone a prueba la aplicación, existen Tools que realizan sofisticados ataques basados en diccionarios, comparando resultados de la página, aplicando Time-Based SQL Injection… un ejemplo de herramienta puede ser :sqlpowerinjector

Bueno, me estoy extendiendo demasiado y se me acaba el año

Espero que con este mínimo resumen haya despertado la curiosidad de algunos y elevado el nivel de atención a la seguridad. Recordad que en general estas técnicas son totalmente independientes del lenguaje de programación y de la Base de Datos, cada uno puede tener algún agujero o característica especial, pero las técnicas generales aplican a todos.

El año que viene opinamos sobre qué hacer para evitar estas vulnerabilidades, pero las recetas mágicas no existen y siempre será necesario ser consciente de las técnicas de ataque para intentar evitarlas en lo posible.

Volviendo otra vez al proyecto actual en el que estamos asignados Dani Gonzalez y yo, nos hemos encontrado con que las versiones de Portlet y de JSF utilizadas no permiten el uso de componentes con comportamiento AJAX. En versiones posteriores estos problemas tienen solución e incluso existen librerías de componentes JSF muy potentes en este sentido (ICE Faces, RichFaces, Oracle ADF) pero como todos os imagináis a los dueños de una aplicación no suele gustarles que les digas que vas a invertir un tiempecito migrando a una nueva versión de algo que no conocen y que además para utilizarla es necesario cambiar la versión del servidor de aplicaciones en producción… así que hemos tenido que “invertar” alguna cosa, para dar ese comportamiento dinámico que nos requería el usuario final. Concretamente la primera petición de nuestros usuarios vino para recuperar la irradiación (cantidad de sol recibido por un punto de la superficie terrestre) a partir de las coordeandas seleccionadas por el usuario en un mapa (en este caso generado con Google Maps) sin necesidad de realizar un submit y recargar toda la página…

Estuvimos viendo distintas alternativas como dojo (aunque se caracteriza más por su librería de componentes gráficos javascript también tiene funcionalidad para realizar llamadas ajax), prototype, el uso del objeto XMLHttpRequest, y otros aunque finalmente nos decidimos por DWR dada la facilidad con la que se puede utilizar en un entorno Java. En realidad, después de un poco de tiempo trabajando con DWR coincido bastante con la forma en que ellos se definen en su site: “DWR es una librería java que permite al código java ejecutado en un servidor de aplicaciones y al código Javascript ejecutado en un navegador interactuar entre ambos de la manera más simple posible” y su eslogan es: “DWR is Easy Ajax for Java”

Bueno, a grandes rasgos nos encontramos con dos piezas que son necesarias para que esto funcione:

• Un servlet java ejecutándose en el servidor que procesa las peticiones Ajax recibidas y devuelve la respuesta al navegador
• Una librería javascript en el navegador utilizada para enviar peticiones al servidor y recibe las respuestas desde éste para actualizar la página que se muestra

Vale y como funciona realmente?

• DWR genera dinámicamente el código javascript para que cada una de las clases java de servidor expuestas como servicios AJAX puedan ser accedidas desde javascript. Es decir el javascript generado por DWR crea un objeto javascript que puede ser referenciado desde cualquier parte de nuestro código js en el navegador.
• El objeto creado se encarga de abstraernos de la comunicación con el servidor. Cuando se invoca a alguno de los métodos javascript ofrecidos se desencadena una llamada al servidor en la que DWR se encarga del envío y recepción (marshalling / unmarshalling) de los parámetros de forma transparente.

Y aquí tenemos un diagrama sencillo de como funciona.

Si queréis ver un ejemplo muy sencillo de lo que hay que hacer para poner esto a funcionar podéis ir a un tutorial en la página oficial de DWR

A partir de la versión 2 (la actual es la 3) ofrece una funcionalidad que ellos llaman “reverse ajax” que permite realizar acciones “push” al estilo comet… También ofrecen dentro de la librería javascript un conjunto de funciones de utilidad para manejar los objetos HTML / JS en cliente / navegador. Y parece que también están trabajando en integrarse con algunos frameworks de componentes de interfaz de usuario como Dojo o Yahoo YUI .

En mi opinión hay otros frameworks / especificaciones que ofrecen una solución completa cubriendo el ciclo de peticiones en servidor (como por ejemplo JSF), pero para algo rápido, sencillo y fácil merece la pena… y si finalmente se integran con alguno de los frameworks de componentes gráficos que hemos dicho antes no habría que perderles la pista…

Óscar Rodríguez, director de dispositivos móviles de la compañía en España, anunció el pasado miércoles 17 de diciembre, que el fabricante de móviles estadounidense ha decidido cambiar su estrategia y abandonar Symbian en todos sus aparatos multimedia por el nuevo sistema operativo de código abierto diseñado por Google.

Motorola viene sufriendo en los últimos meses, al igual que sus competidores, una caída de ventas por el desplome del consumo y ha decidido aprovechar esta crisis para cambiar sus teléfonos con el objetivo de competir mejor en un mercado cada vez más exigente, lo que le obligará a paralizar prácticamente toda su producción en 2009 para adaptar sus aparatos, con la inevitable caída de la cuota de mercado. Rodríguez afirmó en el anuncio que “La compañía está saneada y podemos aguantar tres trimestres con menores ventas a cambio de hacer una apuesta de futuro”.

Mientras se realiza la transición a Android los consumidores sólo podrán elegir entre uno o dos teléfonos Motorola por gama. A partir de ahora, los teléfonos de Motorola utilizarán tres sistemas: Android para los dispositivos multimedia, Windows Mobile para el mercado de aparatos profesionales y el sistema propio del fabricante para los teléfonos de gama más básica.

Motorola (que forma parte de la Open Handset Alliance) ya había anunciado en octubre su intención de adoptar Android como sistema operativo para algún modelo, para lo cual había anunciado una inversión de 50 millones de dólares. Ese anuncio se hizo justo después del lanzamiento en EEUU de su primer terminal con pantalla táctil (Krave ZN4), algo casi imprescindible para sacar partido a Android.

Por su parte Nokia, propietaria del 100% de Symbian, el líder de sistemas operativos para teléfonos móviles, anunció justo después del nacimiento de Android que en dos años el sistema operativo sería abierto, lo que unificará sus versiones y se abrirá a más fabricantes. La batalla está servida.

Durante nuestra estancia en Amberes tuve la oportunidad de asistir a una conferencia sobre seguridad web. La conferencia la ofrecía un miembro del destacado del OWASP. Me pareció interesante el trabajo de esta organización y voy a emplear el presente post para hablaros sobre la misma.

¿Qué es el OWASP?

El proyecto abierto de seguridad en aplicaciones Web (OWASP por sus siglas en inglés) es una comunidad abierta y libre de nivel mundial enfocada en mejorar la seguridad en las aplicaciones de software. Nuestra misión es hacer la seguridad en aplicaciones “visible”, de manera que las organizaciones puedan hacer decisiones informadas sobre los riesgos en la seguridad de aplicaciones. Todo mundo es libre de participar en OWASP y en todos los materiales disponibles bajo una licencia de software libre y abierto. La fundación OWASP es una organización sin ánimo de lucro.

¿Qué puede aportarnos?

El OWASP ofrece dos tipos de aportaciones: proyectos de documentación y proyectos de desarrollo. La documentación está escrita en un lenguaje muy didáctico, pero es a su vez completa. Puede ser interesante como punto de entrada a proyectos cuya componente principal es la seguridad.

¿Qué proyectos de documentación existen?

La documentación es tanto escrita como audiovisual. Los recursos disponibles son los siguientes:

Guía de proceso:

Es una guía que describe una serie de “actividades empaquetadas” orientadas a roles, con el objeto de que el usuario sea capaz de introducirlas dentro de su proceso de desarrollo de software. Es descargable desde aquí.

Vulnerabilidades top 10:

Este proyecto ofrece información acerca de las 10 principales vulnerabilidades existentes en cada momento. Dispone de dos interesantes guías:

• La guía top 10: Explica cada una de las vulnerabilidades más detectadas en aplicaciones web, y ofrece numerosos links sitios web con información. Es descargable de aquí.
• La guía top 10 JavaEE: Esta guía ofrece información aplicada a JavaEE. Es descargable desde aquí.

Screencasts:

Anualmente el OWASP realiza una conferencia en estados unidos, de una semana de duración. Las conferencias son descargables desde aquí.

Guías tecnológicas:

Existen tres guías tecnológicas diferentes:

• Guía de desarrollo: La guía de desarrollo va orientada a arquitectos, desarrolladores, consultores y auditores. Se centra en el diseño, desarrollo y despliegue seguro de aplicaciones. Existen en este momento una guía estable (2.0.1), y una guía en elaboración (3.0). Ambas están disponibles aquí, aunque la 3.0 no es descargable en formato pdf.
• Guía de revisión: Es una guía orientada a aquellos cuyo trabajo es revisar en código fuente en busca de problemas de seguridad. Es descargable desde aquí.
• Guía de testing: Es una guía orientada a testers. Tiene una serie de escenarios y casos de prueba recomendables. Descargable desde aquí.

Guía legal:

Esta guía ofrece ayuda para elaborar contratos vinculados a productos de software en los que la seguridad sea un pilar importante. Ofrece un anexo de ejemplo a agregar a los contratos. Es descargable desde aquí.

¿Qué proyectos de desarrollo existen?

Proyecto Web Goat: http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

Es un proyecto orientado a ofrecer un entorno en el cual se puedan poner en práctica vulnerabilidades y prácticas de seguridad sin problemas legales.

Proyecto Web Scarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

Es una aplicación que se pone como proxy entre el navegador y los servidores http, y sirve para monitorizar, modificar y estudiar técnicas de seguridad sobre protocolo http.

Proyecto DotNet: http://www.owasp.org/index.php/Category:OWASP_.NET_Project

Este proyecto contiene contenido relacionado con el aseguramiento de aplicaciones y servicios sobre tecnología DotNet.

Proyecto Java: http://www.owasp.org/index.php/Category:OWASP_Java_Project

Este proyecto contiene contenido relacionado con el aseguramiento de aplicaciones y servicios sobre tecnología Java.

Otros proyectos: http://www.owasp.org/index.php/Category:OWASP_Project

Hola a todos:

Como algunos de vosotros ya sabréis, Media Net ha decidido plantar una pica en Flandes (más bien dos) y enviarnos a Ángel Rey y a mí al Devoxx (anteriormente llamado Javapolis). Después de dos conferencias matutinas aprovecho un receso para comenzar a escribir este artículo.

Este no trata sobre nada del Devoxx: para esto ya habrá otros artículos. Este artículo trata sobre Mercurial: una herramienta de control de versiones. Esta herramienta la estamos implantando ahora mismo en el proyecto que estoy trabajando (desarrollo de calculadoras de productos financieros en tiempo real). En este artículo os describo el escenario que nos ha llevado a utilizarlo, y cuáles son nuestras impresiones después de probarlo. La explicación la realizo en modo FAQ.

¿Que es Mercurial?

Mercurial es un sistema de control de versiones que cuenta con las siguientes características:

• Es transaccional: Cada cambio sobre el repositorio se ejecuta atómicamente para todos los elementos implicados en el mismo; sean archivos, directorios y/o metadatos.
• Es un sistema distribuido: El histórico de los archivos gestionados no se encuentra en un único servidor centralizado al que los desarrolladores suben sus cambios. Cuando un desarrollador descarga los archivos de un proyecto de Mercurial, éste descarga además una copia completa del histórico de cambios. De esta manera el desarrollador es capaz de reproducir el estado de la aplicación en cualquier momento de su historia sin necesidad de conectarse a un repositorio centralizado.
• Desarrollado en python y algo de C.
• Funciona tanto en modo Push como en modo Pull; dando flexibilidad a las políticas de versionado a aplicar.

¿Por qué nos hemos decidido a utilizarlo?

Los motivos son los siguientes:

• El modelo de versionamiento de CVS no nos convencía. Hemos tenido bastantes problemas de inconsistencia cuando hemos querido descargar versiones anteriores de nuestro software desde el repositorio de CVS. Por otro lado, los desarrolladores de mi equipo se liaban mucho cuando bajaban una versión antigua de un archivo debido a que si posteriormente hacían un commit sobre una de las carpetas que contenía estos archivos, CVS creaba una nueva rama para estos de manera no transparente. En muchas ocasiones nos vimos en la necesidad de corregir estos problemas. En Mercurial la creación de una nueva rama (branch) forma parte del día a día. Toda descarga de fuentes es en realidad una nueva rama. Esto ha obligado a los desarrolladores de Mercurial a que la gestión de ramas sea muy eficiente.
• Los problemas que hemos tenido con CVS al resolver colisiones. En ocasiones han desaparecido cambios muy costosos de recuperar. De su desaparición nos enteramos solo después de ver que nuestras pruebas unitarias fallaban de manera estrepitosa durante la integración. Mercurial es muy conservador para esto: no se mete a resolver colisiones de manera automática, sino que deja esta responsabilidad siempre en manos del desarrollador.
• La posibilidad de clonar directorios de manera tan sencilla nos facilita realizar copias de seguridad con más frecuencia. Sacar una copia de seguridad del CVS era un suplicio; sobre todo teniendo en cuenta que la copia se realizaba para todos los proyectos del repositorio incluidos los de los proyectos con los cuales compartíamos el repositorio. En Mercurial clonar un repositorio es tan fácil como copiar archivos, y además toda clonación lleva asociado su histórico de cambios.
• CVS no es transaccional. Dado que la máquina en la que está ubicado tiene problemas de estabilidad nos ha ocurrido varias veces que una subida de cambios se ha aceptado solo parcialmente. Mercurial es completamente transaccional.
• Necesitábamos una herramienta cuyos requisitos de instalación a nivel de permisos de administración fueran los mínimos posibles. En nuestro proyecto actual el entorno de desarrollo que nos ha facilitado el cliente no es tal entorno “de desarrollo”, ya que ni lo controlamos nosotros, ni es un entorno aislado (hay como 30 aplicaciones haciendo pruebas sobre la misma máquina).
• No tenemos posibilidad de realizar pruebas de usuario en nuestros entornos de trabajo antes de subir los cambios a un repositorio porque nuestra aplicación se conecta con sistemas externos a través de APIs que solo están instaladas en el entorno de integración. Además algunas de las librerías utilizadas solo funcionan sobre Unix, mientras que nuestros entornos de trabajo son Windows.
• Los mercados de tiempo real tienen unas condiciones de trabajo que son continuamente monitorizadas por los operadores de los mismos. Una incidencia puede dar lugar a multas millonarias. Es fundamental que podamos reproducir cualquier versión de manera rápida para corregir cualquier error. Por otro lado necesitamos la facilidad de poder agregar o quitar funcionalidad hasta pocos días antes de publicar una versión. Mercurial permite reproducir cualquier versión del histórico a partir de cualquier clon de cualquier rama de cualquier entorno, incluido el de los desarrolladores, con lo cual es muy fácil reproducir incidencias de manera rápida. También permite agregar cambios de distintas ramas de desarrollo de manera sencilla e individual.
• La aplicación es altamente concurrente, paralela, multi-hilo, y calcula productos financieros en base a modelos complejos. Es ventajosa la capacidad que da Mercurial al responsable de una rama estable. No son los desarrolladores quienes suben los cambios a la rama estable (modelo push), sino que es el responsable de esta rama quien va demandando los cambios a las ramas de los desarrolladores (modelo pull). Esto permite probar las aplicaciones en ramas de prueba, y posteriormente integrar los cambios individuales solo cuando ya han sido probados y revisados.
• Uno de los problemas que veíamos al uso de Mercurial era la integración con eclipse. Clonar repositorios nos obliga a clonar los proyectos y el workspace de eclipse para poder trabajar. Por suerte existe un plugin (Merclipse) que realiza esta tarea.

¿Cómo funciona el control de versiones?

Cuando un desarrollador descarga un proyecto del control de versiones, en realidad lo que está haciendo es clonar el repositorio de origen. No existen diferencias entre ambos repositorios después de la operación. Haciendo un símil con subversión, es como si cada desarrollador tuviera un servidor de subversión instalado en su equipo. Este “servidor” contiene toda la información histórica del proyecto.

Al clonar el repositorio se crean dos espacios:

• Repositorio público: Contiene el histórico de cambios. Es visible desde otros repositorios.
• Espacio de trabajo: Se genera a partir del histórico. El desarrollador solicita un “update” de una versión determinada, y Mercurial actualiza el espacio de trabajo para que contenga los fuentes de dicha versión.

A la hora de trabajar, un desarrollador realiza los cambios sobre su espacio de trabajo. Cuando quiere poner los cambios a disposición de los demás, este los sube al repositorio público mediante el comando “commit”. Desde este momento los cambios están visibles desde otros repositorios. Hasta aquí el modelo de trabajo es similar al de un control de versiones centralizado con la diferencia de que el servidor es propio de cada rama.

Cuando llega el momento de sincronizar dos repositorios distintos Mercurial ofrece dos comandos: “push” y “pull”. Push se emplea cuando se desea transferir cambios desde un repositorio a otro, y Pull se emplea cuando se desea tomar desde un repositorio los cambios de otro repositorio. Este segundo modelo es más seguro porque permite que un responsable determine qué es lo que le interesa que su rama contenga.

Con estas herramientas un desarrollador tiene capacidad de clonar un repositorio estable, y a su vez clonar esta rama de nuevo para implementar cada nueva funcionalidad por separado. De este modo pueden probarse e integrarse las funcionalidades de modo independiente.

En el caso de nuestro proyecto actual las ramas existentes son las siguientes:

• Rama estable: Es la rama desde la que se generan las versiones publicables. Ubicada en la máquina de integración. Está bajo control del responsable de proyecto y solo toma cambios desde las ramas de desarrollo.
• Ramas de desarrollo: Cada desarrollador tiene una rama en la máquina de integración para subir y probar sus cambios. Esta rama se clona desde la rama estable al comienzo de cada iteración. Una vez probados, estos cambios se revisan para asegurar que se están cumpliendo las especificaciones de desarrollo y las buenas prácticas establecidas. Hecho esto el responsable de proyecto realiza un pull e importa los cambios sobre la rama estable.
• Ramas locales: Cada desarrollador tiene una rama local principal que se clona a partir de su rama de desarrollo al comienzo de cada iteración. El desarrollador puede clonar tantas ramas a partir de esta como estime oportuno. Idealmente una por funcionalidad.

¿En que se diferencia de subversion?

Subversion es un sistema que nos gusta, pero no respondía a nuestras necesidades porque:

• Únicamente se puede tener un repositorio central. No nos resuelve la papeleta de tener varias ramas en el entorno de desarrollo.
• El esquema de versionamiento y el sistema de ramificación es mucho menos flexible. Nos permite realizar menos adaptaciones. Con Mercurial las políticas de ramificación, mezclado y subida de cambios son un mero evento social.
• No es capaz de funcionar en modo pull. Solo admite modo push, y nos ha gustado mucho el control sobre los cambios que nos da este esquema de funcionamiento.

Está muy chulo todo esto, ¿pero donde está la pega?

Las pegas que yo veo son las siguientes:

• Requiere por parte de los desarrolladores un cambio de mentalidad a la hora de trabajar con el control de versiones.
• Al ser muy flexible permite hacer muchas cosas bien, pero también muchas cosas mal. Obliga a ser muy disciplinado. Un símil a lo que pasa con C++ y JAVA.
• Las herramientas de usuario aún no están tan maduras como pueden estar las de subversión, CVS, u otros controles más populares. Sin embargo la línea de comando se la han currado mucho y es muy sencilla, muy coherente, y muy intuitiva.

¿De dónde puedo descargarlo?

Podéis descargarlo desde http://www.selenic.com/mercurial/wiki/. En este sitio Web hay manuales (muy buenos), ejecutables, código fuente y guías de ayuda rápida.
El plugin de Merclipse lo podéis descargar de http://www.goldenhammers.com/merclipse/.
¿Tengo que hacer algo en especial para instalarlo?
Nada. Se instala mediante un instalador. Instalar y ejecutar.