JavaFX alcanzo los 100 millones de descargas

Continuando con las noticias, ésta vez relacionadas a Java, el CEO de Sun Jonathan Schwartz anunció que JavaFX ha llegado a los 100 millones de descargas. En su blog alaba las características de éste recién nacido lenguaje multiplataformas y augura un futuro muy prometedor.

Jonathan Schwartz fue la persona de Sun que más ha promocionado Java y colaborado para liberar la plataforma completamente, convirtiendo a la compañía en un icono más del Open Source.

¿Que opinas de JavaFX?

Links:

1. Fuente de la noticia
2. JavaFX site
   

Encuesta: ¿Que S.O. prefieres para desarrollar en Java?

Finalizada la encuesta, podemos observar que de un total de 26 votos gana Linux con 13 votos, siendo Ubuntu la distro preferida. Le sigue Windows con 11 y bueno... Solaris y MacOs con un solo voto.

Si bien la muestra de 26 votos es muy chica, me alcanza para confirmar lo siguiente:

Con las facilidades de usabilidad que alcanzaron al día de hoy las distribuciones Linux como Ubuntu, los desarrolladores Java que desean ser productivos y no liarse con asuntos exclusivamentes del sistema operativo ya no lo ven de forma negativa. Más aún están comenzando a notar ventajas sobre Windows en cuando a estabilidad, seguridad y usabilidad.

Desde que migre mi ambiente de desarrollo desde Windows a Ubuntu no me canso de recomendar y enumerar las ventajas que vengo obteniendo.

Personalmente opino que muchos de los que aún siguen prefiriendo Windows a Linux, toman su desición debido a prejuicios basados en conceptos fantasmas y relacionados a la falsa creencia de la dificultad de configuración y usabilidad. En fin, quiero recomendar a todos ellos que prueben el live-cd de ubuntu y despues me cuentan.

Escucho sus opiniones.

Exprimiendo a Hudson - Parte 3 (Creando un Job)

Por fin vamos a crear nuestro primer job. En ésta ocasión vamos a suponer que contamos en nuestra Software Factory con un proyecto Java que se construye (compila, distribuye, genera javadoc, etc) desde un script ant. Si usamos un IDE como NetBeans este script es generado automáticamente segun las propiedades del proyecto, no es la finalidad de este tutorial explicar como modificar estos script desde Netbeans, solo comentar que podemos modificar/agregar task ant facilmente sin tocar lo generado por el ide en el archivo build.xml del directorio raiz del proyecto. Aquí un pequeño tutorial que explica como hacer esto.

Retornando a Hudson, podemos definir un Job como una tarea con acciones y triggers a realizar sobre un proyecto de software. Normalmente tendremos definido un job por cada proyecto que tengamos que integrar, pero no hay un límite sobre la cantidad de jobs que podamos definir sobre un proyecto particular, todo depende de las acciones que quisieramos ejecutar en el job.

Para crear un job nuevo hacemos click sobre New Job. Como dijimos que la construcción del proyecto esta basada en un script ant, entonces de las distintas posibilidad que disponemos, seleccionamos la opción Build a free-style software project y dejamos la opción de maven2 para otra ocación. Ya que estamos aquí, Copy existing job será muy útil para copiar una configuración de un job ya existente al job nuevo ( que deducción! XD ) y ahorrarnos trabajo repetitivo. Le asignamos un nombre al job y le damos al ok.

La configuración del job se divide en 5 secciones donde Hudson nos pide lo siguiente:

1. Dame información básica.
2. ¿De donde obtengo el proyecto?
3. ¿En que momento construyo el proyecto?
4. Dame una herramienta para la construya.
5. ¿Que quieres que haga después de construir el proyecto?

Vamos a repasar cada una de las secciones:

Si nos concentramos en la sección superior, observamos que podemos llenar un campo de comentario con una descripción de la finalidad del job. Tambien existe un checkbox para indicar si queremos que los builds antiguos se vayan descartando, podemos definir esto por cantidad de días y/o por cantidad de builds. Esta última opción es la que siempre uso, manteniendo los últimos 10 builds. También disponemos de otro checkbox que deshabilita la ejecucion del job.

En la próxima sección Source Code Management, básicamente debemos elegir el sistema gestor de código fuente que posee nuestro repositorio de proyectos y definir la conexión al servidor. En principio solamente veremos las opciones CVS y Subversion ya que Hudson por defecto trae instalado y listo para usar plugins para conexión a estos dos servidores. Aunque además disponemos de plugins para Mercurial entre otros.

En la sección Build Triggers debemos definir el momento en que Hudson realizará el build. Por defecto existen tres formas distintas de realizar hasta acción (cuatro si incluimos el build now manual).
Una de las posibilidades es definir que se haga luego de finalizar otros build de proyectos, indicando el nombre de estos. Esto es muy útil si estamos definiendo un job para correr una completa bateria de tests pero siempre despues de que otro job complete la construcción de todo el proyecto. La segunda forma es encuestar el repositorio definido en la sección anterior cada cierto intervalo de tiempo, si se detectan cambios, se realizará el build. Por último se puede indicar que el build se haga periodicamente.
Para las últimas dos opciones la forma de indicar el tiempo es mediante cinco valores separados por espacios, siendo estos valores en orden: minuto, hora, dia del mes, mes, dia de la semana. Podemos usar el caracter comodín * para indicar "todos". Por ejemplo si queremos realizar builds nocturnos pasada media hora de la media noche todos los dias del mes, los valores a llenar en el campo Schedule podrían ser 29 23 * * * (los valores para minutos y dias, etc comienzan de 0).

Continuando con la próxima sección build, es aquí donde definimos la herramienta de construcción, en nuestro caso Ant. Especificando el target que queremos que corra o dejando el campo vacío para que corra el target por defecto. Además tenemos la potencia de ejecutar ordenes de un shell script o de batch script de Windows. Por ejemplo, podríamos invocar por shell script a la orden make makefile para construir un proyecto c/c+.

En la última sección podemos pedirle a Hudson que realize varias acciones luego de que finalize el build. Como muestra la imagen es posible retener artefactos indicando cuales son. Como por ejemplo archivos .exe .war . jar .zip o lo que fuese resultado del build. Además podemos hacer que se publique el javadoc (obviamente si es un proyecto Java) indicandole también donde se encuentra. Si lo deseamos, Hudson nos generará un reporte con el resultado de los test JUnit. Todas estas últimas acciones estan basadas en resultados ya generados en la etapa de build, en nuestro ejemplo con el script ant. Otra acción pos-build sencilla de activar es la de notificación por e-mail. Para esta sección disponemos de varios plugins extras sobre todo para reportes.

Con lo visto hasta aquí ya podemos hacer uso de Hudson de forma básica. En el próximo post comenzaremos a exprimir a Hudson. Ya saben... espero sus comentarios.

Exprimiendo a Hudson - Parte 2 (Administración)

De retorno de mis vacaciones donde procure no interactuar con ningun tipo de tecnología más que la de una piedra/martillo para poder clavar las estacas de una carpa, intentare continuar con Hudson.

Ya hice publicidad de las bondades de Hudson a la hora de administrar y configurar el servidor, asi que este post será muy sencillo. Como si no fuera suficientemente fácil, veremos que la UI de Hudson nos proporciona ayuda continuamente.

Vemos que en la pantalla de administración entre otras operaciones se nos permite configurar el servidor y manejar los plugins de extenciones. Veamos como configurar el servidor:

Hudson permite la ejecución concurrente de builds. Se denomina "executor" a un hilo del servidor que puede realizar builds. Por eso se nos recomienda llenar el campo # of executors con la cantidad de procesadores que cuenta el equipo donde se esta corriendo Hudson.

Tenemos la posibilidad de marcar un checkbox para habilitar la seguridad. Esto permitira configurar o correr un nuevo build sólo a los que se logueen con un usuario con rol "admin". Si Hudson esta desplegado sobre Tomcat, los usuarios y roles estan definidos en el archivo $TOMCAT_HOME/conf/tomcat-users.xml . Podemos ver como editar éste archivo en la parte 1 de este tutorial.

Además de la concurrencia, tenemos la posibilidad de definir agentes "esclavos" del master. Esto nos permitira la ejecución de los builds de forma distribuida.

Cuando un esclavo se registra al master, el master comienza la distribución de las cargas a los esclavos. La carga será balanceada dependiendo de la configuración particular de cada Job. Algunos proyectos pueden optar a "pegarse" a una máquina en particular para hacer el build, mientras que otros podrán optar por balancear su carga libremente entre los esclavos definidos. En algún futuro post publicaré como configurar Hudson para realizar builds de forma distribuida, por ahora, aqui un tutorial para ir aprendendiendo esta técnica.

Tambien podemos definir los path y conexiones a distintas herramientas que Hudson eventualmente pueda utilizar. Los campos a llenar son las instalaciones del JDK, Ant, Maven, y definir las conexiones a un servidor CVS y a un servidor SMTP para notificaciones por e-mail.

Obviamente si usamos Subversion como repositorio de código fuente, no llenaremos los campos de CVS. De forma similar, si no nos gusta Maven y solo usamos Ant para programar nuestros script de builds, no es necesario definir una instalación de Maven.

Como vemos completar una configuración estándar del servidor es totalmente visual y sencilla.

Para la próxima aprenderemos a crear Jobs para realizar buids de proyectos. A no desesperar, el tunning avanzado para exprimir Hudson vendrá más adelante, cuando ya dominemos "de taquito una integración continua base con Hudson.

Exprimiendo a Hudson - Parte 1 (Instalación)

Hudson es un CI Server o servidor de integración continua open source. Existen varios productos similares tales como Cruise Control o Continuum de Apache.
Lo que diferencia a Hudson del resto es su potencia mediante la extension por plugins y su facilidad de instalación, configuración y mantenimiento.

En esta primera entrega de una serie voy a explicar como desplegar Hudson en un Servidor Tomcat instalado en Ubuntu Intrepid Ibex, de todas formas en cualquier otra distro de Linux u otro S.O esto no debería ser muy diferente. En las próximas entradas veremos como integrar varias herramientas con los plugins de hudson para reporte de test, cobertura y análisis de código estático para métricas de QA.

Instalación:

• Paso 1: Descargamos hudson.war desde el sitio oficial o desde este link. Podemos probar hudson iniciándolo con el servidor embebido que trae simplemente con la orden java -jar hudson.war
  
• Paso 2: Para poder hacer uso de Hudson de forma profesional necesitamos desplegar el war en un contenedor de servlets/jsp como Tomcat. Necesitamos descargar los paquetes tomcat6 y tomcat6-admin. Esto podemos hacerlo desde el gestor de paquetes Synaptic o escribiendo en una terminal:
  

sudo apt-get install tomcat6 tomcat6-admin

• Paso 3: Probamos si tomcat esta funcionando escribiendo en un browser: http://localhost:8080 . Si todo anda bien deberemos crear un usuario administrador con un rol. Para eso editamos el archivo tomcat-users.xml y luego reiniciamos el servidor:

sudo nano /var/lib/tomcat6/conf/tomcat-users.xml

<!--
<role rolename="tomcat"/>
<role rolename="role1"/>
<user username="tomcat" password="tomcat" roles="tomcat"/>
<user username="both" password="tomcat" roles="tomcat,role1"/>
<user username="role1" password="tomcat" roles="role1"/>
-->
<role rolename="manager"/>
<role rolename="admin"/>
<user username="user" password="secreto" roles="manager"/>
<user username="hudson-admin" password="secreto" roles="admin"/>
</tomcat-users>

• Paso 4: Abrimos el administrador de Tomcat, aquí nos pedira el usuario y contraseña que recien agregamos en tomcat-users.xml. Para esto escribimos la siguiente direccion en el browser: http://localhost:8080/manager/html. En la sección apropiada agregamos el archivo hudson.war para poder desplegarlo en el contenedor.

• Paso 5: Creamos el directorio de trabajo de Hudson y le otorgamos permisos:

sudo mkdir /home/hudson
sudo chmod 777 /home/hudson

• Paso 6: En el archivo /etc/init.d/tomcat6 agregamos a la variable JAVA_OPTS la variable -DHUDSON_HOME con el valor del directorio de trabajo de hudson que definimos en el paso 5.
  

sudo gedit /etc/init.d/tomcat6

JAVA_OPTS="$JAVA_OPTS -Djava.endorsed.dirs=$CATALINA_HOME/endorsed -Dcatalina.base=$CATALINA_BASE -Dcatalina.home=$CATALINA_HOME -Djava.io.tmpdir=$CATALINA_BASE/temp -DHUDSON_HOME=/home/hudson"

Bueno...ahora el ultimo paso es probar si hudson esta andando escribiendo en el browser la dirección: http://localhost:8080/hudson

Espero que les sirva y ante algún problemita ya saben, escribanme preguntando que por ahí a mi ya me paso. Hasta la próxima entrega.

Subversion en Linux

Para poder mantener controladas las versiones de los proyectos que estamos desarrollando existen los servidores de control de versiones. Uno de los mas populares es Subversion o svn.

Voy a explicar paso a paso como consumi un par de horas de mis vacaciones para instalar svn en mi Ubuntu 8.10. Abrimos una terminal y...

• Instalamos los paquetes de subversion:

sudo apt-get install subversion subversion-tools


• Si queremos "browsear" el repositorio necesitamos tener instalado y configurado un servidor Apache con el modulo dav y dav_svn, si no lo tenemos:

sudo apt-get install apache2 libapache_svn

• Para poder otorgar permisos creamos un grupo llamado subversion:

sudo groupadd subversion

• Agregamos un usuario:

sudo usermod -Gsubversion nombreusuario

• Creamos un archivo con el usuario, luego nos pedira una contraseña
  

sudo htpasswd -c /etc/apache2/dav_svn.passwd nombreusuario

• Creamos un directorio, indicamos el repositorio, y otorgamos permisos de grupo y de escritura:

sudo mkdir /home/svn/
sudo svnadmin create /home/svn/
sudo chown -R www-data:subversion /home/svn/
sudo chmod -R 770 /home/svn/

• Editamos el archivo de configuración de Apache para svn:

sudo nano /etc/apache2/mods-available/dav_svn.conf

##
# SVN
#

DAV svn
SVNPath /home/svn
AuthType Basic
AuthName “Repositorio Subversion del proyecto”
AuthUserFile /etc/apache2/dav_svn.passwd

Require valid-user

• Ahora solo nos queda reiniciar al sevidor Apache y verificar en un browser la dirección http://localhost/svn

sudo /etc/init.d/apache2 restart

Espero que este mini-tutorial les sea útil. Cualquier duda escriban comentarios.

Chatbots

Continuando con la linea de IA retro me puse a investigar sobre la vida y logros de Joseph Weizenbaum, considerado el padre de la cibernetica. En 1966 Joseph Weizenbaum creo en el MIT un programita simple que lo llamo ELIZA, este programa intentaba mantener una conversación de texto coherente con un usuario. El usuario realizaba preguntas y ELIZA en rol de psicologa contestaba.

Luego ELIZA fue repudiado por su autor aclarando que sólo se trataba de una simulación de IA.

Pasemos al diván de ELIZA con este applet y dejemos que ella nos analize:

Eliza: Hi. I'm Eliza. Tell me your problems!
You : I am afraid
Eliza: How long are you afraid?
You : since last year
Eliza: Perhaps you would like to talk about a problem?
You : are you stupid?
Eliza: Why are you so interested wether I am stupid or not?
You : you are mother fucker
Eliza: Why do you think that I am mother fucker?
You : Fuck you!
Eliza: What does this mean for you, saying " Fuck me "?

El paciente se enojo por la corriente rogeriana de ELIZA :D y la mando a lavar los platos. Más alla de las palabras agresivas del paciente, podemos ver que cuando ELIZA encuentra una palabra en su diccionario responde con una pregunta preparada para esa palabra, como por ejemplo la tupla (afraid, How long are you afraid?). Cuando no encuentra alguna palabra clave, sólo responde con una pregunta lo suficientemente ambigua (a veces irritante) como para esconder su desconocimiento, concatenando además la frase del paciente.

Si te gusta Python aquí tienes otra implementación de ELIZA en éste lenguaje.

Aunque ELIZA no posee IA, dio inicio a una revolución en este campo. Les dejo algunos chatbots más modernos para que se diviertan un rato, algunos de ellos preparados para intentar pasar el Test de Turing:

• Alice by Dr. Richard Wallace
• MotBot
• Athena
• Bildgesmythe