4 bits blog

Pongo aquí un pequeño truco (más que un truco es un archivo de configuración) para que APT no instale los paquetes recomendados por otro, suele pasar que hay paquetes que recomiendan instalar servidores de correo y, obviamente, no quiero tener un servidor de correo en muchos de mis ordenadores.

# echo 'APT::Install-Recommends "0";' > /etc/apt/apt.conf.d/90recommends

Sacado de Checklist for configuring a Debian system.

Sigo pesado con los applets, esta vez porque he descubierto un script de JavaScript (applet-fu) que permite insertar los applets en (X)HTML de manera sencilla y evitando tener que preocuparte si será compatible con IE o cumplirá los estándares (X)HTML.

A costa de unos cuantos KB del script de JavaScript que hay que incluir en el (X)HTML, se pueden insertar applets con el siguiente código:

<script type="text/javascript" language="javascript" charset="utf-8">
    applet_fu.run (
        // Atributos del elemento (X)HTML (como object)
        { 'width'  : '0',
          'height' : '0',
          'name'   : 'applet',
          'id'     : 'applet' },
        // Parámetros del applet
        { 'archive' : 'applets/Applet.jar',
          'code' : 'es.4bits.Applet' },
        // Versión de Java necesaria
        '1.6',
        // Mensaje mostrado si no se encuentra la versión de Java
        '<p>No se ha encontrado la versión de Java necesaria.</p>'
    );
</script>

Además, este código ofrece mediante el mecanismo del navegador utilizado la posibilidad de descargar Java si no se ha encontrado o si tiene una versión distinta a la necesaria.

Sun ofrece algo parecido llamado Java Deployment Kit, pero ocupa más, sólo por realizar más tareas como la posibilidad de usar Java Web Start.

Dejo el enlace a su repositorio en github, para quién lo quiera descargar: código de applet-fu.

Si alguna vez habéis tenido que programar algo para funcionar sobre la consola de Linux, a lo mejor os habría gustado poder colorear la salida, como hacen la mayoría de los programas de la consola de Linux.

Pues si vuestra consola admite colores ANSI (casi todas lo hacen, incluso la de Windows), lo tenéis muy fácil ya que mediante unas cadenas de escape se pueden cambiar los colores. Estas cadenas siguen un patrón del tipo:

<ESC>[{attr1};...;{attrn}m

Donde attrX es un código numérico que determina una característica del texto (como subrayado), el color del texto y el color del fondo de éste. Estos código están definidos y se pueden consultar en esta web que contiene las cadenas de escape ANSI.

De este modo, si se quiere cambiar el color del texto, por ejemplo en un programa en C, se haría lo siguiente:

printf ("\e[32m Soy de color verde\n");
printf ("\e[0m Vuelvo a ser del color normal.\n");

Lo normal es que estas cadenas se guarden en algún tipo de constantes, para luego usarlas y no tener que escribir la cadena de escape cada vez que queramos cambiar el color.

(Sacado de zeros and ones)

Una de las cosas que hacen grande al IDE Eclipse (que recientemente ha estrenado versión, la 3.4) es la cantidad de plugins que uno encuentra para casi cualquier cosa. Uno de esos tipos de plugin, de los más útiles, son los de herramientas de revisión de código. Si nunca habéis usado uno y tenéis la moral baja, no los uséis ahora; la primera vez siempre sonroja un tanto. En mi caso, he utilizado 3 hasta la salida del nuevo Eclipse. La mayor parte de lo que viene a continuación lo encontré después de aquel post Plugins de Eclipse, así que vamos con ellos:

FindBugs

Éste estaba en la lista anterior. Es un analizador de código bastante eficiente en lo suyo (bugs potenciales y algunas malas prácticas de programación) marcando todo lo que encuentre en 3 niveles de gravedad. Personalmente es mi favorito, sobre todo para empezar, pues no me resulta tan paranoico como los demás y puedes corregir casi todo lo que marca.

PMD

Más completo que el anterior (mucho más), además de todo lo anterior, también comprueba la complejidad o longitud del código. Pero resulta un paranoico que ofrece pocas soluciones reales. Por ejemplo, te dice que una variable se puede declarar como final y cuando la declaras te dice que no, que no se deben declarar variables finales, que uses campos. ¿¿¿¡¡En qué quedamos!!???

A su favor tiene que es mucho más completo y que también permite buscar código duplicado (malditos copypastes).

Enerjy

Me enteré de este plugin a través de JavaHispano, debido a su reciente gratuidad. Es similar al PMD, tiene algunas reglas más paranoicas todavía (uso de tabulador en lugar de espacios) y tiene la grave, gravísima desventaja de que no se ejecuta bajo demanda. Aunque puedes marcar qué proyectos excluir del análisis, me parece un tanto inviable en workspaces con muchos proyectos. Una ventaja que le encuentro es que te cambia automáticamente los bucles for de Java 1.4 por los de Java 5 (donde es posible, claro), aunque tampoco estaría mal que lo hiciera sólo si estás trabajando con Java 5 ó superior :-/

Fin

Esta última fiebre revisionista me dio tras leer Revisiones de código automatizadas con Eclipse, donde se habla más extensamente de los 2 primeros y también del CheckStyle. Éste último lo instalé, me empezó a señalar que las variables no cumplían con el estándar de nombrado y, con la misma, lo envié al limbo. Paranoias vale, pero las justas; una variable boolean que no se llame sexo no es seria ;)

¿Habéis utilizado alguno de estos plugins? ¿Quizá otro que desconozca? ¿Qué ventajas y desventajas veis a estas herramientas?

Se dice, y seguro que es verdad, que la forma de trabajar con SVN debe ser a base de branches y, una vez probados los diferentes cambios, pasarlo al trunk. Desde Eclipse, con el Subclipse, crear un nuevo branch es muy fácil, pero… ¿cómo se hace posteriormente el merge?

El día que tuve que hacerlo por primera vez seguí las instrucciones de aquí, la parte donde dice Merging Two Different Trees y que, traduciendo, resumiendo y ampliando, dice lo siguiente:

1. Ponte en la copia local del Eclipse que apunta al trunk (muy importante)
2. Pulsa botón derecho del ratón, selecciona Team → Merge
3. En el campo “From” se indica la URL completa del trunk
4. Selecciona la revisión en la que iniciaste el branch
5. Desmarca el check del Use “From:” URL
6. En el campo “To” se indica la URL completa del branch
7. Selecciona la revisión del branch que quieres juntar (habitualmente será el HEAD)
8. Pulsa “OK”
9. Finalmente, comprueba que todo es correcto, corrige posibles problemas en el buildpath y realiza un commit

Este método es exactamente lo que se debe hacer también para volver a una versión anterior (ahora que está de moda, imaginemos el fallo de Debian), salvo el paso 5 ya que estamos con la misma URL. A pesar de que algunos lo odien, SVN es a buen seguro la herramienta de control de versiones más extendida y espero que lo anterior os sirva para vuestro día a día.