Secciones

Eclipse Mylyn Connector para GoogleCode

Buscando la forma de conectar eclipse con la gestión de tareas de googlecode, me encontrado este plugin http://code.google.com/p/googlecode-mylyn-connector/ que implementa la api IssueTrackerApi para google code http://code.google.com/p/support/wiki/IssueTrackerAPIJava.

Aquí os dejo un vídeo de como instalarlo y configurar un proyecto de googlecode en Eclipse Helios 3.6.

Saludos,
JK

MacUbuntu: Increible tema para Ubuntu

Hace unas cuantas semanas instalé y configure el tema MacBuntu para personalizar mi Ubuntu 10.10 y la verdad es que la apariencia es realmente buena. Aquí os dejo algunos screenshots para que veáis el resultado:






El proceso de instalación consiste en seguir los siguientes pasos:
  1. Descargarlo de la web de sourceforge http://sourceforge.net/projects/macbuntu/files/macbuntu-10.10/v2.3/Macbuntu-10.10.tar.gz/download
  2. Descomprimir el tar.gz 
  3. Ejecutar el script ./install.sh
  4. Seguir los pasos que aparecen por pantalla.
Una vez finalizado, podréis comprobar por vosotros mismos el cambio en vuestro escritorio.

El único problema que me he encontrado ha sido con eclipse, debido a que no aparece el menú de herramientas en el panel de control de ubuntu. Para solucionarlo hay que seguir las instrucciones descritas en este link donde se indica que basta con crear un script como este para arrancar eclipse:

#!/bin/bash
export UBUNTU_MENUPROXY=0
/opt/ide/eclipse/eclipse
Saludos,
JK

Repositorios públicos y privados en nexus

Para combinar repositorios públicos y privados en nexus es necesario realizar algunas adaptaciones en la configuración que viene por defecto.

Antes de comenzar a ver el detalle de los cambios a realizar, hagamos un pequeño resumen de los conceptos básicos.

Repositorios y grupos de repositorios

Un repositorio es una colección de artefactos de software y metadatos almacenados en una estructura de directorios definida que es utilizada por clientes como Maven o Ant  en un proceso de construcción.

Un grupo de repositorios es una agrupación de repositorios. 

Seguridad en nexus

La seguridad en nexus está organizada en 4 bloques:
  1. Users
  2. Roles. Agrupaciones de privilegios.
  3. Privileges. Funciones de nexus; por ejemplo lectura de repositorio, escritura sobre un repositorio, acceso a la consola de nexus, etc ...
  4. Repository targets. Es una expresión regular que se puede aplicar sobre un repositorio o grupo de repositorios.
Podéis encontrar un detalle más profundo de estos conceptos en este link

Personalización

Los objetivos que persigo con la adaptación que os propongo son:
  • Crear una serie de repositorios privados donde publicar los artefactos privados de nuestros proyectos.
  • Impedir que los usuarios anonymous puedan ver los repositorios privados.
  • Crear los roles para que los miembros de la organización puedan acceder a los repositorios privados.
Pasos

1. Crear dos repository targets; All private y All public 



 2. Crear los roles; Public Repository (Read) y Private Repository (Full Control)


3. Crear los grupos de repositorios public y private y asignar los repositorios a cada uno de ellos.


4. Eliminar el rol de lectura All repository read al usuario anonymous.

5. Asignar los nuevos roles a cada uno de los usuarios.

Saludos,

JK

Liquibase: El control de versiones para BBDD

Si en la anterior entrada escribía sobre Mercurial y los sistemas de control de versiones distribuidos, hoy hablaré de LiquiBase, un sistema similar pero para bases de datos.

En la mayoría de proyectos en los que he participado, existía un repositorio para gestionar las diferentes versiones de código, pero no pasaba lo mismo con los cambios que se realizaban en la base de datos. Para trazar estos cambios, se utilizaban mecanismos bastante primarios, como por ejemplo crear ficheros upgrades para actualizar los datos entre las diferentes versiones de proyecto.

Liquibase se presenta en su web de la siguiente forma:
You never develop code without version control, why do you develop your database without it?
Y en la mayoría de casos es cierto que lo que sucede es que una de las primeras tareas que se realizan es crear el repositorio de código, y en cambio no se hace lo mismo para los cambios en la BBDD. Esto provoca algunos inconvenientes:
  • faltan tablas, campos incorrectos, faltan columnas...
  • es necesario hacer una carga mínima de datos y nadie sabe cual debería ser.
  • se ha cambiado la versión del proyecto y es necesario cargar una nueva versión de base de datos.
  • el equipo de desarrollo utiliza mysql y el entorno de integración oracle
  • ...
Para mitigarlos, liquibase ofrece una serie de herramientas que permite:
  • Merging changes from multiple developers
  • Code branches
  • Managing production data as well as various test datasets
  • Cluster-safe database upgrades
  • Automated updates or generation of SQL scripts that can be approved and applied by a DBA
  • Database ”diff“s
  • Generating starting change logs from existing databases
LiquiBase permite a los desarrolladores almacenar los cambios de BBDD en archivos XML en sus entornos de desarrollo para luego aplicarlas al resto de BBDD.  Como los cambios se encuentran almacenados en el sistema de control de código fuente y se distribuyen al resto de desarrolladores, los cambios se pueden aplicar de forma simple al resto de entornos de BBDD; entorno de desarrollo local, entorno de integración, BBDD de pruebas, e incluso a BBDD de producción.  
Estos cambios pueden ser aplicados a través de varios métodos, ya sea a través de una Ant, Maven, línea de comandos o de forma automática durante la aplicación o el inicio del servidor de aplicaciones.
 
LiquiBase Migrator es el núcleo del sistema que permite de forma simple el desarrollo de aplicaciones de base de datos utilizando una metodología ágil. Como los cambios se aplican a la base de datos local durante el desarrollo, las diferentes revisiones se almacenan en un archivo de registro XML.

Cada cambio que se produce está identificado por:
  • un id
  • un autor
  • el nombre 
  • y la ubicación del archivo de cambio 
Cuando el proceso de migración se ejecuta, compara cada uno de los cambios con los que se encuentran en la tabla DatabaseChangeHistory. Esta tabla debe estar en cada una de las BBDD que forman parte del proyecto. Esta tabla contiene el "id", el "autor", y el "archivo" de identificación de todos los cambios que se han ejecutado. Si al ejecutar el proceso de migración hay cambios que no han sido aplicados, el proceso Migrator ejecuta y registra el cambio para que se omitirá en las siguientes ejecuciones del proceso Migrator.

Primeros pasos con Liquibase en Maven.

Para comenzar a utilizar liquibase en nuestros proyectos con Maven, podemos seguir los siguientes pasos:
  1. Agregar al pom.xml las dependencias del driver de BBDD que necesitemos.
  2. Agregar al pom.xml el plugin de liquibase.
  3. Crear el fichero src/main/resources/liquibase.properties
  4. Crear el fichero src/main/resources/org/liquibase/change_log.xml
  5. Por último, ejecutar mvn liquibase:update
El detalle lo podéis encontrar en:
 Una vez finalizado con éxito los pasos, tendremos en la BBDD test la siguiente información:

Más información.
Saludos,
JK.

Primeras impresiones : DVCS Mercurial

Después del anuncio acerca de que Atlassian había comprado Bitbucket y de que este utiliza Mercurial como SCM (Source Code Management) he decidido investigar más sobre Mercurial, ya que Atlassian siempre ha demostrado tener muy buen ojo con los productos/empresas que ha comprado.

Distributed VCS vs Centralized VCS

Distributed revision control o Distributed Version Control Systems o Decentralized Version Control Systems es un sistema de control de versiones o revisiones de software que permite a cada uno de los desarrolladores trabajar en el código sin necesidad de estar conectado a un servidor central.

Las ventajas que ofrece un sistema distribuido DVCS frente a uno centralizado CVCS son:
  • No hay una copia canónica, existen referencias al código en las workings copies.
  • Soporta operaciones desconectadas: La mayoría de operaciones comunes como commits, viewing history, diff, y reverting changes son rápidas, porque no se necesita conexión con el sistema central.
  • Cada working copy es un backup.
  • Experimental branches – crear y eliminar branches es rápido y simple.
  • Fomenta la colaboración entre desarrolladores, permitiendo por ejemplo compartir cambios sin necesidad de commitearlos en el servidor central.




DVCS: Conceptos principales

Cuando utilizamos herramientas de versionado distribuido, debemos adaptarnos a una nueva filosofía de trabajo, en la que se requiere dominar algunos conceptos claves:
  • CVCS está centrado en sincronizar cambios de ficheros en un servidor central, mientras que DVCS tiene una orientación hacia compartir los cambios; de forma que cada cambio tiene un identificador único.
  • En un sistema DVCS registrar/descargar cambios y aplicarlos se realizan en pasos diferentes, en cambio en un sistema CVCS ocurren todos a la vez.
  • Un sistema DVCS no fuerza a utilizar una estructura común para todos.
  • El concepto push indica enviar un cambio a otro repositorio y el concepto pull indica almacenar en nuestro repositorio un cambio producido en otro.
¿Que es Mercurial?

Ahora que ya conocemos las conceptos básicos de un sistema DVCS, comenzamos a adentrarnos en Mercurial. Mercurial es un proyecto Open Source con licencia GPL, que nació en Abril del 2005 y cuyo creador es Matt Mackall al cual podéis seguir en twitter con el nombre de mpmselenic.

En el momento de escribir este post, la versión que se puede descargar es la 1.6.3 y parece que está apunto de liberarse la versión 1.6.4, y tiene versiones para Windows, Linux y Mac OS.

Su nickname es hg, debido a que es la abreviatura del mercurio, por lo que sus comandos comienzan todos por hg.

Una de las grandes virtudes que tiene frente a otros DVCS tales como Git o bazar, es que la mayoría de sus comandos son muy sencillos, aquí os dejo los más habituales:


hg init                   (create repo here)
hg add list.txt           (start tracking file)
hg commit -m "Added file" (check fie into local repo)
hg log                    (see history; notice guid)

hg revert list.txt        (revert to previous version)
hg tag v1.0               (tag this version)
hg update -C v1.0         ("update" to the older tagged version; 
                           -C forces overwrite of local copy)

Una vez creado un repositorio de mercurial, este está formado por:
  • Working copy. Los ficheros que estás editando actualmente.
  • Repository. Un directorio denominado .hg que contiene todos los ficheros, parches, metadatos, etc...

Updates y Merge

Es necesario distinguir entre update y merge. Los cambios que podemos hacer sobre un repositorio/working copy podrían ser:
  • obtener un cambio en el repositorio, (pushing o pulling)
  • aplicar un cambio a uno o varios ficheros (update o merge)
  • guardar un cambio  (commit)
Dependiendo del tipo de cambio, este puede provocar unupdate o un merge:
  • Los updates ocurren cuando no hay ambigüedad. Por ejemplo, se ha realizado un pull sobre un fichero que sólo tu has modificado.
  • Los merges son necesarios cuando hay algún conflicto con los cambios que estamos intentado realizar.

Mercurial vs Subversion

Creo que todo el mundo conoce Subversion, una herramienta de control de versiones populares, desarrollado para reemplazar CVS. Riene una arquitectura centralizada cliente/servidor, en cambio Mercurial es un sistema descentralizado.
 
Subversión y Mercurial tienen comandos similares para realizar las operaciones clásicas. Ambas herramientas son portátiles a todos los sistemas operativos más populares.
 

Antes de la versión 1.5, Subversion no ofrecía soporte útil a "merges". En la versión 1.6, se ha ampliado y añadido nuevas capacidades para gestionar merges, aunque es conocido por ser complicado y lleno de errores. Mercurial por contra, es un sistema pensado para trabajar con merges de forma nativa.

Mercurial tiene una ventaja sustancial en cuanto a rendimiento sobre Subversion ya que la gran mayoría de operaciones se pueden hacer en modo desconectado. En cambio la gran mayoría de comandos de Subversion necesitan conexión con el servidor y esto puede provocar cuellos de botella y hacer bastante molesto las operaciones habituales.


Herramientas Mercurial
Mercurial ofrece una gran cantidad de herramientas para trabajar con sus repositorios, aquí están algunas de las más destacables:
Aquí tenéis la la lista completa.


Más información y fuentes utilizadas para este post.

SparkleShare: Crea tu propio DropBox

Hace unos días fui a parar al blog de frankgroeneveld.nl y una entrada me llamo la atención, "Dropbox on your own server", y como soy un usuario habitual de DropBox no pude contener mi curiosidad.

En esta entrada, se habla de un proyecto llamado sparkleshare.


En la web del proyecto, se define como:

SparkleShare is a syncing and collaboration tool that shines by its absence. it's designed to get out of your way, to make sharing documents and collaboration easier, and to make peers aware of what you are doing.

Para el intercambio de datos utiliza git, que todo apunta que será el sustituto de subversion como herramientas para el control distribuido de código fuente. Según he podido leer en la documentación, basta con disponer de una cuenta en github o gitorious

El proyecto aún se encuentra en fase beta y tendrá versiones para windows, mac y linux, y se basa en git para por lo que estaré atento para ver si puede sustituir/complementar a DropBox.
JK

Get Wacom Bamboo CTH-461/S Pen Working in Ubuntu 10.04

Desde unos años utilizo una tableta digital en sustitución del ratón por recomendación de mi osteopata para intentar mitigar unos problemas de hombro. A todos aquellos que padecéis este tipo de molestias, os recomiendo utilizarlas.

El modelo que compré fue Wacom Bamboo CTH-461/S, porque entre otras cosas Wacom es una de los pocos fabricantes que ofrece soporte para Linux para la gran mayoría de sus tabletas a través del proyecto linuxwacom.
Hasta ahora tenía un script para compilar el código fuente pero hoy acabo de encontrar una entrada en el blog de brettalton donde se explica como realizar el proceso a partir del repositorio PPA de Martin Owens.

El proceso es realmente simple, basta con ejecutar las siguientes instrucciones:

sudo add-apt-repository ppa:doctormo/wacom-plus
sudo apt-get update
sudo apt-get install wacom-dkms

Y a continuación reiniciar el sistema.

Solución : User is not in the sudoers file

Cuando un usuario se crea  en ubuntu, por defecto se le asignan a una serie de grupos que le permiten realizar ciertas tareas administrativas.

Uno de estos grupos es el admin. La pertenencia de un usuario a este grupo permite realizar ciertas tareas de administración y en particular utilizar el comando sudo, ya que en el fichero /etc/sudoers se suele tener esta configuración por defecto:
Defaults        env_reset
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root    ALL=(ALL) ALL

# Allow members of group sudo to execute any command after they have
# provided their password
# (Note that later entries override this, so you might need to move
# it further down)
%sudo ALL=(ALL) ALL
#
#includedir /etc/sudoers.d

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
El problema que sufrí hace unos días fué que por error eliminé al usuario con el que trabajo del grupo admin, y como podeis imaginaros una vez salvados los cambios tu usuario no puede realizar ninguna tarea de administración ni tampoco ejecutar el comando sudo por lo que no puedes volver a asignar a tu usuario al grupo admin :-(

Bien, para solucionarlo basta con seguri los siguiente pasos:
  • Reiniciar el sistema.
  • Entrar en modo recuperación y escojer la opción de entrar en modo root
  • Editar el fichero /etc/group y buscar el grupo admin
  • Una vez seleccionado agregar a vuestro usuario
Para evitar que os vuelva a pasar, también se puede agregar a vuestro usuario de trabajo normal al fichero /etc/sudoers.

Saludos,

JK

ScrumManager Certified

Después de asistir al curso de formación y de pasar la prueba de certificación final he obtenido el certificado de ScrumManager.


Scrum Manager Member



Para los que no sabeis de que va todo esto, Scrum es una metodología de desarrollo muy simple, pero que a su vez requiere de un gran esfuerzo, ya que no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto.

Como método ágil:
  • Es un modo de desarrollo adaptable, antes que predictivo.
  • Orientado a las personas, más que a los procesos.
  • Emplea el modelo de construcción incremental basado en iteraciones y revisiones
El componente raíz de Scrum es el sprint, y está formado:
  • Planificación del sprint

Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál va a ser el trabajo y los objetivos que se deben conseguir en la iteración.
  • Seguimiento del sprint

Breve revisión diaria, en la que cada miembro describe tres cuestiones:
  1. El trabajo que realizó el día anterior.
  2. El que tiene previsto realizar.
  3. Cosas que puede necesitar o impedimentos que deben suprimirse para realizar el trabajo.
Cada persona actualiza en la pila del sprint el tiempo pendiente de sus tareas, y con esta información se actualiza también el gráfico con el que el equipo monitoriza el avance del sprint (burn-down)
  • Revisión del sprint
  1. Análisis y revisión del incremento generado.
  2. Retrospectiva de lecciones aprendidas para mejorar la implementación de scrum en la organización.
Si estáis interesados en Scrum, aquí tenéis links que os pueden servir de ayuda:

El futuro de los JEE Web Frameworks, según Matt Raible

Hace algún tiempo que sigo las andaduras de Matt Raible uno de los gurus de los frameworks JEE y creador AppFuse.

El pasado 2 de junio tuvo lugar en Dublin la 2nd Annual Irish Software Show donde Matt realizó algunas presentaciones que tenéis a continuación.
Comparing Kick Ass Web Frameworks
View more presentations from Matt Raible.

Espero que os guste.

Juan C.

Certificado SCEA

Por fin, después de casi 1 año de preparación, me han comunicado oficialmente desde Sun (ahora ya Oracle) que por fin he obtenido la certificación de:

Para poder obtener esta certificación, tuve que realizar 3 partes:
Todos aquellos que estéis en este proceso os recomiendo revisar la información
que Oracle ha colgado en esta dirección.

A mi me sirvió de ayuda revisar los siguientes links:
Y leer el libro (Link a amazon):


Para la práctica utilicé Enterprise Architect, una buena herramienta para el modelado UML que me recomendó Emmerson Miranda, un compañero de in2 también certificado SCEA como podéis ver en esta entrada.

Durante la parte final tuve algunos problemas con el upload de la práctica, ya que han deshabilitado la opción de subirlos a la página antigua (que por cierto no tiene nada de web 2.0 ;-) ) y después de alguna semanas de correos me indicaron que tenía que enviarlos directamente por mail a Eric Boice eboice@esgroup.cc.

Saludos,
JK.

SOA, Spring-WS y contract-first

Spring-WS es un subproyecto de Spring basado en la construcción de Web Services bajo la filosofía "building contract-first". Esta filosfía de crear servicios no es muy popular y la mayoría de desarrolladores prefieren  crear el contrato del servicio al final, lo que implica que hasta que no se despliegue el servicio no se conoce su contrato. 
Esta técnica, que puede ser utilizada para crear Web Services de forma rápida acarrea algunos inconvenientes:

  • WSDL y XSD resultantes complejas de manipular.
  • El contrato resultante, acaba reflejando detalles de implementación internos al servicio, y al aparecer en el contrato, provocan que cambios en la implementación se reflejen en el contrato.
  • Relacionado con el punto anterior, se debe tener especial atención a la hora de realizar refactorizaciones de código, ya que estas también pueden ocasionar cambios en el contrato.
En resumen, es recomendable utilizar una estrategia de contract-first a la hora de desarrollar nuestros servicios y definir el contrato en "términos de negocio" y hacer hincapié en lo que se espera del servicio y no en cómo se implementará.
En este artículo podéis encontrar el detalle sobre como implementar un Web Service mediante Spring-WS.
Saludos,
Juan C.