Sep 30

Puzzle inverso

Normalmente, en un puzzle, tienes las piezas y "sólo" hay que encajarlas. Sin embargo, estos días he estado codificando un poco (¡¡ pof fin!!) y estoy haciendo en el proyecto una pequeña funcionalidad. El proyecto usa Spring Framework e iBatis. Y el puzzle es "inverso".

Resulta que Spring ya tiene cosas hechas, con iBatis hay cosas que se hacen solas, y con algunas de las librerías que tenemos también. Sólo hay que implementar determinadas interfaces y pasárselas a todo esto. Y eso es lo curioso de este puzzle, esas implementaciones son las piezas que faltan, tienen sus huecos asignados y sólo tienes que hacerte las piezas.

Me explico. Un fichero xml para iBatis con las consultas. Una implementación de DAO que llame a iBatis. Unas clases para convertir los datos devueltos por iBatis a datos propios de la aplicación. Una configuración para el DataSource, etc, etc, etc. Y milagrosamente, tras hacer trozos sueltos de código aquí y allí y meterlo todo en su sitio… ¡¡ funciona !!.

La verdad es que si estás acostumbrado a esas herramientas, se hace todo en un "pis-pas" y con cierta garantía de que funcionará. La pega es que el programar se hace un pelín más aburrido, ya que hay poco que pensar y sólo tienes que hacer clases mecánicas con poco o nada de código interesante.

Cambiando de tema, ¿por qué estoy codificando ahora?. Muy sencillo. Después de que me dieran una especificación adecuada ("no sé qué quiero, pero debe estar para mañana"), yo he hecho un diseño adecuado a esa especificación ("vete haciendo, que luego ya hablaremos") y los codificadores han hecho un código según el diseño

public class ElProyecto {
   public static void main (String [] args) {
      // To be defined.
   }
}

Hoy ya es mañana, así que toca que todos como locos quitemos el "to be defined": y rellenemos el código de dentro.

Sep 19

Regla del único punto de salida

Estoy leyendo un manual de estilo de programación, de Planetalia. Muchas (casi todas) las cosas que ahí se ponen más o menos las conozco y las aplico, porque son las consabidas reglas para hacer código claro, mantenible, etc. Sin embargo, está bien releerse estos manuales (y este es fácil por estar en español) porque siempre hay alguna cosa que aprendes o te llama la atención.

Y comento aquí una que me la ha llamado especialmente, la "regla del único punto de salida". Esta regla consiste en que si una función debe devolver un valor, sólo puede haber un return al final de la función. Esto implica que debemos crear una variable local para almacenar el resultado, hacer todo el código para guardar ese resultado en la variable local y luego devolver la variable local.

Yo muchas veces la he intentado aplicar, pero en muchas ocasiones me complica el código demasiado (especialmente si hay bucles y condicionales que hacen terminar el bucle prematuramente), así que a veces me la salto y pongo el return directamente en cuanto obtengo el resultado.

Pues bien, lo que me ha llamado la atención de este manual es que dice que dicha regla tenía su sentido hace tiempo, pero que con los actuales medios y lenguajes de programación, se ha quedado totalmente obsoleta y que en ocasiones, como a mi me pasaba, complica demasiado el código dejándolo menos claro. Por ello, dice el manual, nos la podemos saltar a la torera siempre que queramos.

¿En qué casos tiene sentido?

Antes no había los depuradores que hay ahora, por lo que la depuración consitía en poner "print" del resultado antes de devolverlo. Obviamente esto es más sencillo si sólo hay un return en la función que si hay varios repartidos por el código de la función. Con los depuradores actuales, no tiene sentido. Sólo los muy novatos (o en casos muy raros) depuran el código a base de poner "print".

Otro caso que tiene sentido es cuando debemos liberar recursos antes de volver de la función (hacer free() en C, cerrar ficheros, etc). Sin embargo, si el lenguaje lo permite (como java), esto tampoco tiene demasiado sentido, ya que siempre podemos poner un "finally" en la función para el cierre de todo lo que haya que cerrar.

Esto me recuerda al tema de los monos y el agua helada, en el que se crea una "regla" que tiene sentido en un momento dado y con el tiempo, se sigue esa regla a ciegas sin saber por qué, incluso aunque haya dejado de tener sentido hace tiempo.

Puedes ver una discusión sobre la regla del "único punto de salida" (en inglés), en http://forums.sun.com/thread.jspa?threadID=5194210

 

Sep 18

Hudson

 Este comentario de Blaxter me ha llevado a probar las herramientas que él indica para integración continua, en lugar de CruiseControl o Continuum.

La primera herramienta, bitten, la descarté sin probarla, porque parece que es como un plugin para Trac, que de momento no puedo usar, aunque quiero, porque no soporta CVS. Tampoco me fijé demasiado si se puede arrancar suelta, pero me hace la impresión de que sí.

Así que me fuí con la segunda, Hudson.

Una maravilla de herramienta.

La instalación muy sencilla. Se baja uno un .war y ejecuta java -jar hudson.war. Abres el navegador y ya tienes lista la página de hudson, preparada para configurar y añadir proyectos.

La configuración sencilla y toda a vía web. Todavía no he tenido que tocar ningún fichero externo, salvo la variable HUDSON_HOME antes de arrancar, para decirle a Hudson dónde debe situar todo.

Los proyectos se añaden fácil, copiando unos de otros, indicando el repositorio CVS, subversion o lo que sea, si es de maven, de ant, etc.

Sin embargo, lo que más me ha gustado de todo, es que es "inteligente". Trabajando con varios proyectos maven es capaz de ver las dependencias entre proyectos y automáticamente, si un proyecto necesita compilarse, después compila todos los que dependen de él. Y al revés, para mirar si un proyecto necesita compilarse, mira también automáticamente si necesitan compilarse los proyectos de los que depende.

Dicho de otra forma, si tengo un proyecto LIBRERIA y otro proyecto PROYECTO que usa librería, si meto algo en CVS de LIBERIA, me compial LIBRERIA y automáticamente después compila PROYECTO. Y al revés, cuando mira a ver si hay algún cambio de CVS en PROYECTO para ver si necesita compilarlo, mira automáticamente también los posibles cambios en CVS de LIBRERIA.

Esto tiene la ventaja de que garantiza que todos los proyectos están siempre actualizados y compilados con las últimas librerías disponibles de las que dependen y que si se toca una librería, se detecta rápido si eso estropea el compilado de un proyecto.

Sin embargo tiene una "pega" o efecto curioso. Basta tocar un fuente en una librería para que Hudson se ponga a compilar como loco unos proyectos y otros, y los compilados de unos provoquen a su vez los compilados de otros. Por un simpel fuente tocado, puede pasarse un par de horas compilando todas las dependencias y las dependencias de las dependencias (cosa, por otro lado, lógica).

En cuanto al resto, también estupendo. Todo lo que se te ocurre configurar, esta configurable via web (el servidor de email, cuantos logs quieres que guarde, comando para construir los proyectos si no es el de defecto, los path de java, ant, maven, sh, etc, etc, etc. También puedes configurar cuántos hilos de compilado paralelos quieres, de forma que pueden compilar hasta n proyectos simultáneos, eligiendo tú el valor de n.

Me queda pendiente probar bitten, pero de momento Hudson lleva todas las papeletas de quedarse como herramienta.

 

Sep 16

Continuum vs CruiseControl

 Hace tiempo me decidí a instalar en el trabajo una de estas herramientas de integración continua, de esas que todas las noches compilan los proyectos desde cero y mandan correos a los desarrolladores y jefes sobre el éxito o fracaso de esa compilación.

En su momento evalué estas dos: CruiseControl y Continuum. Primero intenté con Continuum, porque parecía ser la más usada junto con Maven, pero me encontré con una pega en ese momento que me requería mucho trabajo para resolverla. Resulta que una vez instalado y todo a través de una interface web, le indicas a Continuum el fichero pom.xml de tu proyecto y él se encarga. La pega gorda, que me hizo desecharlo, es que en proyectos maven que tienen a su vez subproyectos debajo, Continuum obligaba a que el directorio del subproyecto se llamara igual que el artifactId de maven, cosa que en mi caso no era así. A mi me gusta poner los nombres de directorios en mayúsculas y con _ entre palabras, mientras que el artifactId coincide con el nombre del jar, y me gusta más en minúsculas y sin _. Total, que Continuum no me cogía mis proyectos maven complejos compuestos de subproyectos y no me apetecía ponerme a cambiar nombres de directorios o de jars.

La segunda pega de Continuum es que requiere que en el pom.xml esté la información para el sistema de control de versiones (CVS, Subversion, con usuario, nombre de repositorio y proyecto…. y password). Estupendo si es uno solo, pero si hay varios desarrolladores, ¿de quién ponemos ahí la información?. Por supuesto, habría que crear un usuario "anonimo" con acceso de sólo lectura al sistema de control de versiones. Cosa compleja si el servidor es de CVS y además corporativo. Nada menos que una petición al departamente de informática y un "agujero" de seguridad dejando un acceso público a nuestros "super secretos fuentes" (es un decir).

Así que me puse a probar con CruiseControl. Este fue bastante mejor. No tiene casi ningún tipo de configuración a través de interface web, por lo que todo se configura a mano. Tú te haces el checkout, le dices a CruiseControl en un fichero xml dónde están los fuentes, cada cuánto tiene que compilarlos, a quién tiene que enviar correos y listo. La interface web es además mucho más sencilla, un listado de proyectos con un botón de "build" al lado y un enlace para ver los resultados del compilado y poder bajarse los jar.

Así estuvimos funcionando unos años, pero CruiseControl fue presentando sus pegas. El fichero xml de configuración con los proyectos empezó a crecer y crecer, hasta hacerse una pesadilla cualquier modificación (había que tocar en muchos proyectos). Y encima, el botón de "build" le funciona a unos sí y a otros no, con unos navegadores sí y con otros no, y sin una regla fija. A unos les funciona con Internet explores, a otros con firefox, a otros con ninguno. Y otra pega más, a veces, si el código de los test automáticos de JUnit se queda colgado por el motivo que sea, deja colgadas todas las tareas siguientes de compilación de otros proyectos en CruiseControl. No queda más remedio que "matarlo" y volverlo a arrancar.

El otro día decimos bajar y probar una nueva versión de Continuum. Esta vez sí funcionó el importar los pom.xml, puesto que ya admite nombres de directorios y artifactId distintos. La configuración a través de web de todo el sistema es sencilla, aunque si no hace lo que tú quieres, no se puede hacer. Sigue habiendo cosas ocultas en ficheros de configuración ocultos, como la configuración del servidor de correo para que Continuum pueda enviar correos. Y sigue habiendo cosas que no sé si me gustan, como la necesidad del usuario anónimo en CVS y que en el pom.xml deben estar todos los nombres de desarrolladores y correos que intervengan en el proyecto (cosa lógica por un lado, pero que no deja de ser un rollo ponerlo y tenerlo actualizado). En este sentido, CruiseControl usaba el nombre de usuario del commit de cvs para enviarle el correo, o bien hacer un mapeo de ese nombre con una dirección de correo si no coincide.

Pero bueno, ahí tenemos un Continuum instalado y funcionando, hasta ahora bien, y después de un par de meses de prueba quizás (seguro) que nos cargamos el CruiseControl.

Sep 13

bitnami

 El otro día, mirando javahispano, descubrí una página bastante interesante: bitnami. En ella hay "stacks" que no son más que instaladores fáciles de programas opensource que no sólo instalan el programa en cuestión, sino que además instalan todo lo que necesita.

Por ejemplo, hay uno para wordpress que instala además apache, php y mysql. También está el de trac, que instala el perl y todo lo demás que necesita.

La de horas que me habría ahorrado instalando ciertos programas de haber descubierto esta página antes.

Por cierto, para encontrar los "stacks"  en la página anterior, cuesta un poco. Hay que pinchar en el dibujo de arriba. Cada muñeco es uno de los programas, pero si pinchas en la pizarra, vas a la página donde están todos los que hay.

Sep 07

Jugando con el móvil y J2ME

Este verano me han regalado un móvil. No es que me hagan especial ilusión, de hecho el que tenía  lo usaba como hucha y me explico: es de tarjeta prepago, cada seis meses le echo dinero para que no caduque, pero habitualmente dejo el móvil apagado y en casa, por lo que el saldo se va incrementando, como una hucha.

Sin embargo, el móvil que me han regalado sí tiene una cosa que me ha hecho ilusión: Java.

Así que me he decidido a hacer un primer "Hola Mundo" para el móvil y así enterarme de qué va todo esto de J2ME.

Primero a la página de sun, a bajarme el J2ME. Ya empezamos con cosas raras (para el que no tiene ni idea, como yo). Lo que hay que bajar es el "Sun java wireless Toolkit 2.5.2 for CLDC". Bueno, yo esperaba algo así como un JDK o un JRE y no un nombrecito tan extraño. Urgando un poco en google vi que era eso lo que había que bajarse para hacer programitas para el móvil.

La instalación es sencilla. Primero te pide el directorio de tu SDK de J2SE (tienes que tenerlo instalado previamente) para añadirle la parte de J2ME. Luego te pregunta por un directorio donde instalar el Wireless Toolkit. Ahí mete un pequeño entorno de desarrollo y un par (cuatro) emuladores de móviles estándar, para poder hacer pruebas antes de meter el código en el móvil.

Luego, como soy muy bruto, pensé en hacer el programa a pelo, es decir, con el gvim y compilando en línea de comandos. Es la mejor forma de enterarse qué estás haciendo. Sin embargo, mirando tutoriales, no encontré nada que me convenciera, además, soy un "caga-prisas" incapaz de pasarme dos días buscando y leyendo manuales antes de ponerme a codificar. Así que me decidí por Eclipse y su plugin para J2ME, el EclipseME, que por lo que he visto en google, debe ser el más aceptado.

Una vez instalado el plugin, se le da a nuevo proyecto J2ME y te crea un proyecto para J2ME con todos las dependencias ya puestas y un ficherito jda por defecto. Ese ficherito jda por lo visto en algo parecido al fichero de manifiesto de java estándar, pero para móviles y es obligatorio tenerlo. Ahí se indica el nombre de la aplicación, el icono que tiene que tener y la clase principal de la aplicación (la del main(), pero que aquí no tiene main(), sino que hereda de MIDlet, al igual que los applets no tienen main y heredan de Applet).

Luego, mirando por google y copiando trozillos de código de un lado y otro, hice el "Hola Mundo". Un programita que saca en la pantalla del móvil el texto "Hola Mundo". Ahora queda arrancarlo en eclipse a ver si funciona.

Hay que configurar el plugin EclipseME indicándole dónde están los emuladores de móviles. Para ello se le indica el directorio del Wireless Toolkit de Sun, donde están esos cuatro emuladores que comenté antes, y el plugin los busca y encuentra. Una vez hecho esto y elegido qué emulador quieres (el de móvil estándar con pantalla en color en mi caso), ya se puede ejecutar el programa.

Sale una ventana con el dibujo de un móvil en la pantalla. Allí se ejecuta el programa que hemos hecho y vemos en la pantalla del móvil el "Hola Mundo". Con el ratón podemos pulsar las teclas del móvil.

Ahora sólo me queda lo más importante, generar el .jar y meterlo en el móvil de verdad, a ver si funciona. La pega es que de momento no tengo ni bluetooth, ni cable de datos, así que hasta que vaya de compras no veré el resultado final.

Sep 04

Probando Google Chrome

Bueno, pues me he bajado para probar el navegador de google Chrome.

En apariencia, como casi todo lo de google, parece muy espartano, con pocos botones, menús, bordes, etc. Sin embargo, parece que me he acostumbrado rápido a él. Se abre muy rápido y la navegación es lo normal.

Tiene algunas cosas nuevas que no son normales en otros navegadores, así que supongo que es cuestión de gustos el que te vayan esas cosas nuevas o no. Ahí van algunas que me han llamado la atención:

Por un lado, la página de inicio por defecto es una página de nuestros sitios web favoritos. Eso sí, por favoritos se entiende automáticamente los que más visitamos escribiendo directamente la URL en la barra de navegación. Aparte podemos ver ahí los marcadores y el historial completo de navegación.

Otra cosa que me llama la atención es que no hay caja de búsqueda en google por ningún lado, pero sí la hay. Es la misma caja donde escribimos las URL. Si escribimos una URL, el navegador va a dicha URL, si escribimos palabras, se hace la búsqueda, por supuesto, en google. También por supuesto podemos decir que queremos buscar en google la URL sin visitarla.

Más cosas, al instalar google Chrome importa, al menos en mi caso, los favoritos, passwords y demás de firefox. He tenido que volver a entrar en sesión en los foros y páginas que visito habitualmente, pero al menos no he tenido que meter y recordar las passwords.

Tienen también un botoncito para "añadir  aplicaciones al escritorio". No sé muy bien qué es eso, pero aparentemente, si visito por ejemplo gmail y añado este gmail como aplicación al escritorio, dando doble click en dicho icono se me abre el navegador chrome en la página de gmail. No sé muy bien en qué se diferencia de poner un enlace a una URL directamente en el escritorio, pero por lo que he oido es la base para las aplicaciones remotas que pretende montar google. Me explico, en vez de tener en el escritor iconos de word, excel, outlook, etc, tendrías iconos de gmail, google docs, etc. ¿Que quieres un documento de word?, le das al google docs y ya tienes una aplicación (el navegador) para escribir docs.

Otra cosa que me ha llamado la atención es que no he tenido que bajar plugins de flash, pero no funcionan los applets y no hay forma de bajarse ningún plugin. En Taringa he visto una posible solución a los applets, pero es poco menos que extraña o cosa de meigas.

Y una cosa que no me ha gustado. Aunque parezca increible, de momento no hay google toolbar para google chrome. De hecho, la página de google toolbar cree que estás usando un navegador firefox de versión menor a 2.0.

En fin, voy a seguir usándolo una temporada a ver qué pasa. Por cierto, en el trabajo no me lo puedo instalar porque lo que te descargas es un instalador web y al ejecutarlo parece que no es capaz de pasar el proxy/firewall corporativo o lo que sea.