Wednesday 5 November 2014

Travis, o cómo elegir un CI para tu proyecto Java open source

Recientemente me incorporé al equipo de desarrollo de Arena, nuestro framework de MVVM UI pensado para que alumnos de diversas carreras universitarias den sus primeros pasos en el desarrollo de interfases de usuario. Hicimos un sprint para empezar a familiarizarnos con las herramientas y ahí detectamos algunos problemas en la forma de trabajo, que dificultaban un poco la incorporación de nuevos desarrolladores.
Los inconvenientes principales eran:
  • Para trabajar en un proyecto (hoy Arena se compone de 7 proyectos distintos) no había otra opción que compilar todos los demás, ya que al no estar sistematizado el deploy no siempre el SNAPSHOT se correspondía con la última versión del código. Entonces perdía un poco de sentido la separación en artefactos distintos.
  • Algunas veces se pusheaba al repositorio código que rompía los tests, o incluso no compilaba. Al no tener releases estables, podía darse el caso de que un deploy del SNAPSHOT rompiera los trabajos prácticos de los alumnos de una cursada, como sucedió alguna que otra vez.
  • Los artefactos se desplegaban en un repositorio propio y no en Maven Central, lo que implicaba un paso extra de configuración a la hora de preparar el entorno de desarrollo. Trataremos este tema en el siguiente post de esta serie.
¿Cómo solucionar esto? Automatizando estas tareas repetitivas por medio de un servidor de integración continua. No es el propósito de este artículo discutir los beneficios de esta práctica (para eso puede leerse este artículo de Martin Fowler), así que vamos a pasar directamente a la solución que puse en marcha.

Eligiendo un CI para Arena

Para los ansiosos, la implementación final de lo que contaré a continuación (incluyendo el próximo post) puede verse en el repositorio de Arena en GitHub. De todos modos, recomiendo leer cada una de las decisiones que tomé para entender qué es lo que hace el CI cada vez que se sube código nuevo al repositorio.

CIs Candidatos

Además de que fuera gratuito para Open Source Software (OSS), se necesitaba que cumpliera tres características:
  1. que fuera fácil de configurar y que no necesitara hosting propio.
  2. que soportara Java de forma nativa.
  3. que tuviera algún mecanismo para subir el settings.xml, necesario para poder hacer el deploy a Sonatype.
Entonces, en ese orden, descarté estos 3 productos:
  1. Jenkins, quizás el más conocido y flexible de los que voy a mencionar, pero con el overhead de tener que hostearlo en servidor propio y configurar todos los plugins.
  2. Semaphore, que suele ser mi opción preferida, pero como todavía no soporta Java “out of the box” es necesario bajar Maven en cada build.
  3. Y por último, drone.io, donde no encontré cómo solucionar el problema del settings.xml.
Finalmente mi elección fue Travis, obviamente en su versión para OSS.
(Un comentario al margen: Travis tiene también una versión para repositorios privados y, gracias a un acuerdo con GitHub, la ofrecen de manera gratuita e ilimitada para estudiantes mediante el student developer pack.)

Configurando Travis

La configuración de Travis está basada en el principio de convention over configuration. Para empezar a compilar y correr nuestros tests, basta crear un archivo llamado .travis.yml e indicar en su interior en qué lenguaje está realizado nuestro proyecto, en nuestro caso Java. El primer archivo de configuración se veía así:
language: java
¿En serio? ¿ya está? No del todo, pero ya estamos en condiciones de probar que funciona avisándole a Travis que monitoree el proyecto (esto se hace desde tu perfil) y luego haciendo un git push de algún cambio (aunque una mejor idea sería crear una branch de prueba y hacer un pull request).
Por defecto, Travis empezará a monitorear el repositorio y disparará un build por cada commit que se suba a cualquiera de sus branches, incluyendo pull requests. Una vez concluido dicho build, se encargará de notificar a GitHub el resultado, quien a su vez nos lo mostrará a nosotros como se ve en la siguiente imagen:
Pull requests validados por Travis
Con esa simple línea de configuración que le dimos, lo que se ejecuta es el default para Java, que consta de dos pasos:
  1. mvn install -DskipTests=true, baja todas las dependencias y compila el proyecto. ¿Y para qué le pone ese flag si también queremos que corra los tests? Cuando algo anda mal, Travis diferencia entre un build errored y uno failed, donde el primer estado está asociado con un error en la instalación (no compila, no se encontró alguna dependencia) y el segundo con alguna validación que se ejecuta (normalmente un test fallido). Entonces si llegara a fallar la instalación, ni siquiera se corren los tests y sabemos con certeza que el resultado es errored
  2. mvn test (no necesita explicación)
Hasta acá llega el primer post de esta duología. En el siguiente post explicaré los pasos necesarios para publicar la aplicación en el Maven Central Repository, utilizando Sonatype OSS como intermediario.
¡No dejen de compartir sus proyectos, ideas o experiencias en los comentarios!

Tuesday 14 October 2014

Java8: Traits or Mixins? That is the question

A couple of days ago, a discussion came up in one of our mailing list about the Java 8 Interfaces Default Methods. They were named as «mixins», but I corrected them and called «traits without flattening».
After sending the mail, that last sentence kept ringing in my head, so I proposed myself to try to understand why was I calling them like that, and I came up with this post.
Please, leave your comments below and don't forget to check the blog for the part 2!
Lucas.-
P.S.: If you didn't notice the link above, here it is again :) http://blog.10pines.com/2014/10/14/mixins-or-traits/

Tuesday 7 October 2014

Latest Arena Sprint

The last Saturday, we have had another Sprint of the Arena Project

Arena is one of the flagship projects of the Uqbar Foundation. 

Arena is an MVVM UI framework that strongly encourages the separation between model and ui classes. Although based on automatic bidirectional bindings and small single-responsability reusable controllers. Through this it clearly shape the core concepts of object design applied to UI-development.

It also implements a transparent AOP-based mechanism for object-level transactions and observability (object properties). This makes extremely easy the developer tasks in order to bind UI components with domain, by reducing repeatable domain code such as triggering events or handling transactions.

Arena is being used now since 2010 in several Argentinean Public Universities in order to teach the core concepts of object-oriented user interfaces.

The sprint was a really successful, 11 developers gathered to work in the project. 

The main objective of the Sprint was the integration of new developers to the project. Everybody getting a working development environment and through the use of pair programming everybody started improving Arena. 

The results of the sprint are amazing:


  • A new Continuous Integration effort has been started. The idea is to have an automatically integrated process to release and publish the changes. Every time a developer submit a change the process is fully automatic.
  • The whole project was migrated to Scala 2.11.
  • The documentation has been improved, with all the things the main developer show to everybody.
  • The site of Arena has been improved and fully integrated with the Maven building process.
  • We have started the process to integrate all the repositories and the migration to Git.
  • Also the process to get a copy of Arena into the main central repositories of Maven has been started.
  • Also a number of issues has been resolved and improvements added:
    • Now you can bind tooltips to the controls
    • The window can have a initial size.
    • The labels resize when the content is longer than previously
    • The tables can have a minimal number of rows to show.
    • You can know bind the visible property of panels.
    • The check boxes can be read only.
Even though the main idea was to integrate new developers to the project, we could achieve lots of issues and improvements.

Some nice pictures of the people working:








Monday 15 September 2014

Workshop WISIT 2014 - Convocatoria de Presentación de Trabajos

La fundación Uqbar, con el apoyo de la Universidad Tecnológica Nacional (UTN) FRBA, organiza el Workshop de Ingeniería en Sistemas y Tecnologías de Información (WISIT)Se desarrollará los dias 28 y 29 de noviembre en el Aula Magna de la UTN.BA, ubicada en Av. Medrano 951, Ciudad Autónoma de Buenos Aires.

Mas información