Tutorial de desarrollo de aplicaciones Firefox OS – Parte I

FFxOS3

Aunque las cuotas de mercado de los SO de los dispositivos móviles está claramente balanceada hacia iOS y Android, como desarrolladores no nos podemos olvidar de las nuevas plataformas móviles que van saliendo al mercado.

En este caso me voy a centrar en la plataforma de Firefox OS, para la que me parece que nos han facilitado muchísimo la labor del desarrollo de aplicaciones a aquellos que estamos acostumbrados al desarrollo Web.

Configurando el entorno de desarrollo

Para programar aplicaciones para Firefox OS no importará el IDE que utilicemos y podremos utilizar aquel con el que nos sintamos más cómodos, desde el Eclipse hasta el bloc de notas. Solamente será necesario instalar el simulador de aplicaciones r2d2b2g, que es un simple plugin del Mozilla Firefox.

Podremos instalarlo simplemente pinchando en este enlace desde el Mozilla Firefox, aunque como recomendación personal lo haría desde el Firefox Aurora, que es la versión para desarrolladores de Firefox.

Una vez tengamos instalado el r2d2b2g, lo ejecutamos en Herramientas -> Desarrollador Web -> Firefox OS Simulator.

firefoxOS_01

Ejecutando nuestra primera aplicación

En la próxima parte del tutorial explicaré la estructura de una aplicación así como los diferentes puntos de la misma, pero de momento dejo aquí una aplicación de ejemplo para probar el simulador.

Para abrir la aplicación de prueba descomprimirmos el fichero descargado, pulsamos en Add Directory y buscamos en nuestro directorio el fichero manifest.webapp.

firefoxOS_02

A continuación pulsamos en Run y se abrirá nuestra aplicación de prueba.

firefoxOS_03

La aplicación sólo tiene un par de funciones haciendo uso de las funciones propias del SO como el envío de SMS, correos electrónicos o acceder a una dirección Web.

 

Hasta la próxima entrega!

Documentar, documentar, documentar!!!

documentar

En el proyecto en el que estoy trabajando ahora mismo entramos en una fase de “traspaso de conocimiento al cliente“, en el que debemos entregar a los informáticos del cliente toda la documentación de los proyectos en los que hemos trabajado en los últimos 3 años.

Al principio recibí esta noticia sin ningún sobresalto. Sólo tendría que recopilar del gestor documental para cada aplicativo, el análisis previo realizado para la toma de requisitos con su correspondiente análisis funcional, la documentación de la base de datos, el manual de usuario y verificando que toda esta documentación estuviese al día y sumado a un código bien comentado tendría esta entrega preparada en, como mucho, un par de días, pero…

¿Existía toda esta documentación en el gestor documental?

Pues como muchos intuiréis, NO. Resulta que, a pesar de que los módulos y aplicaciones de los que me he encargado yo si tenían toda la documentación mencionada, para la mayoría de los módulos y aplicativos existía, como mucho, uno o dos de los documentos que yo esperaba encontrar, y es que por lo general no nos gusta documentar, pero eso no es excusa para hacerlo.

Con este artículo tengo la intención de concienciar un poco a la gente para que trate de mantener una documentación mínima de los desarrollos en los que trabaja que, a pesar de ser una tarea aburrida y engorrosa, es también una parte importante de nuestro trabajo.

He oído muchísimas excusas para evitar documentar: La mejor documentación es el código fuente, el manifiesto ágil afirma que se valora más el software que funcione que la documentación exhaustiva, es una pérdida de tiempo, no se lo va a leer nadie…

Ninguna de las excusas para mi es suficiente. Soy un firme defensor de las metodologías ágiles y creo que es una mala interpretación de las mismas el hecho de descartar la documentación de los aplicativos ya que una cosa es que se valore mas el software que funcione y otra muy diferente es que no sea necesaria.

Para seguir con el ejemplo que estoy viviendo ahora mismo, en un proyecto con una complejidad media ahora mismo tenemos problemas para realizar la documentación de lo que no estaba documentado ya que las cosas que parecieron obvias en el momento de desarrollarlas ahora parece que carezcan de sentido y para las que parece que tienen sentido, desconocemos en qué reglas de negocio se basó su desarrollo. Ésto termina traduciéndose en que el propio programador que hizo un módulo hace 3 años, en el principio del proyecto, ya no sabe ni porqué hizo las cosas qué hizo ni cómo las hizo, entonces yo pregunto ¿Si tu no sabes cómo va, cómo pretendes que otra persona retome tu desarrollo?

En cuanto a qué nivel de documentación llegar no creo que exista un nivel óptimo y pienso que en cada proyecto es la propia experiencia la que define hasta donde debe cubrir la documentación, pero desde mi experiencia si he visto que normalmente se puede cubrir la documentación con 4 puntos mínimos:

  • Toma de requisitos: El primer punto que es necesario para documentar un aplicativo es saber qué se espera de éste. Ésta no será una tarea muy compleja si simplemente tomamos nota de qué es lo que quiere el usuario.
  • Análisis funcional: También debemos reflejar cómo resolverá el aplicativo las especificaciones  del cliente. Sólo será necesario apuntar en un documento de forma organizada qué será lo que se desarrollará para cada requisito.
  • Definición Técnica: En este documento especificaremos la tecnología utilizada, arquitectura, etc. En otras palabras lo básico para que un programador sea capaz de comprender cómo está montado el proyecto.
  • Documentación en el código: No creo que tenga que explicar mucho en este punto, pero todos sabemos que como mínimo debemos comentar las cabeceras de las clases, procedimientos y funciones, así como el código que no se explique sólo.

Podemos apreciar que ninguno de los puntos descritos supone un gran esfuerzo para mantener una documentación mínima ya que en la mayoría de ellos lo único que debemos hacer es reflejar por escrito  lo que estamos haciendo ya sea en un correo electrónico, un gestor documental o incluso un conjunto de notas tomadas en servilletas.

Por supuesto estos 4 puntos no son obligatorios, ni constituyen una metodología, ni nada por el estilo. Es simplemente un ejemplo de una forma de cubrir la documentación y que en particular en los casos con los que me he encontrado ha funcionado.

En conclusión, una documentación mínima no supone un gran esfuerzo si se realiza a medida que vamos desarrollando y evitará, en el mejor de los casos, que un nuevo compañero se encuentre completamente perdido y, en el peor de los casos, que seamos nosotros mismos los que nos perdamos.

Integración continua

“La integración continua es una práctica de desarrollo de software donde los miembros de un equipo de trabajo integran su trabajo con frecuencia, por lo general cada miembro integra su trabajo por lo menos una vez al día. Cada integración es verificada por un sistema automatizado de construcción (incluyendo los tests) para detectar los errores de integración lo más rápidamente posible.” – Martin Fowler

Trabajando con IC

Pongámonos en situación en un ejemplo de proyecto real con integración continua:

  • El proyecto está bajo un control de versiones con SVN.
  • Tenemos instalada una herramienta de automatización de ejecución de tests y compilación.

En el momento en el que nos enfrentamos a una nueva tarea lo primero que hacemos es actualizar nuestra copia del proyecto local con lo existente en el repositorio del SVN.

Posteriormente realizamos la tarea que se nos ha asignado y creamos o modificamos los tests asignados a esta tarea.

Apoyándonos en nuestra herramienta de automatización (En mi caso, me gusta utilizar maven para los proyectos Java), lanzamos la ejecución de los test, compilamos y probamos el binario generado en un entorno idéntico al de producción.

Una vez verificamos que todo haya ido correcto, revisamos que el estado del repositorio sea el mismo que en el momento de actualizar nuestra copia local. En caso de no haber variado el repositorio, ya podemos subir los cambios a éste y en el supuesto de que ya se nos hayan adelantado subiendo una nueva versión de los fuentes, actualizamos nuestra copia local y volvemos a realizar la compilación y ejecución de los tests.

De este modo, tendremos como resultado en el repositorio una versión estable de nuestro proyecto en cualquier momento del ciclo de vida del mismo, ya que los errores son detectados rápidamente y solventados antes de actualizar los trabajos en la línea principal del repositorio.

Realización de una tarea con IC

Realización de una tarea con IC

Prácticas clave para trabajar con integración continua

Mantener un repositorio de código fuente único.

El uso de un repositorio de código fuente nos permite garantizar que todo el mundo tendrá acceso a los mismos recursos. Hay una gran variedad de repositorios pero cada vez se está empleando mas como estándar el SVN o Subversion.

Automatizar la construcción

A medida que los proyectos van creciendo, la construcción de los mismos puede llegar a ser muy complicada (compilar en un orden determinado, mover los archivos de aquí a allá, cargar los esquemas en BBDD, etc). Esto acarrea dos problemas fundamentales:

  • Si pretendemos construir nuestro proyecto una o varias veces al día para testear el trabajo realizado nos quitará mucho tiempo y se convierte en una tarea pesada.
  • La construcción manual de un proyecto complejo termina significando errores ya que puede que se nos quede atrás algún paso en el proceso de construcción.

Para evitar estos problemas, podemos automatizar estas tareas, de modo que se puedan ejecutar con un solo comando.

Para mi la herramienta por excelencia para los desarrollos en Java es maven, que además de construir nuestro proyecto es capaz de ejecutar los test definidos.

Incluir tests automatizados

Cada vez se generaliza más el empleo de técnicas como TDD (Test Driven Developer), lo que ha fomentado que muchas personas se den cuenta del valor de programar unos buenos tests.

Para el caso de los proyectos Java yo suelo utilizar la librería jUnit, con la que es muy sencillo preparar las pruebas unitarias y específicamente para los proyectos Web Selenium, que permite preparar pruebas funcionales de las aplicaciones.

Por supuesto, los test no garantizan que todo funcione correctamente, pero nos asegura un mínimo de funcionalidades que están correctas, reduciendo el número de Bugs de las mismas.

Todo el mundo debe subir los cambios a diario

Este punto quizás es uno de los mas importantes. Cuando se pasan muchos días si subir los cambios se puede convertir en un infierno integrar los cambios realizados con la línea principal del proyecto.

Probar el resultado en un clon del entorno de producción

Hemos visto hasta ahora todo el proceso desde el punto de vista del programador, pero la IC no acaba ahí. Una vez se suben los cambios al repositorio es importante probar el proyecto completo en una copia exacta del entorno de producción, teniendo de esta forma la certeza de que la última versión es estable.

En resumen

Con el uso de la IC tendremos las siguientes ventajas:

  • Posibilita la detección temprana de errores, minimizando los costes de resolución.
  • Se minimizan los costes de integración entre las funcionalidades que se van añadiendo al producto.
  • Se anima a los desarrolladores a integrar su código lo antes posible.
  • Permite controlar la estabilidad del producto.

 

Enlaces de interés: artículo de Martin Fowler sobre integración continua.

Probando Artifactory Open Source – Parte IV – Uso

Para finalizar el análisis de Artifactory veremos cómo añadir artefactos manualmente al repositorio y cómo utilizar nuestro repositorio de Artifactory en nuestros proyectos.

Despliegue manual de artefactos

Para desplegar manualmente nuestros artefactos iremos a la pestaña Deploy y subiremos nuestro artefacto compilado.

10-artifactory-deploy-artifacts

 

Posteriormente configuraremos la información detallada del artefacto y pinchamos en Deploy Artifact.

11-artifactory-deploy-2

 

Con esto ya tendremos nuestro artefacto disponible en el repositorio.

Configurar el repositorio para nuestros proyectos

Para que nuestros proyectos hagan uso del repositorio de Artifactory tenemos dos opciones:

  • Configurar el settings.xml de nuestra instalación de maven.
  • Configurar el pom.xml de nuestro proyecto maven.

En ambos casos bastará con sustituir, o añadir en caso de que no existan, la definición de los repositorios por lo siguiente:

<repositories>
    <repository>
        <id>central</id>
        <url> http://[host]:[port]/artifactory/libs-release </url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
    <repository>
        <id>snapshots</id>
        <url> http://[host]:[port]/artifactory/libs-snapshot </url>
        <releases>
            <enabled>false</enabled>
        </releases>
    </repository>
</repositories>
<pluginRepositories>
    <pluginRepository>
        <id>central</id>
        <url> http://[host]:[port]/artifactory/plugins-release </url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </pluginRepository>
    <pluginRepository>
        <id>snapshots</id>
        <url> http://[host]:[port]/artifactory/plugins-snapshot </url>
        <releases>
            <enabled>false</enabled>
        </releases>
    </pluginRepository>
</pluginRepositories>

Probando Artifactory Open Source – Parte III – Configuración

Continuando con el análisis de Artifactory, en esta entrada veremos algunas de las opciones de configuración.

Acceso

Para comenzar accederemos a Artifactory en la URL http://servidor:8081/artifactory y usando el par usuario/contraseña admin/password.

01-artifactory-login

 

Configuración general

Entrando en la pestaña Admin, podremos acceder a la configuración general.

general.configuration.14.10.10

Desde esta pantalla podemos configurar lo siguiente:

  • El nombre del servidor.
  • URL base personalizada.
  • El tamaño máximo permitido para los archivos subidos a través de la interfaz web.
  • El formato de fecha para mostrar fechas en la interfaz web.
  • Indicador de que Artifactory se encuentra fuera de línea (Sin conexión a internet).
  • Logo y slogan.
  • Mostrar información y ayuda como menús contextuales.

Configurar repositorios

Debajo de la configuración general encontraremos la configuración de repositorios.

02-artifactory-repositories

Como podemos observar, ya hay cargados una serie de repositorios por defecto agrupados en las siguientes categorías:

  • Repositorios locales: Repositorios físicos, gestionados localmente, donde podemos desplegar artefactos.
  • Repositorios remotos: Repositorios remotos para los que Artitactory actuará como proxy y caché.
  • Repositorios virtuales: Agrupan varios repositorios físicos bajo la misma URL.

Para eliminar, añadir o modificar los repositorios simplemente haremos uso de los menús existentes.

 

Administración de seguridad

Artifactory nos provee, entre otras, las siguientes opciones:

  • Gestión de usuarios
  • Gestión de grupos
  • Administrar permisos
  • Administración de seguridad con LDAP

 

Para obtener mas información puede acceder a la Wiki del proyecto Artifactory

 

Probando Artifactory Open Source – Parte II – Instalación

En la entrada anterior vimos las ventajas de utilizar Artifactory como repositorio para nuestros proyectos maven.

Hoy explicaré cómo instalar de diferentes modos esta herramienta.

Artifactory puede ser instalado y ejecutado de diferentes modos:

  • Como servicio de Windows o Linux.
  • Ejecución manual.
  • Usando la distribución RPM.
  • En otros servidores de aplicaciones desplegado como aplicación WAR estándar. (Se recomienda Tomcat 6 o 7)

Como requisito previo debemos tener debidamente instalado Java JDK 1.6 o superior y la variable de entorno JAVA_HOME configurada.

Instalación como servicio

En Windows

Ejecutar

%ARTIFACTORY_HOME%\bin\InstallService.bat

donde %ARTIFACTORY_HOME% es la ruta donde hemos descomprimido Artifactory.

En Linux

Ejecutar

$ARTIFACTORY_HOME/bin/install.sh

para instalar y posteriormente

service artifactory start

para arrancar el servicio.

Ejecución Manual

En Windows

Ejecutar

%ARTIFACTORY_HOME%\bin\artifactory.bat

En Linux

Ejecutar

$ARTIFACTORY_HOME/bin/artifactory.sh artifactoryctl start

Instalación de paquete RPM

Para la instalación del paquete RPM debemos ejecutar como usuario root el siguiente comando:

rpm -ivh artifactory-rpm-<version>.rpm

Acceder a Artifactory

Una vez se finalice la instalación y/o el arranque, la interfaz Web será accesible desde http://servidor:8081/artifactory y por defecto accederemos a ella usando el par usuario/contraseña admin/password.

 

Para obtener mas información puede acceder a la Wiki del proyecto Artifactory

 

En el siguiente artículo veremos la configuración básica de Artifactory

 

Probando Artifactory Open Source

El problema

En uno de los proyectos con los que me encuentro actualmente se está empezando a convertir en un infierno la carga de las dependencias de maven cada vez que es necesario hacer un update de las mismas o simplemente se incluye a nuevo integrante en el proyecto y comienza a montar el proyecto en su equipo para comenzar con el desarrollo.

Los mayores problemas con los que nos encontramos son los siguientes:

  • Extremada lentitud en la descarga desde los repositorios de maven debido a la gran cantidad de dependencias del proyecto.
  • Necesidad de importar proyectos internos adicionales al que estamos trabajando y compilar los mismos para que queden añadidos al repositorio local.
  • Se requiere la instalación manual en el repositorio local de dependencias no existentes en repositorios (por ejemplo el JDBC de Microsoft SQL Server).
  • Desaparición de librerías de terceros en los repositorios de maven.

 ¿Por qué Artifactory?

artyfactory

Artifactory es un Repositorio de maven en el que se almacenan las dependencias de nuestros proyectos. Algunas de sus principales características son:

  • Actúa como proxy entre los repositorios de maven y los locales.
  • Mantiene en caché las dependencias descargadas, ahorrando tiempo de descarga en veces posteriores y evitando perder las dependencias que en un momento u otro fueron parte del proyecto.
  • Permite controlar qué repositorios se utilizan, qué artefactos descargar, cuáles bloquear, cómo se despliegan, quién los despliega y muchas opciones mas.
  • A través de un wizard es posible el despliegue manual de artefactos dentro del repositorio, con lo que podemos dejar dentro de nuestro repositorio tanto nuestras librerías como las de terceros que no se encuentran en los repositorios de maven.
  • Con su instalación por defecto, puede estar funcionando en tan sólo unos minutos.
  • Es de fácil configuración.

En resumen, observando sus características, no es muy difícil entender que nos solventa los problemas mas comunes cuando trabajamos con proyectos maven además de simplificarnos mucho el trabajo.

 

En siguientes entradas veremos las diferentes opciones de instalación, configuración y uso de Artifactory.