4 bits blog

La mejor funcionalidad de SSH es poder usar pares de claves (pública/privada) para autenticarse en una máquina sin necesidad de introducir una contraseña. El problema radica cuando necesitas usar varios pares de claves, por ejemplo: para acceder diferentes máquinas sin compartir un mismo par de claves. Pero como con todo, siempre hay una solución para poder usar varios pares de claves distintos.

Partiendo de que se han generado dos pares de claves:

$ ssh-keygen -t rsa -f ~/.ssh/id_rsa.work -C "fran@trabajo"
$ ssh-keygen -t rsa -f ~/.ssh/id_rsa.home -C "fran@casa"

La forma sencilla es crear el archivo «~/.ssh/config», añadiéndole las siguientes líneas:

IdentityFile ~/.ssh/id_rsa.work
IdentityFile ~/.ssh/id_rsa.home

De este modo, cada vez que SSH conecte con una máquina intentará usar alguna de esas dos claves. Sin embargo, SSH permite realizar un control más granular sobre las claves, para ello habría que tener un archivo «~/.ssh/config» similar al siguiente:

Host 192.168.0.100
  IdentityFile ~/.ssh/id_dsa.home
  User franchukelly

Host ssh.trabajo.com
  IdentityFile ~/.ssh/id_rsa.work
  User fran
  Port 2211

Dónde cada campo Host permite definir una pequeña configuración que se usará de forma predeterminada cuando se realice una conexión a la dirección indicada. Por ejemplo:

$ ssh ssh.trabajo.com

SSH usaría la clave «id_rsa.work», junto al usuario «fran» y el puerto 2211.

Basado en Multiple ssh private keys.

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?