Bits y Bytes

Botones no funcionan en Eclipse Galileo tras actualizar a Ubuntu 9.10

Iván Párraga García — Mon, 02 Nov 2009 10:18:06 +0000

El viernes pasado antes de irme para casa dejé el Ubuntu 9.04 del trabajo actualizando a la recién estrenada y flamante versión 9.10. Al llegar esta mañana a la oficina acabé el proceso de instalación (no, Synaptic, no me borres mi configuración del MySQL, bueno Synaptic te dejo que me cambies la versión del Firefox, etc, descarga kernel, compila y rebota) e iba a ponerme manos a la obra con la nueva iteración recién estrenada, cuando al ir a configurar un nuevo proyecto Java para la nueva branch del repositorio, los botones de mi Eclipse Galileo se manifestaron en huelga.

Los botones están ahí, pero no funcionan, es decir al hacer click sobre ellos la acción asociada no se ejecuta. Yo tengo el Eclipse instalado descargándolo directamente de su web y no de los paquetes de la distribución. Los compañeros que están usando el Eclipse de la distribución no han experimentado problemas.

Googleando un poco he encontrado rápidamente la solución en este post. Aparentemente es un bug de Eclipse en la biblioteca de gestión de ventanas GTK que será resuelto en próximas versiones. Por el momento tenemos un workaround para seguir trabajando con la versión actual arrancando Eclipse mediante el siguiente scrtipt:

#!/bin/sh
export GDK_NATIVE_WINDOWS=1
/PATH_AL_ECLIPSE/eclipse

Tagged: Eclipse, Ubuntu

Configurar log4j para JUnit

Iván Párraga García — Mon, 25 May 2009 12:44:23 +0000

Es muy habitual que a la hora de programar nuestras aplicaciones utilicemos algún tipo de librería de log. Tradicionalmente hay dos familias log4j (la pionera) y la nativa de Java (java.util.logging) que vino un poco después “inspirándose” bastante en la filosofía del proyecto de Apache.

Personalmente soy usuario de log4j por varios motivos: estuvo disponible antes, es el logging nativo de mi servidor de aplicaciones habitual (JBoss) y me gusta más

Por otro lado, mi manera habitual de desarrollo es TDD, así que el IDE pasa una parte importante del tiempo ejecutando suites de tests JUnit.

Cualquiera de los frameworks de logging que utilicemos tiene el concepto de appender que es el destino en el que se escriben los mensajes. Destinos habituales suelen ser la consola o un fichero, por ejemplo. La configuración de los appenders de una aplicación se suele hacer durante el bootstrap (o la inicialización, si lo preferís) de la misma. Sin embargo cuando estamos corriendo tests, dicha inicialización no se produce así que perdemos todos los mensajes de logging que, si alguien se molestó en escribirlos, seguro que son muy útiles (especialmente cuando estamos desarrollando).

En “modo desarrollo” seguramente tenemos suficiente con una configuración básica en el que todos los mensajes se redirijan a la consola (que obviamente puede estar integrada en nuestro IDE). En el caso de log4j existe el método estático

org.apache.log4j.BasicConfigurator.configure()

que hace precisamente eso (creo recordar que java.util.logging tiene un mecanismo análogo). Ahora sólo resta saber dónde hacer la llamada al método. Obviamente no tiene sentido que lo pongamos en cada TestCase. Como en general agrupamos los diferentes tests en suites, parece que este es un buen lugar para configurarlo. Por ejemplo:

@RunWith(Suite.class)
@Suite.SuiteClasses(value={
    nq.quota.QuotaTest.class,
    nq.quota.FrequencyTest.class,
    })
public class AllTests {
    @BeforeClass
    public static void startup() {
        BasicConfigurator.configure();
    }
}

En el código precedente se ve la configuración de una test suite con JUnit 4 y etiquetamos un método de inicialización como @BeforeClass para asegurarnos que se ejecuta una única vez y antes de que la suite lance todos los tests configurados.

Esta misma idea puede utilizarse para configurar todos aquellos compartidos por los diferentes tests: variables de entorno, conexiones a bases de datos, etc.

Tagged: JUnit, logging, TDD

Bug con el tracker en Ubuntu 9.04 – Jaunty Jackalope

Iván Párraga García — Sun, 24 May 2009 17:35:01 +0000

Como sabéis soy bastante pro-Ubuntu. Me parece un gran entorno de escritorio y de desarrollo y sólo cambio a otros (y dentro de una máquina virtual, por supuesto) ante la falta de sensibilidad de algunos fabricantes de dispositivos (Apple, TomTom, Logitech, por citar algunos) que te obligan a utilizar software no compatible con Linux para utilizar las características avanzadas de dichos dispositivos. También es lamentable que para utilizar algunas páginas web (especialmente de la administración pública) tengas que recorrer al Internet Explorar. Pero bueno, esto es otra guerra.

Hace poco se lanzó la versió Ubuntu 9.04 (alias Jaunty Jackalope) e hice el upgrade hace unas semanas. Los upgrades de Ubuntu también dan gusto: todo se hace de manera automática, no pierdes el control sobre tus cofiguraciones propias (ficheros de configuración de servicios como MySQL, Samba, etc.) y todo funciona correctamente.

No obstante venía observando que a la que la máquina llevaba un rato encendida, se me disparaba el uso de una de las CPU, el ordenador no paraba de rascar disco duro y se recalentaba que daba gusto, de hecho hasta incluso llegar a colgarse en alguna ocasión. La verdad es que hace unos meses le metí mano al hardware del portátil y le metí un disco mucho mayor (como estaba metido en temas de formación necesitaba tener instaladas unas cuantas máquinas virtuales simultáneamente) y mucho más rápido y, que por tanto, se calentaba más y pensé que a lo mejor no había sido muy buena idea… Pero no tenía sentido, porque no había tenido ningún problema antes con el Ubuntu 8.10 y al arrancarlo ahora en modo Windows (sí, soy culpable, tengo una partición nativa Windows para casos de urgencia) tampoco había problema.

Tirando de top en un momento que se disparaba el uso vi que había un proceso comiéndose una CPU entera y accediendo sospechosamente al disco: tracker-indexer. Este proceso se corresponde con la utilidad tracker que es algo parecido al locate de toda la vida, un proceso que analiza el disco, e indexa su contenido para tener un acceso rápido en las búsquedas. Me sorprendió un poco porque creía haberlo desinstalarlo hace mucho tiempo (desde luego no aperecía como antes en la interfaz gnome) y además había instalado el Google Desktop que es un software análogo pero que personalmente me gusta más.

En cualquier caso, el tracker no debería comerse una CPU y llevar el portátil hasta la extenuación por calor del disco duro. Googleando un poco se ve que es un bug conocido en la nueva versión de Ubuntu. La verdad es que no me he molestado mucho en mirar si tiene solución, porque, como he dicho, es un software que no utilizo, así que simplemente he abierto el Synaptic, he buscado el paquete asociado y lo he desinstalado efectivamente y todo solucionado.

Por cierto, con una instalación “limpia” deJaunty Jackalope, el tracker no vien pre-instalado.

Tagged: Jaunty Jackalope, Ubuntu

Teclas de función y modificadores no funcionan en VMware Workstation 6.5 en Ubuntu 8.10

Iván Párraga García — Sun, 08 Mar 2009 18:42:21 +0000

Mi estación de trabajo es un Ubuntu 8.10 workstation. Estoy muy contento con el sistema operativo tanto para desarrollo como para el resto de tareas que necesito hacer con un ordenador (ofimática, multimedia, internet, etc.). Sigo teniendo un arranque dual con el Windows XP que venía preinstalado en mi portátil (no me dejaron elegir ), aunque la verdad es que no suelo arrancar casi nunca la partición con el sistemas operativo de Microsoft.

De todos modos para algunas herramientas muy concretas todavía no he podido librarme al 100% del Windows. Para no tener que estar reiniciando la máquina continuamente, tengo una máquina virtual con una imagen de XP que arranco cuando me hace falta usar alguna de estas herramientas. También utilizo máquinas virtuales para hacer pruebas varias y para poder poder provisionar rápidamente máquinas.

En su momento evalué varias máquinas virtuales, incluyendo VirtualBox (un proyecto open source muy interesante) y VMware. Finalmente, por facilidad de instalación y mantenimiento y por estabilidad en huéspedes Windows me decanté por la segunda.

Todo perfecto. El 95% del trabajo en Linux y cuando necesitaba sin remedio Windows, arrancaba la máquina virtual y listo.

El problema surgió tras una actualización de Ubuntu (aunque no sabría decir cuál concreta causó el problema): cuando arrancaba las máquinas virtuales, habían dejado de funcionar las teclas especiales, teclas tales como las flechas, el pad numérico, Inicio, Fin, etc.

Tras googlear un poco, ha resultado que la solución es bastante sencilla. Sólo hay que modificar el fichero de configuración del VMware, que en Ubuntu está en /etc/vmware/config para añadir la línea siguiente:

xkeymap.nokeycodeMap = "true"

Me ha funcionado tanto con huéspedes Windows como Ubuntu.

ACTUALIZACIÓN:

La solución anterior aparentemente funcionaba bien pero la tecla ALT GR seguía sin funcionar. Investigando un poco más he encontrado la siguiente solución que sí que ha funcionado para todas las teclas. Consiste en establecer un mapeo manual de todas las teclas. Así pues, en el mismo fichero de configuración, borramos la línea anterior y añadimos las siguientes:

xkeymap.keycode.108 = 0x138 # Alt_R
xkeymap.keycode.106 = 0x135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0x148 # Up
xkeymap.keycode.116 = 0x150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0x152 # Insert
xkeymap.keycode.119 = 0x153 # Delete
xkeymap.keycode.110 = 0x147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0x149 # Prior
xkeymap.keycode.117 = 0x151 # Next
xkeymap.keycode.78 = 0x46 # Scroll_Lock
xkeymap.keycode.127 = 0x100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menu

Tagged: Ubuntu, VMware

Métricas de calidad con NetBeans y Hudson

Iván Párraga García — Thu, 05 Mar 2009 18:21:41 +0000

Este artículo como PDF.

Introducción

En un post anterior expliqué cómo montar un entorno de integración continua básico, que luego completamos para que también se convirtiera en un verdadero entorno TDD con tests y métricas de cobertura. El siguiente paso para tener un entorno totalmente ágil consiste en añadir métricas de calidad de código para favorecer la mejora continua del trabajo hecho por todo el equipo y para que los gestores puedan tener una perspectiva algo más “objetiva” del nivel de calidad. Continuaré en este tutorial sobre el mismo ejemplo, así que en numerosos puntos haré referencias a los artículos previos para no tener que repetirme más de lo necesario.

Nótese que he puesto la palabra objetiva entre comillas. En este artículo vamos a ver una serie de herramientas que detectarán malas prácticas, bugs potenciales o puntos mejorables y generarán informes al respecto. El desarrollo de software es algo muy complejo y la medida de su calidad real no es automatizable (si así fuera, también lo sería su desarrollo y aún no hemos llegado a ese punto), ni hay un convenio universal de en qué consiste, con lo cual hay que saber leer e interpretar el resultado que producen estas herramientas. Si están avisando de que nuestro código tiene problemas, muy probablemente tengan razón y deberemos poner medidas correctoras. Lo contrario, sin embargo, no implica que nuestro código sea de alta calidad, sino que no se han encontrado aquellas cosas que se sabe que producen problemas. No se podrá automatizar, por ejemplo, cosas como la detección de uso inadecuado de patrones de diseño o la escalabilidad de la plataforma, que podríamos estar de acuerdo que son medidas de calidad. Simplificando mucho: se puede detectar que el código de un proyecto tiene poca calidad de manera automática, pero no se puede decir que para aquellos para los que no se ha detectado, el código sea de alta calidad.

Hechas estas matizaciones, en este artículo vamos a explicar cómo integrar las siguientes herramientas en NetBeans y Hudson usando Ant:

Checkstyle : genera informes sobre el grado de seguimiento del código a los estándares de codificación establecidos.
Simian : detector de copia de bloques de código.
PMD : analizador de código estático en busca de posibles bugs y malas prácticas.
FindBugs : similar al anterior.

El procedimiento de instalación de las herramientas va a ser análogo para cada una de ellas:

Instalación del plugin correspondiente en el NetBeans (si lo hubiere) y configuración del mismo.
Instalación de las bibliotecas de la herramienta en la máquina de desarrollo.
Modificación del script del Ant para poder lanzar el análisis sin la ayuda del IDE.
Instalación del plugin correspondiente en el Hudson.
Modificación del job para incluir la generación y publicación de informes correspondientes.

Checkstyle

Cuando hablo de estilo de codificación (o convenciones de código) me refiero a cosas como el nivel de indentación, utilizar espacios o tabuladores, añadir comentarios, cómo organizar las llaves de los bloques de código, el tamaño máximo de la línea, etcétera.

Parece un hecho ampliamente aceptado que la uniformidad de estilo a la hora de codificar facilita el grado de cohesión del equipo de desarrollo, la mantenibilidad de la base de código y en definitiva la productividad. Si todo el equipo trabaja con un mismo estilo, puede entender la estructura del programa más fácilmente de un vistazo.

En el mundo Java, Sun proporcionó unas guías de estilo que han sido ampliamente adoptadas por la comunidad. En este documento las podéis encontrar junto con los motivos que hay detrás de cada convención.

Checkstyle es una herramienta que genera informes del nivel de seguimiento de estas convenciones. Seguir el estilo al pie de la letra puede resultar algo duro en ocasiones, así que también es posible rebajar el nivel de exigencia decidiendo para qué convenciones se quiere generar una alarma y cuáles se puede ignorar o incluso para definir nuestras propias convenciones.

Checkstyle lo tenemos disponible en las tres vertientes: plugin para el NetBeans, como task del Ant y como plugin del Hudson.

Plugin para NetBeans del Checkstyle

El plugin no forma parte de los repositorios estándar, así que el primer paso para instalarlo será añadir el repositorio correspondiente. Para ello iremos a: Tools -> Plugins -> Settings -> Add y añadiremos la siguiente url : http://www.sickboy.cz/checkstyle/autoupdate/autoupdate.xml tal y como se muestra en las siguientes imágenes.

A continuación hacemos click en la pestaña de Available Plugins y seleccionamos Checkstyle Beans Library y Checkstyle Beans Plugin y los instalamos (seguimos los pasos indicados por el asistente y cuando nos pregunte si queremos instalar plugins no firmados le decimos que sí) . Ahora sólo resta reiniciar el NetBeans para que cargue el plugin.

Ahora cada vez que alguna línea de código no conforme con respecto a las convenciones de Sun, aparecerá una etiqueta a modo de aviso. Poniendo el ratón encima de la etiqueta, mostrará cuál es la convención que no se está siguiendo.

Como decía, se pueden utilizar plantillas con convenciones personalizadas. Para ello deberemos editar la configuración por defecto que se encuentra en: Tools -> Options -> Miscellaneous -> Checkstyle.

Incluir Checkstyle en el script de Ant del NetBeans

Como ya he explicado en otros artículos, NetBeans realiza todas sus tareas mediante scripts Ant que autogenera y el build.xml que hay en la raíz del proyecto es extensible para que los desarrolladores podamos introducir nuestros propios targets .

Lo primero que tenemos que hacer es descargarnos la distribución del Checkstyle (en el momento de escribir este artículo la versión 5 sigue siendo beta , así que yo me decanto por la versión 4.4) que, entre otras cosas, aporta los tasks necesarios para invocarlo desde Ant. A continuación habremos de descomprimir el paquete en algún lugar de la máquina de desarrollo. Yo, siguiendo mi propio estándar, lo situaré en el directorio /srv y luego lo enlazaré con un link simbólico para no tener que hardcodear la ruta hacia una versión concreta en ningún fichero de configuración o script que haga uso del mismo. También crearé un enlace simbólico al jar que contiene la implementación del task por el mismo motivo.

root@hargon:/srv# tar -zxf checkstyle-4.4.tar.gz
root@hargon:/srv# ln -s checkstyle-4.4 checkstyle
root@hargon:/srv# ls -alh checkstyle
lrwxrwxrwx 1 root root 14 2009-02-25 16:24 checkstyle -> checkstyle-4.4
root@hargon:/srv# rm checkstyle-4.4.tar.gz
root@hargon:/srv# cd checkstyle
root@hargon:/srv/checkstyle# ln -s checkstyle-all-4.4.jar checkstyle-all .jar

El siguiente paso consiste en modificar el build.xml . Lo primero que vamos a necesitar es importar el task tal y como sigue:

    resource="checkstyletask.properties"
    classpath="${checkstyle.dir}/checkstyle-all.jar"/>

Puesto que el valor de checktyle.dir puede ser diferente en la máquina de diferentes desarrolladores o en la máquina que contiene en el servidor de integración, esta propiedad la definimos en el fichero de propiedades privadas del proyecto (que recordemos no forma parte del repositorio de código): nbproject/private/private.properties.

checkstyle.dir=/srv/checkstyle

Como yo estoy partiendo del mismo ejemplo del artículo previo donde explicaba cómo integrar Cobertura, yo ya tengo definido un import en el build.xml del fichero de propiedades privadas, si no lo tuvierais acordaros de añadirlo.

A continuación definimos el target que construirá los informes en el build.xml :



     file="nbproject/project.properties"/>

    

    
        config="${checkstyle.dir}/sun_checks.xml">
        
        
            toFile="${checkstyle.report.dir}/checks.xml"/>
        
            toFile="${checkstyle.report.dir}/checks.txt"/>

El target es bastante fácil de entender. En primer lugar construimos el directorio donde se generarán los diferentes informes. A continuación lanzamos el task del Checkstyle indicándole que siga procesando el build.xml aunque se encuentren fallos de formato ( failOnViolation=”false” ) y que utilice las convenciones definidas en el fichero sun_checks.xml que forma parte de la distribución estándar de Checkstyle. Este fichero es donde se describen, en un formato que escapa al ámbito de este artículo, cuáles son las convenciones que caso de no seguirse generan un aviso. Obviamente podemos editar o sustituir este fichero por otro adaptado a nuestras necesidades, pero si dejamos éste, forzamos las convenciones de Sun que, como ya había indicado previamente, se describen en este documento .

Finalmente generamos los informes en dos formatos: en texto plano y en XML. El primero es más sencillo de leer por humanos pero el segundo es el adecuado para integrarlo con Hudson.

En este target presuponemos inicializadas las propiedades checkstyle.dir , src.dir y checstyle.report.dir . La primera ya la hemos configurado en el punto anterior, la segunda forma parte de las propiedades creadas por NetBeans y la última la tenemos que definir. Las añadiremos como propiedades del proyecto en el nbproject/project.properties :

reports.dir=${build.dir}/reports
checkstyle.report.dir=${reports.dir}/checkstyle-report

Integrando Checkstyle con Hudson

Para generar los informes en Hudson nos aprovecharemos del target que acabamos de definir en el build.xml del NetBeans, por tanto el proceso va a ser sencillo:

añadir el plugin del Checkstyle al Hudson,
instalar las bibliotecas del Checkstyle en la máquina donde reside el Hudson,
añadir las propiedades privadas a mano (recordad que este fichero no forma parte del Subversion),
añadir el nuevo target en la construcción del proyecto,
configurar el job para que utilice el target .

El proceso para instalar el plugin, ya lo hemos visto en el post donde explicaba cómo añadir el plugin de Cobertura . Básicamente, seleccionarlo de la lista de plugins disponibles, instalarlo con el asistente y reiniciar el Hudson.

Utilizaré el mismo procedimiento y ruta para instalar la distribución del Checkstyle en el servidor donde se ejecuta el Hudson, así que repetiré exactamente los mismos pasos que hice en la máquina de desarrollo.

A continuación tenemos que modificar las propiedades privadas para añadir la ruta al Checkstyle. Nos situaremos en el directorio del job y editaremos (o crearemos) el fichero nbproject/private/private.properties para añadir la línea:

checkstyle.dir=/srv/checkstyle

Finalmente añadimos checkstyle-report a la lista de tagets a construir y configuramos el job para que lea los informes generados en xml y los publique. Adicionalmente podemos configurar opciones avanzadas como los límites a partir de los cuales el build debe considerarse inestable o roto.

Ahora ya sólo resta ver los informes que genera el Hudson:

Simian

Alguna vez oí, aunque no recuerdo la fuente, que en informática la duplicación es el diablo y yo no puedo estar más de acuerdo. En ciertas ocasiones requerimientos no funcionales, como por ejemplo eficiencia, puede requerir duplicar información (denormalización de tablas en bases de datos, materialización de cálculos de agregación de información, etc), pero ello debe ser consecuencia de una decisión de diseño meditada y no de la dejadez. La replicación de código, en general, es menos justificable e introduce un gran coste en mantenibilidad y calidad: modificaciones en cualquiera de las copias debería llevar aparejadas actualizaciones en el resto, lo cual se hace muy tedioso y complicado de implementar.

Por todo lo anterior, si tenemos repetido un bloque de código de un tamaño razonable, probablemente ello está descubriendo un mal diseño y ese código debería encapsularse de alguna manera para que exista en un único punto.

Simian es la herramienta que nos va a permitir encontrar replicación de bloques de código (o de texto en general) en una gran cantidad de lenguajes de programación y formatos de texto. Hasta donde yo sé, no existe como plugin para NetBeans (aunque sí para Eclipse e IntelliJ). Sí que existe el task para Ant y como plugin para el Hudson y por tanto veremos estas configuraciones.

Como el procedimiento para incluir nuevas herramientas de análisis y métricas va a ser siempre muy similar a lo que he explicado en el caso del Checkstyle, no explicaré el proceso de una manera tan detallada (entre otras cosas porque no aporta nada y sólo hace crecer el documento).

Incluir Simian en el script de Ant del NetBeans

Lo primero es obtener y configurar la herramienta en el entorno de desarrollo, para ello lo descargamos , lo descomprimimos en /srv / (id con cuidado porque el paquete no contiene un directorio raíz) y creamos el enlace simbólico correspondiente.

root@hargon:/srv# mkdir simian-2.2.24
root@hargon:/srv# cd simian-2.2.24
root@hargon:/srv/simian-2.2.24# mv ../simian-2.2.24.tar.gz .
root@hargon:/srv/simian-2.2.24# tar -zxf simian-2.2.24.tar.gz
root@hargon:/srv/simian-2.2.24# rm simian-2.2.24.tar.gz
root@hargon:/srv/simian# cd bin/
root@hargon:/srv/simian/bin# ln -s simian-2.2.24.jar simian.jar
root@hargon:/srv/simian-2.2.24# cd ../..
root@hargon:/srv# ln -s simian-2.2.24 simian

A continuación configuramos el build.xml de manera análoga al Checkstyle:

    resource="simiantask.properties"
    classpath="${simian.dir}/bin/simian.jar"/>


     file="nbproject/project.properties"/>

    

    
        

        
            toFile="${simian.report.dir}/simian.xml"/>

        
            toFile="${simian.report.dir}/simian.txt"/>

Las propiedades las definiremos allí donde toca: el simian.dir (con valor /srv/simian ) en el nbproject/private/private.properties y el simian.report.dir (con valor ${reports.dir}/simian-report ) en el nbproject/project.properties .

El task de Simian es muy sencillo. En su configuración simple tal y como tenemos, tan sólo hace falta especificar el directorio que contiene el código a analizar y el formato de los informes (en XML para integrarse con el Hudson y en texto plano para que sea más legible por humanos).

Integrando Simian con Hudson

Como en el caso del Checkstyle, replicamos la instalación de Simian en la máquina donde se encuentra el Hudson y definimos la propiedad simian.dir en el nbproject/private/private.properties .

El siguiente paso debería consistir en instalar el plugin del Simian para el Hudson, pero cuando lo buscamos en la lista de plugins disponibles nos damos cuenta que no aparece. Afortunadamente existe un plugin llamado Violations que integra diferentes herramientas de análisis estático de código (de hecho podríamos utilizar este mismo plugin para otras de las tratadas en este artículo) y que tiene soporte para Simian. Lo instalamos de la manera habitual, reiniciamos el Hudson para que lo cargue y el siguiente paso consiste en configurar el job . Como siempre, añadiremos el simian-report a la lista de targets a construir por el Ant y a continuación configuramos el plugin tal y como se muestra en la ilustración (también podemos definir los límites a partir de los cuales se rompe el build ).

Tras construir el job podremos ver los informes de replicación de código de manera integrada en el Hudson.

PMD

Tanto PMD como FindBugs, son herramientas de análisis estático de código (analizan el código y no el programa en ejecución) en busca de estructuras potencialmente peligrosas tales como:

posibles bugs,
código “muerto” (variables no accedidas, bloques de ejecución inalcanzables, etc.),
código subóptimo,
bloques con una estructura poco legible o más complicada de lo necesario.

Estas herramientas son especialmente útiles integradas en el IDE porque de esta manera el programador puede ir viendo mientras escribe el código las posibles alertas. Obviamente también tienen tasks de Ant lo que permite integrarlas fácilmente en Hudson para obtener los informes correspondientes.

Plugin para NetBeans del PMD

En este caso el plugin del PMD no está accesible mediante un repositorio, por lo que para instalarlo procederemos a la descarga del mismo y a su instalación local.

Una vez tenemos el fichero, deberemos descomprimirlo y nos quedamos con el plugin empaquetado en el fichero pmd.nbm que instalaremos a través la pestaña Downloaded del gestor de plugins: primero lo añadimos a la lista mediante el botón Add Plugins y después le damos a Install .

Aceptamos la licencia, asumimos el riesgo de instalar un plugin “no firmado” y rebotamos el IDE para que se reflejen los cambios.

En este momento el plugin debería estar listo para ser utilizado. Mientras trabajamos PMD monitorizará el código que escribimos y nos pondrá una marca en el editor cuando algo no le guste. Si ponemos el puntero encima de la marca, se nos mostrará un mensaje informativo del problema en forma de tooltip .

Si queremos obtener un informe de todos los posibles problemas en una carpeta de código, paquete o clase, sobre la ventana Projects hacemos click derecho en el elemento correspondiente -> Tools -> Run PMD.

Ello abrirá una nueva pestaña de informe con todas los avisos disponibles en forma de tabla (permitiendo ordenación por las diferentes columnas). Haciendo doble click sobre cualquiera de las advertencias, el editor se desplazará a la línea de código correspondiente.

PMD puede ser muy estricto y es posible que nos interese personalizar el tipo de alertas generadas y, quizá, desactivar algunas. Hay que encontrar un compromiso entre lo razonable y la calidad. Por ejemplo, algunas de las estructuras autogeneradas por el IDE (como el equals mostrado en el ejemplo unas líneas más arriba) producen advertencias que podríamos ignorar con tranquilidad ya que NetBeans sabe lo que hace . Para modificar la configuración del plugin y el tipo de reglas que aplicar, nos vamos al menú de opciones: Tools -> Options -> Miscellaneous.

Las reglas se gestionan mediante rulesets temáticos. Es decir un ruleset puede contener todas aquellas reglas ( rules) que tengan que ver, por ejemplo, con código muerto. Mediante el menú de rulesets podemos incluir o no las incluidas con PMD y añadir otras propias generadas por nosotros o por terceros. En el menú Manage rules se nos permite la activación o desactivación de reglas individuales.

Incluir PMD en el script del Ant de NetBeans

De manera análoga a las herramientas anteriores, descargamos e instalamos la herramienta en /srv .

root@hargon:/srv# unzip -q pmd-bin-4.2.5.zip
root@hargon:/srv# ln -s pmd-4.2.5/ pmd
root@hargon:/srv# rm pmd-bin-4.2.5.zip
root@hargon:/srv# cd pmd/lib/
root@hargon:/srv/pmd/lib# ln -s pmd-4.2.5.jar pmd.jar

A continuación modificaros el build.xml de manera adecuada.

    classname="net.sourceforge.pmd.ant.PMDTask"
    classpath="${pmd.dir}/lib/pmd.jar"/>


            file="nbproject/project.properties"/>

    

    
        unusedcode,basic,design,controversial
                    toFile="${pmd.report.dir}/pmd.xml"
            linkPrefix="http://pmd.sourceforge.net/xref/" />

                    toFile="${pmd.report.dir}/pmd.html"
            linkPrefix="http://pmd.sourceforge.net/xref/" />

Las propiedades las añadimos al fichero correspondiente: el pmd.dir (con valor /srv/pmd ) en el nbproject/private/private.properties y el pmd.report.dir (con valor ${reports.dir}/pmd-report ) en el nbproject/project.properties .

El task del PMD es sencillo de utilizar. Primeramente indicamos qué rulesets de los estándar queremos analizar (podríamos también especificar rulesets personalizados) y a continuación indicamos en qué formatos queremos generar los informes. Como es habitual, tendremos los informes en XML que se integran bien con Hudson y en formato HTML para ser leídos por humanos.

Integrando PMD con Hudson

Al igual que las dos herramientas anteriores, instalamos PMD en el servidor de integración y definimos la propiedad pmd.dir en el nbproject/private/private.properties .

A continuación instalamos el plugin del PMD del Hudson de la manera habitual (no olvidéis rebotar lo) y ya podemos proceder a la configuración del job tal y como se muestra en la siguiente captura. Obviamente podemos establecer los límites que por defecto, como casi siempre, están desactivados.

Y estos serían los informes generados.

FindBugs

Sin entrar en demasiados detalles, FindBugs es una herramienta similar a la anterior. En el momento de escribir este tutorial todavía no existe una versión compatible del plugin para NetBeans 6.5, pero los ingenieros de FindBugs están trabajando en ello y me imagino que estará disponible en breve (sí que existen versiones funcionales para otros IDEs).

Incluir FindBugs en el plugin de Ant de NetBeans

Procedemos a descargar el paquete para instalarlo de la manera habitual.

root@hargon:/srv# tar -zxf findbugs-1.3.7.tar.gz
root@hargon:/srv# ln -s findbugs-1.3.7 findbugs
root@hargon:/srv# ls -alh findbugs
lrwxrwxrwx 1 root root 14 2009-03-05 15:55 findbugs -> findbugs-1.3.7

A continuación modificamos el build.xml para añadir un target que use el task del NetBeans.

    classname="edu.umd.cs.findbugs.anttask.FindBugsTask"
    classpath="${findbugs.dir}/lib/findbugs.jar" />



    

    

            output="xml"
        outputFile="${findbugs.report.dir}/findbugs.xml">

Como en los casos anteriores, añadimos las propiedades a los ficheros correspondientes: el findbugs.dir (con valor /srv/findbugs ) en el nbproject/private/private.properties y el findbugs.report.dir (con valor ${reports.dir}/findbugs-report ) en el nbproject/project.properties .

El task del FindBugs requiere no sólo el código fuente sino también las clases compiladas y por ello el target tiene una dependencia del target estándar de NetBeans compile . Las clases compiladas se referencian mediante una propiedad también estándar de NetBeans: build.classes.dir .

El resto de propiedades son las típicas que hemos ido viendo, el directorio de instalación de la herramienta y el directorio de salida de los informes.

En este caso estamos generando los informes en XML que son los que entiende Hudson, pero también pueden generarse en otros formatos, como en texto plano o en HTML.

Integrando FindBugs con Hudson

Como siempre, replicamos la instalación del FindBugs en la máquina donde está instalado el Hudson y definimos la propiedad findbugs.dir apuntando al directorio correspondiente en el nbproject/private/private.properties .

FindBugs también tiene un plugin nativo para Hudson, así que lo instalamos y reiniciamos. A continuación, de manera totalmente análoga al PMD, configuramos el nuevo target y las opciones de FindBugs.

Finalmente ya podemos ver los informes generados.

Conclusión

En este artículo hemos aprendido que existen herramientas que nos pueden ayudar a generar métricas sobre la calidad de nuestro código. También hemos enfatizado el hecho que obtener un 100% de puntuación no garantiza un software de calidad.

Hemos visto que las herramientas suelen venir en tres “sabores”: como plugin para el IDE que dan un feedback inmediato al programador, como task del Ant que permiten ejecutarlas en modo consola e integrarlas con otros sistemas y como plugin para Hudson que permite publicar los informes correspondientes de una manera agradable para los humanos.

Existen muchas más herramientas de calidad. En próximos artículos tocaré algunas mas.

Tagged: Agile, Ant, calidad, Hudson, Java, NetBeans

Problemas desplegando unidades de persistencia en JBoss 5

Iván Párraga García — Tue, 24 Feb 2009 19:02:03 +0000

En los últimos cursos que he dado sobre tecnologías JEE he utilizado los productos open source de Sun porque se integran bastante bien y además los considero más adecuados para formación que otras posibles alternativas. En particular, he estado utilizando NetBeans y Glassfish para explicar EJB 3.0 y las apis de persistencia y transaccionalidad (JPA y JTA).

Hace unos días me bajé JBoss AS 5 para ver las novedades que presentaba (ya que en el pasado trabajé bastante con él) y al ir a desplegar algún jar que había funcionado perfectamente en Glassfish me ha dado problemas. Como sospechaba, el problema estaba en el context.xml y en que JBoss AS se ha vuelto un poco más pijo.

Veámoslo con un ejemplo. Este es el persistence.xml que funcionaba sin problemas en Glassfish y que reventaba en el JBoss:



  
    org.hibernate.ejb.HibernatePersistence
    banco
    false

Esta es la salida que producía en el log del JBoss:

2009-02-24 19:28:42,832 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) Error installing to Parse: name=vfszip:/home/ivan/jboss-5.0.0.GA/server/all/deploy/titan.jar state=Not Installed mode=Manual requiredState=Parse
org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfszip:/home/ivan/jboss-5.0.0.GA/server/all/deploy/titan.jar
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:337)
	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:297)
	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:269)
	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:230)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
	at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:290)
	at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to resolve schema nsURI= location=persistence
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
	at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168)
	at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:199)
	at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
	at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
	at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
	at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:188)
	at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:323)
	... 27 more
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve schema nsURI= location=persistence
	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:313)
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
	at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:199)
	... 35 more
2009-02-24 19:28:42,848 WARN  [org.jboss.system.server.profileservice.hotdeploy.HDScanner] (HDScanner) Failed to process changes
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

*** CONTEXTS IN ERROR: Name -> Error

vfszip:/home/ivan/jboss-5.0.0.GA/server/all/deploy/titan.jar -> org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve schema nsURI= location=persistence

	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:863)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:665)
	at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:293)
	at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)

La solución ha sido más o menos sencilla: definir el espacio de nombres XML tal y como sigue y la unidad de persistencia se ha desplegado sin más problemas:



   
      java:/DefaultDS

Tendré que echar un ojo a la especificación de JPA para ver si definir el espacio de nombres es obligatorio, aunque me parece recordar que esto no era una exigencia en versiones anteriores de JBoss AS…

Tagged: j2ee, Java, JBoss, logging

Configuración de logging global en Java

Iván Párraga García — Thu, 19 Feb 2009 13:04:38 +0000

: Image via Wikipedia

Hoy me he pasado unas cuantas horas peleándome con una tontería. La típica cosa que cuando ves lo que es te da una rabia infinita

Aunque en el pasado había trabajado bastante con JBoss AS aún no me había dado tiempo a probar la versión 5 que se liberó en diciembre, así que he decidido utilizarlo para un pequeño proyectito y así tener la excusa de ver qué novedades presenta.

Mi sorpresa ha sido que al ponerlo en marcha se ha puesto a sacar tal cantidad de información de logging por la consola que el pobre ha tardado más de 10 minutos en arrancar. Cara de póquer. Como me conozco el servidor, me voy a ver la configuración de logging del mismo que está en:

JBOSS_HOME/server/default/conf/jboss-log4j.xml

Si no recuerdo mal en anteriores versiones el fichero se llamaba a secas log4j.xml, pero al echarle un vistazo su estructura es la misma que en versiones anteriores. Sigue utilizando log4j en vez de la api de logging de de la JSE y por defecto configura dos appenders: uno de consola con límite en el nivel WARN y otro de fichero.

Ahora sí que no entendía nada: ¿cómo es posible que la consola esté sacando tanto mensaje de logging y además con un nivel TRACE cuando la configuración limita al nivel a WARN?

Sigo investigando y compruebo que la información de logging que se corresponde con lo que yo voy configurando en dichero fichero sale por la salida estándar y que los mensajes “okupas” en realidad están saliendo por el canal de error… Además otros dos detalles, estos mensajes se corresponden con clases de la JSE y no tienen el mismo formato (pattern) que el resto de mensajes… Es más, parece que tienen formato del paquete de logging estándar de JSE…

Fallo localizado, tengo activado el logging estándar de la JSE (javax.util.logging) al nivel más alto. Ahora sólo falta averiguar por qué. Tras probar una serie de cosas estrambóticas, el fallo estribaba en que en algún momento (que no logro recordar) había cambiado la configuración global del logging estándar; ¿cómo se hace esto? Editando un fichero que se encuentra en la carpeta lib de la JRE instalada, en particular:

JAVA_HOME/jre/lib/logging.properties

En dicho fichero tenía establecido lo que llaman el “Default global logging level” a ALL. Al cambiarlo a WARNING todo volvió a la normalidad.

../..
# Default global logging level.
# This specifies which kinds of events are logged across
# all loggers.  For any given facility this global level
# can be overriden by a facility specific level
# Note that the ConsoleHandler also has a separate level
# setting to limit messages printed to the console.
.level= WARNING
../..

Tagged: Java, logging

DZone y Refcardz

Iván Párraga García — Wed, 11 Feb 2009 19:10:12 +0000

Una de las suscripciones que tengo en mi GoogleReader es el feed de DZone. En esta web se pueden leer artículos muy interesantes, bien redactados y estructurados y, en muchas ocasiones, escritos por eminencias en diferentes campos de la ingeniería del software. Las temáticas que cubren son diversas (patrones de diseño, antipatrones), metodologías, lenguajes, tecnologías concretas, tendencias, comparativas, etc. Cuando aparece un nuevo post suele ser uno de los feeds que tienen preferencia en mi orden de lectura.

Al margen de los artículos, son los encargados de publicar las Refcardz. Son unos documentos PDF con un estilo vistoso, funcional, uniforme y, sobre todo, breve que cuben en pocas páginas las ideas fundamentales de una tecnología concreta. Generalmente encajan en alguna de las siguientes categorías: herramientas, lenguajes y frameworks y, más raramente, arquitectura.

Yo las utilizo bajo dos puntos de vista:

Cuando conozco la tecnología, las utilizo como guía de referencia rápida (por ejemplo, la de NetBeans tiene tablas con todas las combinaciones de teclas o con las diferentes plantillas de código y la de JPA tiene resúmenes de todas las etiquetas disponibles). Además suelen incluir ejemplos muy prácticos que permiten recordar de un vistazo cómo usar la tecnología que están ilustrando.
Cuando es una tecnología que no conozco en profundidad o que me es desconocida las utilizo para hacerme una primera idea de las posibilidades que ofrece. Además suelen ofrecer punteros a otras fuentes de documentación o libros.

Estas fichas tecnológicas tienen una gran calidad de edición y de contenidos (se nota que el proceso de producción hasta que se hacen disponibles está muy cuidado) y están escritas por expertos en la materia que ilustran.

Además son GRATIS y se pueden usar sin restricciones. El truco es que el autor de la misma incrementa su reputación por tener la ficha y además se reserva un pequeño espacio donde éste puede publicitar su libro (siempre referente a la tecnología de la ficha en custión).

También existe un feed que informa de la publicación de nuevas fichas. Cuando aparece una nueva entrada no puedo evitar bajarme rápidamente el PDF.

Tagged: ingeniería del software

Presentación de administración de Tomcat

Iván Párraga García — Mon, 09 Feb 2009 19:30:47 +0000

: Image via Wikipedia

Hola,

Os cuelgo una presentación (creo que completita) que preparé para un curso de administración de Tomcat. Esta vez os lo cuelgo en un formato decente: en PDF.

La distribuyo bajo licencia . Si alguien quiere hacer un uso comercial que se ponga en contacto conmigo.

En algunas transparencias aparece en rojo “Ejercicio MxEy”, lo que quiere decir que en ese punto de la presentación había previsto un ejercicio correspondiente al módulo x con número de ejercicio y. Si alguien quiere los enunciados y las soluciones, que me los pida sin ningún problema (es una pena que wordpress no deje subir zips o tars).

Aprovecho para comentar que en este momento soy profesional freelance y que me ofrezco para temas de asesoría y/o formación en los temas sobre los que posteo.

El índice de la presentación es el siguiente:

Introducción
Instalación de Tomcat
Aplicaciones web con Java
Configurar Tomcat
Gestionar aplicaciones web
Características avanzadas
Conexión con bases de datos
Conectores
Seguridad
Alojamiento compartido

Tagged: Java, Presentación, Tomcat

Presentación desarrollo del software para no informáticos

Iván Párraga García — Sun, 08 Feb 2009 11:39:49 +0000

Os cuelgo una presentación sobre ingeniería informática y desarrollo de software que hice hace unos meses para una audiencia no informática que se dedica a programar. Hablo de bastantes temas pero desde un punto de vista muy divulgativo y poco profundo. El formato es un pptx (lo siento ).

La distribuyo bajo licencia y se puede descargar aquí. Si alguien quiere utilizarla con propósitos comerciales que se ponga en contacto conmigo.

El índice de la presentación es el siguiente:

Ingeniería del Software y Metodologías
1. La problemática de la construcción de software
2. La ingeniería del software como solución
3. Partes fundamentales de la ingeniería del software
4. Ciclos de vida de construcción de software
Arquitectura de aplicaciones
1. Componentes de un sistema
2. Evolución y tipos de arquitecturas
3. Patrones de diseño
Metodologías
1. Por qué las metodologías tradicionales no son suficiente
2. Metodologías ágiles
3. TDD
Entornos y herramientas
1. Entornos de desarrollo
2. IDEs
3. Plugins e integración de herramientas
Buenas prácticas
1. Buenas prácticas generales
2. Particularidades del software científico
3. Checkpoints
Programación paralela
1. Qué es la programación paralela
2. Conceptos y clasificaciones
3. Programación paralela
4. Qué ayudas tiene el programador
Asincronía y colas
1. Sincronía vs asincronía
2. Sistemas de colas
Midiendo
1. Debugging
2. Logging
3. Profiling
4. Benchmarking
Definición de flujos

Tagged: Agile, calidad, ingeniería del software, Presentación, TDD