Andrés González

No, no me gusta pasar la aspiradora: iRobot

2008-05-24T21:22:00.002+02:00

Venga, regálaselo a tu pareja, a tí mismo, o a ambos:

http://mcidor.blogspot.com/2008/05/irobot.html

"disclaimer: no me dan un chavo por esto. Supongo que a Miguel Cid tampoco, jeje"

Nina Simone: My baby just cares for me

2008-05-12T17:01:00.002+02:00

Sabía que la canción estaba genial, pero... ¿y el vídeo? Eeeeeeeeeeeeeestupendo

Excelente interpretación del Júpiter de Holst

2008-05-02T20:16:00.001+02:00

Disfruten de la Osaka Philharmonic Orchestra (el director lo flipa un poco, pero la ejecución es soberbia, según mi humilde opinión):

http://www.youtube.com/watch?v=3B49N46I39Y

Desactivar la previsualización automática en el explorer de Windows

2008-04-26T11:00:00.002+02:00

Muchas veces el que el explorador de windows te "previsualice" un vídeo, una imagen, archivo de audio o similar, da más problemas que ventajas. Cuando queremos cortar y pegar uno de esos archivos, o cambiarle el nombre, o borrarlo... nos encontramos con que dicha acción no se puede llevar a cabo porque el archivo "está siendo usado por otra aplicación".

Os recomiendo desactivar esa opción ejecutando los siguientes comandos (Inicio -> Ejecutar):

regsvr32 /u shimgvw.dll

regsvr32 /u shmedia.dll

Si queremos restablecer la previsualización basta con ejecutar:

regsvr32 shimgvw.dll
regsvr32 shmedia.dll

Fuente http://ings.ca/jim/2007/08/29/disable-avi-preview-in-windows-explorer/

Los Planetas de Gustav Holst para piano

2008-04-22T16:01:00.004+02:00

Originalmente, Gustav Holst compuso los Planetas pensando en un dueto de piano.

¿Quereis haceros una idea de cómo suenan?

http://www.emusic.com/album/Len-Vorster-HOLST-Music-for-Two-Pianos-MP3-Download/10870658.html

O bien esta versión completa de Marte:

Jin Shin Jyutsu: Seminario de formación en Vigo - Chaoki El Ahel

2008-04-18T10:11:00.003+02:00

JIN SHIN JYUTSU^®

Es una Fisio-Filosofia, un arte antiguo de armonización de la energía vital en el cuerpo nacido
de la innata sabiduría y transmitido oralmente de generación en generación durante siglos, el arte estaba casi olvidado cuando el maestro Japonés Jiro Murai lo rescató de forma espectacular al Principio del siglo XX.

Al haber tenido éxito en liberarse él mismo de una enfermedad que amenazaba su vida, el maestro Murai dedicó el resto de sus días a la investigación y al desarrollo del JIN SHIN JYUTSU basándose en una gama muy amplia de experiencias personales y en recursos de manuscritos tal como KOJIKI (libro de cosas antiguas) resulta de ello, el conjunto de descubrimientos que fueron más tarde traducidos por MARY BURMEISTER quien lo trajo a los Estados Unidos en los años cincuenta.

El JIN SHIN JYUTSU se sirve de 26 situados sobre los circuitos energéticos que alimentan el cuerpo de energía vital. Cuando uno o varios de estos
circuitos están bloqueados el estancamiento que resulta de ello puede perturbar la zona que concierne, a continuación desarmonizar los flujos energéticos en su totalidad.

Tocando uno o varios de estos cierres combinados pueden entonces tomar una parte activa en el buen funcionamiento de nuestro equilibrio Físico, mental y emocional.

La práctica del JIN SHIN JYUTSU nos compromete en el estudio y la ayuda a sí mismo y a través de este proceso, tomamos conciencia de la sabiduría de nuestro cuerpo y aprendemos a interpretar sus mensajes y a utilizarlos para restablecer el Equilibrio.

El JIN SHIN JYUTSU puede aplicarse como ayuda a sí mismo o por un practicante formado. Una sesión de JIN SHIN JYUTSU dura generalmente una hora. No incluye masaje, ni manipulación de los músculos, ni el empleo de medicamentos y otras sustancias. Es un arte suave
que se practica con la punta de los dedos (encima de la ropa) sobre los cierres de seguridad de la energía útiles a la armonización y a la restauración de la circulación energética.

Este arte puede practicarse sobre sí mismo o sobre los demás. Sirve para todos, a los bebés y a los ancianos, a los enfermos y a los que están bien y a todos los que quieren estar bien.

EL SEMINARIO DE FORMACIÓN

Este seminario es dirigido a todos: a las personas que les gustaría descubrir este arte y aquellas que desearían profundizar sus conocimientos. Para una eventual práctica profesional la participación en los seminarios de formación es indispensable. Un certificado será entregado
después de haber asistido la primera vez a la primera y segunda parte en los seminarios de formación de cinco días. Otro diploma será entregado después de haber asistido tres veces a la primera y segunda parte para considerarse “practicante de JIN SHIN JYUTSU”.

Chaoki El Ahel, es un profesional muy comprometido con sus pacientes, la terapia y la medicina alternativa y vibracional. Es quien hizo posible que se conociera Jin Shin Jyutsu en España. A raíz de descubrir la rapidez, la eficacia del JSJ y el cambio de vida y la madurez que producía en sus pacientes, Chaoki se comprometió en darlo a conocer a pesar de todos los contratiempos que ha podido encontrar y encuentra. Con su respeto al código de ética e inculcando este respeto a todos los practicantes guardando así el bienestar y los intereses del paciente. Logró que en España tengamos el más alto y prestigioso nivel de JSJ de Europa.

DETALLES SEMINARIO

Lugar: Vigo - Escuela de enfermería (C/ Aragón nº 197)
Horario: 9h. - 19h.
Fechas: primer fin de semana de mayo y tercer fin de semana de mayo (pdte. de confirmar).
Participación: 600€ (400€ para segundos participantes)
Anulación: toda cantidad pagada será íntegramente devuelta si su orden de anulación se realiza antes del 25 de Abril de 2008.
Teléfono de contacto: 886134259

Fotos con categoría

2008-04-15T12:28:00.002+02:00

Link del colega tevi, quien sin duda acabará haciendo fotos tan buenas como éstas :)

http://www.timecatcher.com/main.cfm?p=04_100

No tienen desperdicio, ninguna. Recomiendo guardar enlace en favoritos y ver un par de ellas cada día...

Fotos panorámicas

2008-04-09T11:20:00.002+02:00

Gracias a Miguel Cid por el enlace: http://viewat.org/

No dejeis de echarle un vistazo, merece la pena. Fotos panorámicas de distintos lugares del mundo, animadas por flash, de forma que puedes ver el sitio casi como si estuvieras allí.

Un par de panorámicas interesantes, para abriros el apetito:

El libro de las Ilusiones

2008-03-31T16:44:00.002+02:00

Acabo de terminarlo... !Qué bueno! Desde luego este Paul Auster tiene un estilo genial.

Os lo recomiendo a todos.

Ahora... toca cambio de estilo: novéla histórica. Enola Gay, de Gordon Thomas, "una apasionante investigación sobre la bomba atómica de Hiroshima".

Un verdadero placer recuperar la lectura, la tenía bastante abandonada y... desde luego ahora mismo agradezo mucho más sentarme a leer un buen libro que encender la televisión...

Horowitz y la Polonesa más famosa de Chopin

2008-03-17T11:23:00.001+01:00

Jin Shin Jyutsu: taller de autoayuda en Vigo - Marzo 2008

2008-03-08T12:29:00.003+01:00

El último fin de semana de este mes (Marzo, 2008), es decir, los días 29 y 30, el Maestro Chaoki El Ahel impartirá en Vigo un taller de autoayuda de Jin Shin Jyutsu.

El programa será el siguiente:

I. El significado de los 26 cierres de seguridad de la energía
II. Los flujos de la trinidad.
III. La noción de profunidad en el cuerpo
IV. La fisio-filosofía del Jin Shin Jyutsu
v. Prácticas varias veces al día.

El Jin Shin Jyutsu es un arte suave y simple que se practica por imposición de la punta de los dedos sobre ciertos puntos de nuestro cuerpo ( encima de la ropa ).
Es un arte Japonés muy antiguo para la armonización de la energía vital en nuestro cuerpo.
El Jin Shin Jyutsu se sirve de 26 Puntos , "cierres de seguridad de la energía", situados sobre los circuitos energéticos que alimentan el cuerpo de energía vital. Cuando uno o varios de estos circuitos están bloqueados el estancamiento que resulta de ello puede perturbar la zona que concierne, y a continuación desarmonizar los flujos energéticos en su totalidad.Tocando uno o varios de estos puntos combinados pueden entonces tomar una parte activa en el buen funcionamiento de nuestro equilibrio físico, mental y emocional...

Chaoki El Ahel, es un profesional muy comprometido con sus pacientes, la terapia y la medicina alternativa y vibracional. Es quien hizo posible que se conociera Jin Shin Jyutsu en España. A raíz de descubrir la rapidez, la eficacia del JSJ y el cambio de vida y la madurez que producía en sus pacientes, Chaoki se comprometió en darlo a conocer a pesar de todos los contratiempos que ha podido encontrar y encuentra. Con su respeto al código de ética e inculcando este respeto a todos los practicantes guardando así el bienestar y los intereses del paciente. Logró que en España tengamos el más alto y prestigioso nivel de JSJ de Europa.

Los interesados en conocer más detalles dejen un comentario en esta entrada con un correo electrónico o teléfono de contacto.

Horowitz: Primera Balada de Chopin

2008-03-01T12:48:00.002+01:00

12 años después de no actuar delante del público, el gran Horowitz vuelve a sentarse delante de una audiencia expectante. Finaliza el concierto con la siguiente interpretación:

La otra Galicia

2008-02-21T15:17:00.003+01:00

Desde luego, qué cosas descubre uno leyendo a Paul Auster (El libro de las ilusiones, qué bueno):

http://es.wikipedia.org/wiki/Galicia_(Europa_Central)

A modo resumido: antigua provincia de Polonia, actualmente dividida entre Polonia y Ucrania. En español se le llama "Galitzia", simplemente para diferenciarla da nosa Galicia.

FAQ: BOINC - GridRepublic

2008-01-18T09:41:00.000+01:00

¿Qué es el volunteer computing?

La computación voluntaria se basa en que los recursos de computación para un proyecto dado son proporcionados por usuarios de Internet, de forma voluntaria. Dichos usuarios instalan en sus PCs, servidores, etc. una pequeña aplicación cliente que se encargará de conectarse a los proyectos en los que hayamos decidido participar, descargándose los ficheros (ejecutables, datos de entrada, etc.) necesarios. Si el número de usuarios colaboradores es elevado, la potencia de computación conseguida puede ser realmente impresionante. Ello permite que proyectos que llevarían cientos o miles de años en un único ordenador se completen en un tiempo mucho más reducido. Además, el coste que todo esto supone para los responsables del proyecto es nulo. Aquéllos proyectos que despierten el interés del público contarán con un gran apoyo y, por tanto, con una mayor potencia de computación.

¿Qué es BOINC?

BOINC es una plataforma software que proporciona los medios necesarios para crear un proyecto basado en el volunteer computing. Desarrollado por la Universidad de Berkley a partir del primer proyecto de este tipo de la historia, SETI@home, que trata de descubrir vida inteligente en otros planetas analizando las radiaciones cósmicas que llegan a la tierra continuamente. Hoy en día BOINC es utilizado por multitud de proyectos

¿Qué es GridRepublic?

Se trata de un administrador de cuentas para proyectos BOINC. Utilizando directamente el cliente de BOINC, el usuario tiene que darse de alta y vincularse a cada proyecto en el que quiera participar, de uno en uno. Grid Republic ofrece una interfaz unificada, en la cual basta con crear una cuenta y marcar todos los proyectos en los que queremos participar. El proceso de instalación es muy sencillo y está descrito en esta entrada anterior.

¿Es necesario estar permanentemente conectado a Internet?

En absoluto, basta con conectarse de vez en cuando (todos los días, 1 vez cada 3 días, una vez a la semana...). La aplicación cliente (el programilla que se ejecuta en nuestro ordenador) aprovecha cuando se establece una conexión para descargar "tareas" a realizar del servidor y para informar de los resultados que ya haya obtenido.

Y si me paso un mes sin conectarme... ¿qué pasa?

Cada tarea tiene un plazo determinado para informar al servidor del resultado, entre 3 y 8 días normalmente (depende de cada cuánto tiempo nos conectemos, información que tiene en cuenta la aplicación cliente para descargarse tareas que tengan un plazo de entrega de resultados suficientemente alto para nuestras costumbres de conexión). Si pasa mucho tiempo desde la última conexión lo que ocurrirá, probablemente, es que las tareas ejecutadas se descartarán (los archivos que se descargaron con esa tarea serán borrados del disco) y se volverán a bajar unas tareas nuevas del servidor. Esto no significa que esas tareas hayan estado "paradas un mes por nuestra culpa". Si llega el plazo de entrega y el servidor no tiene todos los resultados que necesita inmediatamente enviará las tareas pendientes a otro usuario para que las realize.

¿Se puede instalar GridRepublic / BOINC si se dispone de una conexión muy lenta a Internet, tipo módem?

Se puede hacer y el sistema funcionará sin complicaciones. El único inconveniente es que, muy probablemente, mientras se descargan tareas nuevas la conexión estará "saturada" y si intentamos navegar por Internet al mismo tiempo notaremos que todo va muy lento. Lo mejor es esperar a que el programa acabe de descargar las tareas pendientes (se puede ver qué está haciendo el programa yendo a la "Advanced View" en la pestaña de "Mensajes") y después comenzar la navegación.

En cualquier caso, el programa tiene una opción accesible pinchando con el botón derecho del ratón en el icono de la barra de tareas, que permite "pausar" o "dormitar" la aplicación, de forma que podemos pararla mientras navegamos por internet, si notamos que nos está "molestando". Eso sí, en algún momento tendremos que dejarle algo "de conexión" para que se pueda descargar las tareas nuevas, informar de resultados, etc.

Para quien quiera currárselo un poco más, puede usar los parámetros Maximun download rate y Maximum upload rate (a 0 indica "ilimitado") accesibles en mi caso desde el menú de la vista avanzada, en Avanzado->Preferences->Uso de la red.

¿Existe riesgo de infección por virus al usar este sistema?

Existe el mismo riesgo que cuando nos descargamos un programa de Google, el programa "PADRE" de la AEAT (Agencia Española de Administración Tributaria), etc. Es decir, muy bajo o nulo. Si nos descargamos un ejecutable de algún sitio y lo ejecutamos será porque confiamos en ese sitio (Google, Microsoft, AEAT, etc.). Los ejecutables que nos descargamos al ejecutar el sistema BOINC en nuestro ordenador serán, además del mismo BOINC, los de cada proyecto en el que participemos. Dichos proyectos pertenecen a entidades de renombre como el Ontario Cancer Research Institute, la Universidad de Berkley, la de Nueva York, etc. Por lo que parece "prudente" creer que dichas entidades se dedican a cosas más serias que a la propagación de virus. Por otro lado, aunque un hacker consiguiera entrar en el servidor de un proyecto dado y quisiera cambiar los ejecutables albergados en ese servidor por otros infectados, el propio sistema BOINC detectaría que dichos programas han sido cambiados y proceden de una fuente no fiable (los ejecutables de cada proyecto se firman utilizando técnicas de criptografía y firma digital) y no serían descargados a nuestro ordenador.

Sun compra Mysql

2008-01-16T18:03:00.000+01:00

Después de esta noticia, quién sabe, hasta puede que el driver JDBC de MySQL empiece a soportar el fetchSize :)

Instalar BOINC en Ubuntu

2008-01-07T15:31:00.000+01:00

Los chicos de http://www.gridrepublic.org todavía no disponen de una versión de su aplicación cliente para linux. Pero eso no supone mayor problema. Para poder formar parte del volunteer computing desde linux tendremos que crearnos una cuenta en gridrepublic.org, tal y como se describe en los primeros pasos de esta entrada (pasos 1-6), y después instalarnos la aplicación cliente de BOINC en Linux.

En esta entrada describo cómo instalar dicha aplicación en una distribución Ubuntu u otra basada en Ubuntu (como, por ejemplo, Guadalinex). Los pasos a dar son los siguientes_

1) Abrir una "línea de comandos" o "terminal de trabajo" (normalmente Aplicaciones -> Accesorios -> Terminal)

2) Introducir el siguiente comando: sudo apt-get install boinc-client boinc-manager. Este comando nos pedirá la contraseña (passwd) del usuario administrador (root). Si no se conoce preguntar al responsable del equipo.

3) En algunas ocasiones, durante la ejecución del comando anterior, el sistema nos preguntará si queremos instalar los paquetes seleccionados. Evidentemente debemos decirle que sí.

4) Las líneas finales de la ejecución del comando anterior deben ser similares a estas:

Configurando boinc-client (5.8.17-2build1~feisty1) ...
* Starting BOINC core client: boinc_client ...done.

Configurando boinc-manager (5.8.17-2build1~feisty1) ...

5) Ahora configuramos el BOINC para que se vincule a nuestra cuenta de GridRepublic. Para ello ejecutamos el comando "boincmgr" (en la línea de comandos). Con ello arrancaremos el interfaz gráfico del gestor (manager) del BOINC. Al ser la primera vez que se ejecuta, veremos una pantalla en la que se nos invita a unirnos a algún proyecto:

6) Debemos cancelar dicho asistente pulsando "Cancelar" (nos pide una confirmación de la cancelación). El aspecto de la aplicación después de cancelar dicho asistente será:

7) Ahora debemos pasar a la vista "Advanced" por lo que haremos click con el ratón en el botón "Advanced View". El aspecto de la aplicación ahora será:

8) Ahora, en el menú "Herramientas", seleccionaremos la opción "Unirse a un administrador de cuentas...". Esto nos llevará al siguiente asistente:

9) Pulsando "Siguiente" obtenemos:

10) En el campo "URL del Administrador de Cuentas" debemos introducir la siguiente URL:

http://www.gridrepublic.org/

Pulsando "Siguiente" veremos como, durante un rato, la aplicación está estableciendo la conexión con el servidor de gridrepublic.org:

11) Después de dicha pantalla aparecerá la siguiente:

12) Aquí debemos introducir el correo electrónico y la clave que utilizamos al crear nuestra cuenta en gridrepublic.org y pulsar "Siguiente". De nuevo, aparece una pantalla en la que se ve cómo la aplicación se está comunicando con el servidor. Finalmente aparecerá la siguiente pantalla:

13) Pulsamos "Finalizar" con lo que se cerrará el asistente y volveremos a la pantalla inicial de la aplicación. En esta ocasión, probablemente, ya veamos una lista de tareas pendientes de ser ejecutadas. Esto es, ya tenemos nuestro ordenador colaborando con los proyectos de nuestra cuenta de gridrepublic.org:

Por otro lado, no tenemos que preocuparnos de iniciar esta aplicación manualmente cada vez que se encienda el ordenador, puesto que durante la instalación (comando apt-get install), ya se ha configurado para que se inicie automáticamente con el arranque del ordenador.

Dona el tiempo libre de tu ordenador para una buena causa

2007-12-24T15:15:00.000+01:00

Ya que estamos en tiempo de Navidad me gustaría proponeros una buena acción para este nuevo año que se aproxima. Su ejecución tan sólo os requerirá una pequeña inversión de vuestro bien más preciado: vuestro tiempo. Pero os garantizo que la inversión será mínima y que el resultado merecerá la pena.

En una entrada anterior os hablé del volunteer computing. En esta ocasión os indicaré lo sencillo que es conseguir que el tiempo libre de vuestro ordenador sea usado de forma efectiva en investigaciones que intentan luchar contra enfermedades como el cáncer, el SIDA o la malaria.

Como os comenté en dicha entrada, el sistema BOINC es usado por multitud de proyectos (medicina, física, matemáticas, etc.) en la actualidad. Instalarse la aplicación (el "cliente" de BOINC) que permite a cualquier persona participar en dichos proyectos y suscribirse después a los proyectos que nos interesen puede ser un poco tedioso. Por eso os recomiendo que useis el siguiente portal:

http://www.gridrepublic.org/

Dicha web nos ofrece un punto de entrada único y sencillo para crear una cuenta de usuario y elegir aquéllos proyectos que más nos interesen de entre una lista siempre actualizada. En menos de dos minutos tendréis vuestro ordenador configurado para contribuir sus ciclos de CPU a las investigaciones más punteras y humanitarias del planeta.

PASOS A SEGUIR:

Entrar en http://www.gridrepublic.org/y pulsar "Join"

Introducir los datos de la cuenta. Podemos poner cualquier cosa en Name y Password. La E-mail Address debería ser (aunque no es necesario) nuestra dirección de correo habitual (nota: el Password introducido no tiene que ser la contraseña de vuestro correo electrónico!! podeis inventaros uno cualquiera) y pulsar "Continue"

Obtendremos la lista con los proyectos disponibles. Por desgracia, la descripción de cada proyecto sólo está disponible en inglés de momento (más adelante la esta web será multi-idioma).

Si en el campo donde pone "All Projects" seleccionamos, por ejemplo, Biology/Medicine (estos son los proyectos que yo recomiendo, cada uno que eliga libremente), y seleccionamos todos los proyectos que aparecen (Rosetta@home, etc.) (el de Proteins@Home no los marcamos porque da problemas), teniendo en cuenta que el proyecto "World Community Grid" consta a su vez de varios proyectos que también seleccionaremos, deberíamos tener la siguiente pantalla como resultado

Pulsando el botón "Continue" nos saldrá la siguiente página en la que se nos pide que aceptemos la licencia de World Community Grid

Pulsando "Accept" nos saldrá una página que dice:

Please note: World Community Grid will be sending you an email...

Pulsando "Continue" llegaremos a la página final, donde aparece un botón de "Download" para bajarnos la aplicación cliente que se ejecutará en nuestro ordenador de forma continua
Ahora debemos pulsar en "Download" y guardar el archivo en nuestro ordenador. Cuando la descarga haya finalizado deberemos ejecutar dicho archivo (GridRepublicSetup.exe). Al ejecutarlo nos saldrá el típico diálogo de instalación de un programa windows. Ya sabéis, se le dice a todo que sí y palante. La pantalla final debería ser:

Una vez que pulsamos "Next" la aplicación se ejecutará y podremos ver una ventana en el modo llamado "Simple View". Además, el programa se ha añadido al menú de Inicio, de forma que siempre se ejecutará al iniciar sesión en windows. Si cerramos la ventana (pulsando en la "X") la ventana se cerrará, pero la aplicación sigue ejecutándose en segundo plano. Podemos abrir de nuevo la ventana haciendo doble click en el icono situado alado del reloj, en la barra de herramientas.

En mi caso, cuando abro la ventana del GridRepublic Desktop mi aplicación tiene el siguiente aspecto:
Podemos observar que actualmente estoy participando en el proyecto "MalariaControl". Lo que realmente ocurre es que estoy ejecutando una "work unit" de ese proyecto, esto es, un trozo de dicho proyecto. Mi ordenador lleva 26 minutos dedicados a esa work unit y todavía le faltan 1 hora y 12 minutos para acabarla. Cuando eso ocurra, de forma automática la aplicación pasará a ejecutar otra work unit pero de otro proyecto disinto. Es decir, mi ordenador participa de forma equitativa en todos los proyectos a los cuales estoy suscrito.

Desde aquí os animo a que participeis en estos proyectos humanitarios (todos pertenecen a instituciones sin ánimo de lucro y los resultados son publicados al resto de la comunidad científica) y a que animéis a vuestros amigos, familiares, compañeros de trabajo, etc. a que también lo hagan.

Comentad en este blog cualquier problema o duda que tengáis durante la instalación o ejecución del programa.

Grid-Volunteer Computing: BOINC

2007-12-23T15:46:00.000+01:00

Muchos de vosotros conoceréis el famoso proyecto SETI@home, en el cual personas de todo el mundo "donaban" el tiempo libre de sus PCs para analizar las señales de radio provenientes del espacio en busca de vida inteligente en otros planetas.

El software de dicho proyecto ha evolucionado para convertirse en una plataforma de computación distribuida genérica llamada BOINC, que permite crear proyectos similares al SETI@home. El potencial del llamado volunteer computing es impresionante. Teniendo en cuenta los siguientes factores:

una gran parte del tiempo nuestro ordenador (el de casa o el del trabajo) no lo estamos usando
cuando lo usamos, normalmente no utilizamos el 100% de sus recursos (CPU, memoria)
la potencia de los ordenadores personales es cada año mucho mayor
el número de ordenadores personales en el mundo es cada año mayor

podemos entender resultados tan sorprendentes como, por ejemplo, que el proyecto Help Defeat the Cancer, lanzado el 20 de Julio de 2006 y completado en Abril de 2007, utilizó un tiempo de procesamiento total equivalente de 2909 años, 260 días, 10 horas, 43 minutos y 29 segundos. Es decir, si el proyecto se hubiese ejecutado en un único ordenador, hubiese tardado casi 3,000 años en vez de nueve meses. ¿No está mal verdad?

Las posibilidades que esta tecnología nos brinda son inmensas. Antes, a menudo, un investigador tenía que descartar de antemano la ejecución de una simulación o un análisis determinado debido a que llevaría "miles de años" ejecutarlo. Con la computación distribuida y, en el caso de la computación voluntaria, con coste cero, muchos de dichos procesos pueden llevarse a cabo, con lo que los planteamientos iniciales de una línea de investigación dada pueden cambiar radicalmente.

Además, el hecho de que cada usuario decida de forma individual en qué proyectos quiere participar, hace que este sistema adquiera un tinte "democrático": son los usuarios quienes deciden a qué proyectos dan su apoyo. Por ejemplo, un proyecto que investigue las proteínas en busca de nuevos medicamentos para el cáncer es probable que tenga mucho mayor apoyo que un proyecto que busque la forma de aumentar la potencia de las armas atómicas.

Los proyectos ejecutados con este sistema suelen pertenecer a disciplinas tales como la astronomía, física, química, biología, medicina, matemáticas, etc.

En la siguiente página podemos ver una lista de algunos de los proyectos que utilizan BOINC:

http://boinc.berkeley.edu/projects.php

Otros proyectos que usan BOINC pertenecientes al sistema World Community Grid:

http://www.worldcommunitygrid.org/projects_showcase/viewResearch.do

Es muy probable que este novedoso paradigma de computación crezca cada año de forma que un mayor número de instituciones (universidades, centros de investigación, etc.) se beneficie de sus ventajas.

La Mula debería usar HTTP GET para descargarse el WSDL

2007-09-29T23:54:00.000+02:00

No tiene mucho sentido utilizar HTTP POST para acceder al WSDL de un servicio web dado, verdad?

http://mule.mulesource.org/jira/browse/MULE-2460

WFetch

2007-09-25T18:04:00.000+02:00

Esta herramienta, originalmente diseñada para testear servidores ISS Microsoft, es realmente útil para testear manualmente cualquier tipo de servidor HTTP, pemitiendo generar todo tipo de peticiones de forma visual y sencilla:

WFetch 1.4

PD: Sí emilio, estoy usando windows, esto de trabajar con equipos del cliente es lo que tiene :P

Control de flujo en JMS

2007-09-15T01:11:00.000+02:00

Como en cualquier proceso de comunicación, si un productor genera información de forma más rápida que un consumidor podemos tener problemas como pérdida de mensajes, bloqueos, etc.

El mecanismo por excelencia para coordinar las tasas de productores y consumidores de información a nivel de protocolo es el llamado control de flujo. El caso más típico es el del protocolo TCP, que proporciona dicho control empleando una ventana de transmisión y con mecanismos tales como el slow start, congestion avoidance, fast retransmit, etc.

JMS, el estándar de mensajería de java ee, no define ningún mecanismo de control de flujo a nivel de estándar. De todas formas, ciertos proveedores sí que proporcionan dicha funcionalidad de forma propietaria:

Como unir ficheros en windows sin el hacha

2007-09-08T21:34:00.000+02:00

Nada más fácil. Desde la consola:

COPY /B fichero.1+fichero.2+fichero.3... /B fichero

Buscando en el JNDI de Glassfish

2007-07-23T11:29:00.000+02:00

Me ha llevado un buen rato, así que os lo cuento por si os sirve para ahorraros unos minutillos dando vueltas por la web: para poder acceder al contexto JNDI del Glassfish desde una JVM distinta (local o remota) debeis utilizar las siguientes propiedades:

Properties props = new Properties();
props.setProperty("java.naming.factory.initial", "com.sun.jndi.cosnaming.CNCtxFactory");
props.setProperty("org.omg.CORBA.ORBInitialHost","localhost");
props.setProperty("org.omg.CORBA.ORBInitialPort","3700");
InitialContext ic = new InitialContext(props);

Por supuesto, este código no será portable para su ejecución contra otro servidor de aplicaciones. Si os preocupa la portabilidad un fichero jndi.properties con las propiedades anteriores facilitará la migración en un futuro.

Versión usada: Sun Java System Application Server 9.1 (build b50g-beta3) = Glassfish v2 beta 3

Saludos.

Uniendo JSF y EJB 3.0: Seam

2007-05-31T12:56:00.000+02:00

Buscando la forma de unir el mundo JSF y el mundo EJB 3.0 he descubierto que Seam es la tecnología ideal para ese fin. Este artículo explica perfectamente por qué:

http://www.itarchitect.co.uk/articles/display.asp?id=251

Struts vs. JSF

2007-05-24T10:56:00.000+02:00

En una arquitectura típica de tres capas tenemos varias opciones para la capa de presentación: jsf, webwork, tapestry, struts, spring mvc...

La opción más extendida a día de hoy es Struts, aunque JSF cada vez está cogiendo más fuerza. Hoy he mantenido una conversación interesante en el canal #jsf de freenode con Ken Paulsen creador del framework JSFTemplating, quien me comentó las siguientes ventajas de JSF:

El soporte de JSF en IDEs como Eclipse, Netbeans, etc. es mucho mejor
Constantemente se crean nuevos componentes JSF
Gran soporte de JSF en la industria
JSF es parte de Java EE (Struts no)
Todos los servidores de aplicaciones, por tanto, incluyen JSF
Tendencias

Finalmente, para sacar la máxima productividad posible de JSF, Ken me recomendó que empezara echándole un vistazo a Facelets o a JSFTemplating.

Más tarde, Joseph Ottinger (editor the TheServerSide) me recomendó el siguiente thread:

http://www.theserverside.com/news/thread.tss?thread_id=45519

Es una discusión muy interesante, en la que se lanzan opiniones de todo tipo, a favor y en contra the JSF. Algunas ideas que parecen compartir muchos de los participantes:

El diseño de Struts es horrible (aunque en su momento era mejor que nada)
Usar JSP como rendering engine es una de las principales causas de las críticas a JSF. Es mucho más productivo usar Facelets.

Balanceo de Carga del JMS de Glassfish != Round Robin

2007-05-18T14:35:00.000+02:00

Haciendo pruebas con el proveedor JMS de Glassfish, usando dos consumidores en una misma Queue para comprobar cómo se producía el balanceo de carga observé un peculiar comportamiento: bajo ciertas condiciones sólo uno de los consumidores recibía los mensajes enviados.

Mi primera impresión fue que se trataba de un bug, pues esperaba que el algoritmo de balanceo de carga fuera round-robin.

Finalmente, gracias a la estupenda comunidad que hay detrás de Glassfish, descubrí que realmente dicho comportamiento no era un bug, si no el resultado de un algoritmo de balanceo de carga mucho más inteligente.

Si quereis ver los detalles del asunto:

http://forums.java.net/jive/thread.jspa?messageID=216950

Glassfish y JMS: más de un consumidor en una cola

2007-05-15T10:29:00.000+02:00

JMS es una tecnología realmente interesante que todos deberíamos conocer e incorporar a nuestro maletín de herramientas. En está página podeis encontrar varios links interesantes:

http://vossnet.org/jms-links.html

En mi empresa estamos probando Glassfish con su proveedor JMS por defecto (SJSMQ) y nos llevamos una pequeña sorpresilla cuando intentamos configurar más de un consumidor en una misma cola. En el log del servidor nos encontrábamos con el siguiente mensaje:

[#|2007-05-14T17:00:04.597+0200|WARNING|sun-appserver-pe9.0|javax.enterprise.system.stream.err|_ThreadID=15;_ThreadName=Thread-jms[6];_RequestID=b9d1fdf3-bd50-4328-8798-7fc80308e559;|[14/may/2007:17:00:04 CEST] WARNING [B2009]: Creation of consumer from connection guest@192.168.0.18:32883 on destination QMultipleConsumers failed:
com.sun.messaging.jmq.jmsserver.util.BrokerException: [B4182]: Consumer can not be added to destination QMultipleConsumers [Queue], limit of 1 consumers would be exceeded

Después de investigar un poco llegué a

https://glassfish.dev.java.net/javaee5/docs/AG/abljw.html

donde leemos:

maxNumActiveConsumers -> The maximum number of consumers that can be active in load-balanced delivery from a queue destination. A value of -1 means an unlimited number. The default is1. (Platform Edition limits this value to 2.)

Entonces, tratamos de modificar esa propiedad usando la consola del Glassfish, pero ello producía el siguiente error:

java.lang.Exception: MBean DestinationManagerConfig: Problem encountered while invoking operation create: com.sun.messaging.jmq.jmsserver.util.BrokerException: Unable to set/update attributes destination: QMultipleConsumers, because [B4180]: Support for feature [B0050]: More than 2 Primary Consumers on a Destination is unavailable on destination QMultipleConsumers [Queue], please upgrade to the Enterprise Edition to enable this feature

Finalmente, tras investigar un poco en el IRC, donde comprobamos que había gente usando colas con varios consumidores sin problemas, decidimos bajarnos la última build del Glassfish (v2-b41d) y... tachán!, problema solucionado.

Ya se sabe, esto de actualizar la versión suele dar resultados... :)

Escuchar en el mismo puerto desde distintas ip's

2007-05-11T17:57:00.000+02:00

¿Sabíais que podemos tener varios procesos en uina máquina Linux escuchando el mismo puerto? El truco está en usar una ip distinta para cada proceso. Por ejemplo, si ejecutamos:

#ifconfig eht0:0 192.168.1.1
#ifconfig eht0:1 192.168.1.2

tendremos dos ip's virtuales, a parte de la que ya tenga la máquina.

Si ejecutamos el siguiente código java:

---------------------------------------------------------------------
InetAddress ip1 = InetAddress.getByName("192.168.1.1");
InetAddress ip2 = InetAddress.getByName("192.168.1.2");

ServerSocket ss1 = new ServerSocket(14000,0,ip1);
ServerSocket ss2 = new ServerSocket(14000,0,ip2);

Thread.sleep(12000);
System.exit(0);
---------------------------------------------------------------------

Tendremos dos servidores escuchando en el puerto 14000, cada uno en una
ip distinta. Podemos ejecutar en una consola:

#telnet 192.168.1.1 14000
Trying 192.168.0.211...
Connected to 192.168.0.211.
Escape character is '^]'.

y en otra consola:
#telnet 192.168.1.2 14000
Trying 192.168.0.211...
Connected to 192.168.0.211.
Escape character is '^]'.

También he probado a arrancar dos mysql's sobre el mismo puerto y
distinta ip virtual y funciona.

Cómo sacar todas las líneas de un log a partir de cierta hora

2007-05-11T17:50:00.000+02:00

Pues muy fácil (en Linux):

~# cat x.log | awk '{ if ($3>"16:46:00") print $0}'
DEBUG 2006-02-14 16:46:04,408 [http-64.91.4.78-91-Processor21] etc.
DEBUG 2006-02-14 16:46:08,559 [http-64.91.4.78-91-Processor11] etc.
DEBUG 2006-02-14 16:46:15,087 [http-64.91.4.78-91-Processor11] etc.

Cambio de look

2007-05-02T20:18:00.000+02:00

Bueno, parece que está de moda esto de subir los cambios de look al blog, así que ahí va el antes y el despues de mi último corte de pelo :)

Antes:

Despues:

nota: solo se admiten piropos :P

Groovy fix: Thread.setDefaultUncaughtExceptionHandler

2007-04-27T17:40:00.000+02:00

Perfecto! Ya podemos controlar las excepciones no capturadas en Groovy con Thread.setDefaultUncaughtExceptionHandler:

http://jira.codehaus.org/browse/GROOVY-1788

Viva la comunidad open source (¿cuántas veces he dicho esto ya?).

Google usa Hibernate

2007-04-17T17:00:00.000+02:00

En una entrada anterior defendí el empleo de los ORM's.

Hoy me llevé una pequeña sorpresilla al descubrir que ni más ni menos que Google usa Hibernate. De hecho han contribuido a su desarrollo recientemente:

http://www.infoq.com/news/2007/03/hibernate-shards

¿Si Google lo usa no será tan malo verdad? ;)

Grails RFE

2007-02-28T10:15:00.000+01:00

Genial! los chicos de Grails han implementado la RFE ("Request For Enhacement") que propuse hace un par de meses:

http://jira.codehaus.org/browse/GRAILS-520

Una vez más, tres puntos para el modelo de desarrollo del mundo open source. Si alguien conoce algún producto propietario con este nivel de interactividad entre usuarios/desarrolladores que me lo cuente... :)

Java Web Start: una opción interesante

2007-02-06T10:28:00.000+01:00

A día de hoy, cuando un programador debe desarrollar una nueva aplicación debe decidir, entre otras cosas, qué tipo de aplicación realizará: web o de escritorio. En el caso de java tenemos multitud de opciones a la hora de implementar una aplicación web: J2EE, Spring, JSF, Struts, ... las opciones son inmensas. En el caso de la aplicación de escritorio el abanico de opciones es más reducido: Swing o SWT, básicamente.

Las ventajas de las aplicaciones web son evidentes: son fácilmente distribuibles, su instalación y actualizaciones están centralizadas en un único punto (el servidor), etc. En cambio, el grado de interactividad que se puede lograr con el usuario quizá esté más limitado que en una aplicación de escritorio.

Bien, imaginemos que estamos cómodos programando en Swing, y que tenemos que desarrollar una aplicación corporativa dentro de nuestra empresa (para uso interno, vamos). El tener que instalar la aplicación en cada puesto cliente es un tanto tedioso. Y no hablemos de las actualizaciones. ¿No podríamos instalar la aplicación en un único sitio, de forma que todos los clientes usaran siempre la misma versión, y de forma que cada vez que queramos actualizarla baste con hacerlo en un único punto? Pues sí podemos, usando Java Web Start.

Y, no creais, no requiere mucho esfuerzo. Lo único que necesitamos es un servidor web y dar un toque personal a nuestra aplicación, "firmándola". En realidad sólo necesitamos firmar la aplicación si ésta necesita acceder a disco, abrir conexiones de red a otros servidores etc. Otra posibilidad implica utilizar la API que el JWS proporciona para acceder a los recusos de la máquina cliente, pero esta opción es más compleja y limitada. Mi recomendación es firmar la aplicación y solicitar el acceso total a los recursos de la máquina cliente, como veremos más adelante (el cliente deberá conceder dicho acceso, pues java mostrará un diálogo preguntando si "confía" en la firma mostrada).

No voy a describir Java Web Start en sí. La siguiente guía de Sun es bastante completa:

http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/contents.html

Lo que haré será describir concisamente los pasos necesarios para distribuir una aplicación Swing mediante JWS. La aplicación de este ejemplo se desarrollará con Netbeans 5.5, Hibernate 3.2, MySQL 5.0 y Tomcat 5.5, aunque el método sería muy similar para cualquier otro entorno de desarrollo. Al estar creado con "Matisse" (el magnífico asistente para crear GUIs en el Netbeans) y al utilizar Hibernate y MySQL, el directorio "dist" del proyecto presenta la siguiente estructura:

Efectivamente, nuestra aplicación depende de una serie de librerías. Por tanto, para poder ejecutarla vía JWS necesitamos firmar no solo el archivo ParrillaTeleventa.jar, sino todos los archivos JAR de las citadas librerías. Para ello usamos la tarea (task) signjar del ANT. Deberemos crear un par de claves (en este post anterior describo como crear una keystore) y modificar el fichero build.xml del proyecto de la siguiente forma:

Pero... si intentamos firmar las librerías directamente obtendremos una pequeña sorpresilla:

Efectivamente, ciertas librerías ya están firmadas, pero no con nuestra firma, si no con la de su distribuidor. Para poder aplicarles nuestra firma debemos antes "borrar" la firma original. A día de hoy no existe (yo no la he encontrado, al menos) ninguna tarea del ANT o similar para "desfirmar" (unsign) archivos JAR, o para sobreescribir la firma. Pero dado que un archivo JAR no es más que un ZIP con una cierta estructura de directorios podemos eliminar las firmas originales manualmente, descomprimiendo cada librería, eliminando los archivos de tipo *.DSA, *.SF o *.RSA que conforman la firma, y volviendo a comprimirlo. El siguiente script nos ayudará a automatizar el proceso:

unsignjars.sh

#!/bin/bash

TMPDIR=unsignTmpDir
JAR=/usr/local/java/bin/jar
for i in *.jar
do
mkdir $TMPDIR
mv $i $TMPDIR
cd $TMPDIR
jar xf $i
rm -f $i
rm -f META-INF/{*.DSA,*.SF,*.RSA}
jar cf $i .
mv $i ..
cd ..
rm -rf $TMPDIR
done

Una vez eliminada la firma original de las librerías ya podemos firmar todos los componentes (*.jar) de nuestra aplicación.

Ahora sólo resta crear un descriptor JNLP de nuestra aplicación, que no es más que un fichero xml. En nuestro caso, su contenido podría ser:

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="0.2 1.0"
codebase="http://192.168.0.10:8084/ServiciosInternos/parrillateleventa/"
href="parrillateleventa.jnlp">
<information>
<title>Parrilla Televenta 1.0</title>
<vendor>Acme S.L.</vendor>
<description>Sistema de Planificación de las Campañas del Departamento de Televenta</description>
<description kind="short">Planificador de Campañas</description>
<offline-allowed/>
</information>
<resources>
<j2se version="1.5"/>
<jar href="ParrillaTeleventa.jar" main="true" download="eager"/>
<jar href="lib/Generales.jar" download="eager"/>
<jar href="lib/activation.jar" download="eager"/>
<jar href="lib/antlr-2.7.6.jar" download="eager"/>
<jar href="lib/asm.jar" download="eager"/>
<jar href="lib/asm-attrs.jar" download="eager"/>
<jar href="lib/cglib-2.1.3.jar" download="eager"/>
<jar href="lib/commons-collections-2.1.1.jar" download="eager"/>
<jar href="lib/commons-logging-1.0.4.jar" download="eager"/>
<jar href="lib/dom4j-1.6.1.jar" download="eager"/>
<jar href="lib/hibernate3.jar" download="eager"/>
<jar href="lib/jta.jar" download="eager"/>
<jar href="lib/log4j-1.2.11.jar" download="eager"/>
<jar href="lib/mail.jar" download="eager"/>
<jar href="lib/mysql-connector-java-3.1.10-bin.jar" download="eager"/>
<jar href="lib/swing-layout-1.0.1.jar" download="eager"/>
<jar href="lib/xerces-2.6.2.jar" download="eager"/>
</resources>
<application-desc main-class="com.acme.televenta.rejillateleventa.Main"/>
<security>
<all-permissions/>
</security>
</jnlp>

La sintaxis de este fichero puede consultarse en

http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html

Y ya estamos listos para desplegar nuestra aplicación en el Tomcat. La forma más sencilla de hacer esto es creando un archivo WAR, en el que se incluiría nuestra aplicación, sus librerías, el descriptor JNLP y una página web de presentación. Veamos el aspecto de dicha página:

En la página de presentación hemos incluido un mensaje informando de la necesidad de tener java instalado, lo cual siempre es conveniente pues la máquina cliente puede que no tenga java.

Si pinchamos en el enlace mostrado (es un enlace al archivo .jnlp) observaremos la siguiente ventana:

Finalmente nos aparecerá un diálogo informando de que la firma no se puede verificar. Simplemente pinchamos en la opción "confiar siempre en el contenido de este editor" y pulsamos "Ejecutar". La maravillosa Parrilla aparecerá entonces en nuestra pantalla, ejecutándose localmente, como si se hubiera instalado manualmente en la máquina cliente.

Feliz distribución de aplicaciones de escritorio! :)

Logueando tráfico https...

2007-01-31T17:26:00.000+01:00

En ocasiones es útil monitorizar el tráfico TCP a bajo nivel para investigar problemas de conexión con un servidor dado.

En principio, con la herramienta tcpdump (disponible en todos los Linux que conozco) podríamos capturar todo el tráfico en distintos logs diarios invocando el siguiente script desde el cron diariamente:


#!/bin/bash

LOG_FILE_BASE=/home/andres/tcpdata
LOG_FILE=$LOG_FILE_BASE.`date +%Y%m%d`.log
FILTRO='port 80'
killall tcpdump > /dev/null 2>&1

if [ $UID -ne 0 ]
then
echo "Debes ejecutar el script como root."
exit 1
fi

echo "*************************" >> $LOG_FILE
echo "** `date +\'%Y%m%d %T\'`" >> $LOG_FILE
echo "*************************" >> $LOG_FILE

# el ">/dev/null 2>&1" es necesario para que el proceso
# que queda en segundo plano no mantenga "file descriptors"
# abiertos (sino, al llamarse desde el crond, daria como
# resultado un proceso zombie)

/usr/sbin/tcpdump -n -s0 -w $LOG_FILE $FILTRO  >/dev/null 2>&1 &

pero..., ¿qué pasa si el servidor está configurado con HTTPS en vez de con HTTP?, pues que el tráfico TCP estará encriptado, por lo que deberemos descifrarlo para poder entender su contenido.

Una fácil solución pasa por usar la herramienta ssldump.

Imaginemos que tenemos un tomcat configurado con https. Para usar ssldump debemos obtener la clave privada del servidor. Para ello recomiendo usar la clase ExportPriv.java descrita en

http://mark.foster.cc/kb/openssl-keytool.html

Con la clave privada del tomcat guardada en un fichero (¡con los permisos de lectura restringidos por supuesto!) .tomcat.pem el siguiente script logueará el tráfico de forma descifrada:


#!/bin/bash

DUMP_FILE=/home/andres/ssl.dump
PRIVATE_KEY=/home/andres/.tomcat.pem
LOG_FILE_BASE=/home/andres/ssldump_log
killall tcpdump > /dev/null 2>&1

if [ $UID -ne 0 ]
then
  echo "Debes ejecutar el script como root."
  exit 1
fi

LOG_FILE=$LOG_FILE_BASE.`date +%Y%m%d`.log

if [ -f $DUMP_FILE ]
then
   echo "*************************" >> $LOG_FILE
   echo "** `date +\'%Y%m%d %T\'`" >> $LOG_FILE
   echo "*************************" >> $LOG_FILE


   /usr/local/sbin/ssldump -d -k $PRIVATE_KEY -A -X -q -r $DUMP_FILE \\
   >> $LOG_FILE
fi

# el ">/dev/null 2>&1" es necesario para que el proceso
# que queda en segundo plano no mantenga "file descriptors"
# abiertos (sino, al llamarse desde el crond, daria como
# resultado un proceso zombie)

/usr/sbin/tcpdump -n -s0 -w $DUMP_FILE port 443 >/dev/null 2>&1 &

Feliz monitorización :)

HttpUnit (y 3): problemas con la codificación (UTF-8 vs. ISO-8859-1)

2007-01-19T11:54:00.000+01:00

¿Quién no ha experimentado alguna vez el placer de tener problemas con los famosos charsets o codificaciones del texto?

En este caso, nuestro viejo amigo HttpUnit tampoco se libra de ello. En el siguiente mail de la lista de desarrollo describo el problema en sí.

La cuestión es que necesitaba una solución urgente así que, en vez de esperar a que los desarrolladores oficiales arreglen el problema y saquen una nueva versión (últimamente entre cada release del HttpUnit pasa casi un año) me bajé el código fuente, arreglé el bug, compilé y... listo! Ya tengo mi httpunit-tuneado.jar :)

Conclusión: ¡ viva el open source!. La flexibilidad y fiabilidad del programador al usar este tipo de productos es mucho mayor que al utilizar productos propietarios.

Os animo a todos a que utiliceis productos de código abierto y que no tengais reparos a la hora de bajarse el código fuente y "meterle mano". Se aprende mucho y... !se solucionan los problemas con mayor rápidez!

Hasta otra...

Linux (Ubuntu), firefox y plugin de java

2007-01-09T13:21:00.000+01:00

La verdad, no fue nada sencillo, aunque finalmente lo conseguí: instalar el plugin de java en el firefox 2.0. El comando viene siendo algo así como:


/opt/firefox-2.0/plugins$ ln -s /usr/local/jdk1.6.0/jre/plugin/i386/ns7/libjavaplugin_oji.so

Para comprobar que el plugin está correctamente instalado... ¿cómo hacemos? En el menu del firefox, vemos que nos deja ver los "Add-ons" (Menú "Tools") pero nada de los plugins. Lo que debemos hacer es escribir


  about:plugins

en la barra de direcciones del firefox con lo que obtendremos el siguiente informe:

Parece que ya tenemos java disponible... :)

Groovy: accediendo a la base de datos

2007-01-09T10:50:00.000+01:00

Hace tiempo que los lenguajes dinámicos (Ruby, PHP, Python, etc.) están pegando fuerte. Bajo mi punto de vista son un complemento ideal a lenguajes fuertemente tipados como Java o C#. La principal ventaja es la "agilidad" proporcionada por dichos lenguajes.

Mi opción personal es Groovy, debido a su perfecta integración con Java.

Un ejemplo de agilidad: imaginemos que queremos acceder a una base de datos para hacer un par de consultas, generar un informe y enviarlo por correo electrónico. Una tarea tan sencilla y "aislada" como ésta hace que valores como "terminar la tarea" o "permitir cambios en la implementación de forma inmediata" prevalezcan sobre valores como "reusabilidad del código". En éste caso un lenguaje dinámico interpretado es la mejor opción.

Veamos lo sencillo que es implementar dicha tarea en Groovy:


// Groovy source file
import groovy.sql.Sql
import java.text.SimpleDateFormat

sql = Sql.newInstance("jdbc:mysql://localhost/db", "usuario",
                      "clave", "com.mysql.jdbc.Driver")
fecha = new SimpleDateFormat("dd/MM/yyyy").format(new Date())
INFORME=""

INFORME += "+---------------------------------------------+\n"
INFORME += "| *** INFORME DE ACTIVIDAD DEL ULTIMO MES *** |\n"
INFORME += "+---------------------------------------------+\n"
INFORME += "\n"
INFORME += "Fecha: ${fecha}\n"
INFORME += "\n"

sql.execute("LOCK TABLES MENSAJES READ, COLASALIDA READ")
sql.execute("SELECT @primeroDelMesPasado:=DATE_FORMAT(NOW()-INTERVAL 1 MONTH,'%Y-%m-01')");
sql.execute("SELECT @primeroDelMesActual:=DATE_FORMAT(NOW(),'%Y-%m-01');");
sql.execute("""
  SELECT @OPERADORA1_A:=COUNT(*) FROM MENSAJES
  WHERE idcanal IN (1,3)
  AND fh >= @primeroDelMesPasado
  AND fh <  @primeroDelMesActual
""")
sql.execute("""
  SELECT @OPERADORA1_B:=COUNT(*) FROM EM_COLASALIDA
  WHERE idcanal IN (1,3)
  AND fh >= @primeroDelMesPasado
  AND fh <  @primeroDelMesActual
""")
sql.execute("""
  SELECT @OPERADORA2_A:=COUNT(*) FROM MENSAJES
  WHERE idcanal IN (2,4)
  AND fh >= @primeroDelMesPasado
  AND fh <  @primeroDelMesActual
""")
sql.execute("""
  SELECT @OPERADORA2_B:=COUNT(*) FROM EM_COLASALIDA
  WHERE idcanal IN (2,4)
  AND fh >= @primeroDelMesPasado
  AND fh <  @primeroDelMesActual
""")
sql.execute("UNLOCK TABLES")
sql.eachRow("""
  SELECT CONCAT("OPERADORA1.......: ", @OPERADORA1_A       + @OPERADORA1_B , " msjs.")
  UNION
  SELECT CONCAT("OPERADORA2.......: ", @OPERADORA2_A       + @OPERADORA2_B , " msjs.")
"""){
   INFORME += it[0]+"\n"
}

new AntBuilder().mail(mailhost: 'smtp.miservidor.net', subject: " Informe Mensual ${fecha}") {
  from(address:   'informes@miservidor.net')
     to  (address: 'informes@miservidor.net')
     message( "${INFORME}" )
 }

Finalmente, bastará con añadir las entradas pertinentes en el cron para que dicho script se ejecute periódicamente.

Para modificar la generación del informe bastará con conectarse al servidor y editar el fichero .groovy directamente.

Sencillo ¿verdad?

iconv: Cambiar la codificación de un fichero en linux

2007-01-09T10:41:00.000+01:00

Imaginemos que tenemos un conjunto de ficheros .java codificados en ISO 8859-1 y queremos pasarlos a UTF-8. En linux podemos hacer algo tan sencillo como:

for i in `find -name *.java`
do
iconv -f ISO_8859-1 -t UTF-8 $i > tmpfile
mv -f tmpfile $i
done

HttpUnit (y 2): esa fuga de memoria (memory leak)...

2006-12-22T12:57:00.000+01:00

El concepto de recolector de basura de java tiene muchas ventajas, y algún inconveniente: las fugas de memoria (memory leaks). En java el programador no tiene que preocuparse de liberar la memoria de los objetos creados. Cuando éstos dejan de ser necesarios el recolector libera su memoria automáticamente. El problema es el concepto "ser necesario". Puede que nosotros ya no necesitemos ciertos objetos pero que éstos estén almacenados en alguna colección (ArrayList por ejemplo), por lo que el recolector no los liberará.

Otros lenguajes de programación como C o C++ no tienen este problema, pero claro, ello se debe a que no tienen recolector de basura, por lo que tienen otros problemas mucho mayores (punteros mal gestionados etc.).

Pues bien, en el desarrollo de una aplicación Swing que emplea la librería HttpUnit de la que ya hablé en un post anterior tuve la "suerte" de toparme con una fuga de memoria. Esto se hizo evidente cuando el jconsole me proporcionó la siguiente información:

En ella observamos que el consumo de memoria crece de forma constante e indefinida.

Al intentar analizar cuál podía ser la causa de la fuga en mi cerebro se entabló una lucha interna entre mi orgullo y mi prudencia. El uno decía "está claro, tu código no tiene ningún problema, es culpa de alguna librería". La otra decía "las librerías que estás utilizando las usan muchas otras personas, seguro que el problema es de tu código". Ya sabeis, el típico síndrome de "¿a quién le echamos la culpa?" tan famoso como inútil en la mayoría de los casos ;-)

Después de analizar (sin pararme demasiado tampoco) mi código, parecía que no había cometido ninguno de los típicos errores que favorecen las fugas de memoria, por lo que decidí, adoptando una actitud más positiva y productiva, utilizar una potente herramienta para identificar el culpable (para solucionar el problema, no para señalarle con el dedo, jeje): el increible profiler del NetBeans.

La configuración del profiler usada fue la siguiente:

En ella observamos que he seleccionado la opción que hace que el profiler sólo muestre los objetos que están "vivos" (Record both object creation and garbage collection) en cada momento. Al principio me llevé una pequeña sorpresa cuando observé que el total de memoria total usada por la JVM era mucho mayor que la que el profiler me presentaba en su categorización de uso de la memoria por clases. Preguntando por la razón de esta inconsistencia usando la lista de correo del profiler, Gregg Sporar, un programador veterano de Sun, actualmente "Technical Evagelist" del Netbeans, que conocí en Madrid en los Sun Tech Days de este año y que ya me echó una mano en otra ocasión, me respondió en la lista explicando que el parámetro "Track every 10 obect allocations" hace que el profiler sólo registre el 10% de todos los objetos creados. Esto hace que el profiling no afecte demasiado al rendimiento de la aplicación, aunque dicho 10% normalmente sea más que suficiente para identificar el patrón de fuga de memoria.

En mi caso así fue, tras unas tres horas de ejecución realicé una captura (snapshot) del uso de memoria y obtuve el siguiente resultado:

Claramente el problema se debía a la proliferación de arrays de caracteres. Lo más probable es que se trataran de String's (una String de java usa un char[] internamente para el almacenamiento de los caracteres). Pinchando con el botón derecho del ratón sobre la primera fila de la captura (la de los char[]) y seleccionando la opción Show Allocation Stack Traces, que nos permite ver quién/quienes crearon dichos objetos obtuve la clave del asunto:

El problema estaba en el método

handleScriptException( Exception e, String badScript )

de la clase

com.meterware.httpunit.javascript.JavaScript$JavaScriptEngine

Viendo el código fuente descubrí que el HtppUnit guarda todas las excepciones lanzadas por su intérprete de JavaScript (rhino) en un ArrayList, y que dicho array debe ser "limpiado" manualmente por el usuario de la librería, usando la función

HttpUnitOptions.clearScriptErrorMessages();

Los siguientes pasos fueron inmediatos:

Modificar el código para llamar a dicha función periódicamente
Enviar un correo a la lista httpunit-develop@lists.sourceforge.net comentando este problema.

(El segundo punto es verdaderamente importante para cualquier herramienta open source. Os animo a todos a que, cuando os encontreis con un problema, si conseguís resolverlo informeis a la "comunidad" para que todos podamos beneficiarnos de esa solución)

Una vez realizada la modificación mencionada, reiniciamos la aplicación y el jconsole nos proporcionó esta bella panorámica:

Adios a la fuga de memoria!

Feliz Navidad a todos.

Por favor, no más SQL, los ORM's se inventaron hace tiempo...

2006-12-19T16:14:00.000+01:00

Ahora que ya capté tu atención, aclararemos que el título de este post no es cierto del todo :). El SQL todavía tiene su lugar, y es un lugar importante, pero estoy convencido de que el 90% del código que se escribe hoy en día debería emplear un ORM y no SQL "a pelo". Más aún, los ORMs decentes te permitirán bajarte al nivel del SQL en ese 10% de los casos.

Por supuesto, parto de la base de que ya hemos superado el pleistoceno y estamos programando en un lenguaje orientado a objetos (de nuevo, no todos los desarrollos del mundo deben usar la OOP, pero casi), usando herencia, encapsulación, definiendo interfaces, programando consumiendo dichas interfaces ,etc.

Bien, ¿cuántas veces hemos escrito la típica aplicación de gestión con Clientes, Pedidos, etc.? Seguro que muchos de nosotros todavía hacemos algo del tipo:


public class Cliente{
 String   nombre;
 Calendar fechaNacimiento;
 String   telefono;
 ...
}

public class GestorCliente{

  //bdd: simplificación de la API JDBC
  public void nuevoCliente(Cliente c){
    bdd.execute("INSERT INTO clientes VALUES(nombre,fechaNacimiento,telefono) ("+ Sql.escapa(c.nombre) +","+ c.fechaNacimiento +","+...);
  }

  public void modificaCliente(Cliente c){
    bdd.execute("UPDATE clientes SET nombre="+ Sql.escapa(c.nombre) +","+ ...);
  }

  public Cliente obtenCliente(int id){
     ResultSet rs = bdd.consultar("SELECT nombre,fechaNacimiento,telefono FROM clientes WHERE id="+ id);
     if (!rs.next()) throw new RuntimeException("Cliente no encontrado");
     Cliente c = new Cliente(rs.getString(1),rs.getDate(2),rs.getString(3));
     return c;
  }

  public void eliminarCliente(int id){
     bdd.execute("DELETE FROM clientes WHERE id="+ id);
  }

}

Además tendremos una serie de scripts SQL para la creación de las tablas en la base de datos:

clientes.sql:


CREATE TABLE clientes{
 id            INTEGER       NOT NULL PRIMARY KEY   auto_increment,
 nombre        VARCHAR(255) NOT NULL,
 telefono      VARCHAR(100) NOT NULL,
 fhnac         DATETIME     NOT NULL
}

¿Os dais cuenta de cuántas veces hemos tenido que escribir cada campo de la entidad "Cliente"? ¡Seis! ni más ni menos que seis veces. Esto no es duplicación de código, esto es "sextuplicación"! :)

Existe un concepto acuñado por Dave Thomas y Andy Hunt denominado DRY, es decir, "no te repitas". Cuando escribes algo más de una o dos veces piensa que posiblemente algo puede mejorarse en tu código.

Bien, con un ORM como Hibernate toda esta requeterepetición de identificadores se ve reducida a la mínima expresión:


@Entity
public class Cliente implements Serializable {
   Long   id;
   String nombre;
   Date   fechaNacimiento;
   String telefono;

   @Id
   public Long getId() { return id; }

   public void setId(Long id) { this.id = id; }

   //getters y setters del resto de propiedades
}

Ahora, para crear un cliente basta con hacer:


Cliente c = new Cliente("luis",new Date(),"600111222333");
session.save(c);

Para modificar un cliente:


session.update(c);

Para obtener un cliente por id:


c = session.get(Cliente.class, id);

Para eliminar un cliente:


session.delete(c);

¿Bastante mejor no? Incluso el propio Hibernate se puede encargar de crear el esquema en la base de datos, por lo que también nos libramos de los scripts SQL para la generación de las tablas.

Ahora bien, no nos engañemos. Hibernate es una solución compleja a un problema complejo, que es la unión del mundo relacional y el OOP. Como tal, su uso no es algo trivial. La gestión de las sesiones, asociaciones entre clases etc. requiere de un poco de práctica y de lectura de documentación con sosiego, pero os lo puedo asegurar, merece la pena superar esta pequeña curva de aprendizaje inicial. Hibernate no sólo hará que escribáis código de forma mucho más productiva y menos aburrida, sino que os proporcionará una visión más clara de lo que deben ser las transacciones y las conversaciones que la aplicación mantiene con la base de datos.

Ánimo y, ¡adios al aburrido SQL! (siii.... en el 90% de los casos).

Borrar un archivo permanentemente en el Subversion

2006-11-17T16:36:00.000+01:00

Como muchos sabreis el Subversion es un Source Control System que viene a sustituir al CVS, mejorándolo en una serie de aspectos. Para una introducción al mismo y a su integración en el NetBeans 5.5 recomiendo el siguiente WebCast:

https://collabnet.webex.com/collabnet/onstage/tool/record/viewrecording1.php?EventID=245164111&Rnd=0.8441946756428462
En el Suversion, resulta que se lleva control de versión de absolutamente todo: ficheros, directorios, eliminación de ficheros, etc. Por ejemplo, si subimos un fichero con información sensible (passwords, datos personales, etc.) al repositorio, cuando queramos borrar dicha información descubriremos que... no se puede! Si usamos el comando "svn delete" lo único que conseguiremos es borrar el fichero de la última revisión (HEAD). Pero en la(s) revisione(s) anterior(es) seguirá estando el fichero disponible para que, todos aquellos que tengan acceso de lectura al repositorio puedan consultarlo.

Pues bien, una solución fácil y sencilla para excluir definitivamente un fichero de un repositorio dado es la siguiente. Primero realizamos un volcado del repositorio entero:

mv repositorioXXX repositorioXXX.bak
svnadmin dump repositorioXXX.bak > repositorioXXX.data

A continuación volvemos a volcar el repositorio pero esta vez aplicando un filtro:

svndumpfilter exclude trunk/proyectoXXX/.passwords < repositorioXXX.data > repositorioXXX.data.filtrado

Ya solo resta volver a crear el repositorio y cargar los datos filtrados:

svnadmin create --fs-type fsfs repositorioXXX
svnadmin load repositorioXXX < repositorioXXX.data.filtrado

Finalmente, en aquellas copias locales del repositorio habrá que eliminar el fichero (svn delete, mi cliente subversion no se quejó de que no existiera el fichero en el repositorio) para que la copia local quede sincronizada con el repositorio del servidor. En cualquier caso, una solución que siempre funcionará será hacer un checkout entero del repositorio.

Configurar el tomcat con certificado de cliente

2006-11-01T22:43:00.000+01:00

Cuando queremos restringir el acceso a cierto recurso de nuestro
sistema podemos optar por el clásico esquema de proteger dicho
recurso con un par usuario/clave. Pero existe un tipo de accesos o
comunicaciones en el que dicho patrón no es adecuado. Estamos
hablando de las comunicaciones B2B (Business to Business),
es decir, de las comunicaciones entre sistemas, en contraste con las
comunicaciones B2C (Business to Client).

Pongamos un ejemplo: supongamos que tenemos un floreciente negocio
consistente en la venta de minutos de música on-line. Un
cliente puede comprar una licencia para escuchar música
on-line durante un cierto tiempo limitado. Para acceder al sistema el
usuario deberá conectarse a un determinado portal web e
identificarse tecleando su usuario y contraseña.

Ahora bien, cuando el tiempo de su licencia se agota, puede acudir
a la sección Recargas del portal y efectuar una recarga
de, por ejemplo, seis horas. Tras abonar el importe de la recarga
mediante una pasarela de pago, automáticamente su licencia se
recargará con seis horas. Pero mira por dónde, resulta
que el portal web y el sistema que gestiona las recargas de licencias
están alojados en máquinas diferentes y deben
comunicarse a través de internet. Para hacer posible esta
comunicación, el sistema de recargas proporciona un servicio
web(web service) accesible directamente usando HTTP.
Evidentemente, dicho servicio debe estar protegido, de forma que sólo
nuestro sistema pueda acceder a él.

En los dos párrafos anteriores se describen dos procesos de
comunicación distintos. El primero, el efectuado entre el
cliente y el portal web es la típica comunicación B2C,
donde la autenticación se realiza mediante un par
usuario/clave. En cambio, la segunda comunicación, entre el
portal web y el sistema de recargas es una comunicación B2B.
En dicho caso no tiene sentido que generemos un par usuario/clave,
puesto que quien se está identificando en esta ocasión
es un sistema, no una persona. En dicho escenario la solución
más adecuada es utilizar un certificado de cliente, que
identificará en este caso al portal web ante el sistema de
recargas.

Otro escenario donde quizá se vea mejor la utilidad de los
certificados cliente es el siguiente. Imaginemos que quien
efectúa las recargas es nuestra encantadora secretaria, Paula.
Paula tiene instalado en su PC un pequeño programilla que le
permite efectuar las recargas cuando un cliente llama por teléfono.
Imaginemos que en vez de utilizar un certificado cliente para
identificar el programa ante el sistema de recargas utilicemos un
esquema usuario/clave y codifiquemos directamente dichos valores en
el programilla en cuestión. ¿Qué pasaría
si dicho programilla se grabara en un CD para hacérselo llegar
a Paula y dicho CD se extraviara y llegara a manos del avispado
Maximino? Pues que Maximino podría instalar el programilla en
su casita y efectuar todas las recargas que quisiera sin pagar un
duro... En cambio, si lo que hacemos es identificar el PC que
efectúa la recarga mediante un certificado de cliente (se
instala en el propio sistema operativo, en el caso de Windows por
ejemplo) el programilla dejará de tener acceso al sistema de
recargas si se instala en otro ordenador.

Bueno, después de este rollo patatero vamos a lo que vamos,
a configurar nuestro tomcat para permitir este esquema de
autenticación. El tomcat permite configurar una autenticación
de este tipo, pero debe realizarse a nivel de "Connector"
(no se puede hacer a nivel de "Context" por
ejemplo). Lo que esto implica es que si queremos habilitar esta
autenticación para un servicio determinado debemos configurar
dicho servicio en un "Connector" independiente (con
su puerto, etc.)

Los parámetros de configuración del elemento
"Connector" que debemos establecer son:

clientAuth: true (Tomcat will require all SSL clients to present a client Certificate in order to use this socket)
TruststoreFile: the TrustStore file to use to validate client certificates
truststorePass: the password to access the TrustStore
truststoreType: JKS(formato de Java) o PKCS12(formato MSIE, Firefox)

Por supuesto, el Connector a configurar deberá estar configurado con SSL (ver http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html ) Por ejemplo, para configurar un servicio
en el puerto 8443 que requiera un certificado de cliente válido
para acceder a él debermos configurar un Connector
(TOMCAT_HOME/conf/server.xml) similar al siguiente:

<Connector port="8443"maxHttpHeaderSize="8192"
        maxThreads="150"minSpareThreads="25" maxSpareThreads="75"
        enableLookups="false"disableUploadTimeout="true"
        acceptCount="100"scheme="https" secure="true"
        clientAuth="true"sslProtocol="TLS"
        truststoreFile="/home/recargas/truststore" truststorePass="bliblibli"/>

El parámetro más importante es truststoreFile,
que indica la keystore (almacén de certificados de
java) donde se encuentran los certificados (bueno, las claves
públicas de los certificados, para ser más exactos) de
los clientes que podrán acceder a este servicio. Los pasos
para generar un certificado cliente (necesitaremos tener el JDK
instalado, para poder utilizar la herramienta keytool)
son los siguientes:

Creamos el par de claves del cliente (formato PKCS12, para
poder importar después el certificado en nuestro explorador y
poder testear la configuración del tomcat):

/home/andres$ keytool -v -keystore
keystore.p12 -genkey -keyalg rsa -alias RECARGAS -storetype pkcs12

El keytool nos pedirá una contraseña para el
almacén de certificados que va a crear (keystore.p12).
Introduce, por ejemplo, blablabla. Después nos pedirá
una serie de datos para el certificado (no son importante, pero hay
que rellenarlos):

¿Cuáles son su nombre y apellido?: Portal Web
musica.com

¿Cuál es el nombre de su unidad de
organización?: Dpto. web

¿Cuál es el nombre de su ciudad o localidad?:
Baiona

¿Cuál es el nombre de su estado o provincia?:
Pontevedra

¿Cuál es el código de país de dos
letras de la unidad?: es

¿Es correcto CN=Portal Web musica.com, OU=Dpto. web,
O=musica.com, L=Baiona, ST=Pontevedra, C=es?: si

Generando bit 1.024 par de claves rsa y certificado
autofirmado (MD5WithRSA) para: CN=Portal Web musica.com, OU=Dpto.
web, O=musica.com, L=Baiona, ST=Pontevedra, C=es

Escriba la contraseña clave para <RECARGAS>

Finalmente, la herramienta keytool nos preguntará una
contraseña nueva para la clave privada de este certificado.
Le damos a INTRO para que utilice la misma que la del almacén.
Exportamos el certificado (nos pedirá la clave del
almacén, introducir blablabla):

/home/andres$ keytool -export -file
recargas.cert -alias RECARGAS -keystore keystore.p12 -storetype
pkcs12
Importamos ese certificado en la truststore del
tomcat. En este paso estaremos creando un nuevo almacén de
certificados, esta vez para el tomcat, por lo que se nos pide una
nueva clave para este nuevo almacén. Introduce bliblibli:

/home/recargas$ keytool -import -keystore
/home/recargas/.truststore -file recargas.cert

Se nos preguntará si confiamos en el certificado después
de mostrar sus datos por pantalla. Diremos que si.

Ahora solo resta reiniciar el tomcat. Para comprobar que la
configuración es correcta podemos intentar acceder a una
página web del tomcat con nuestro explorador. Por ejemplo,
imaginemos que accedemos a https://recargas.musica.com:8443/,
donde tenemos un tomcat recién instalado y configurado con SSL
en el puerto 8443. Veríamos la siguiente página sin
mayor problema:

Ahora, si seguimos los pasos aquí descritos, reiniciamos el
tomcat y refrescamos la página veremos lo siguiente:

El explorador detecta que el servidor está solicitando un
certificado de cliente, por lo que muestra un diálogo al
usuario instándole a que seleccione el certificado a utilizar.
Muy probablemente no tengamos ningún certificado de cliente
instalado, por lo que dicho diálogo nos muestra una lista
vacía. Le damos a "Esc" para cerrar el diálogo
y efectuamos los siguientes pasos para instalar el almacén de
certificados "keystore.p12" generado anteriormente en el
almacén de certificados de Windows (nota: probablemente, al
cerrar el diálogo el Explorer nos muestre la página del
tomcat de nuevo. Esto no quiere decir que el Explorer sea un genio y
se haya saltado nuestro mecanismo de autenticación,
simplemente nos está mostrando una página guardada en
la caché):

En el Explorer seleccionamos Herramientas->Opciones de
Internet
Seleccionamos la pestaña Contenido y pinchamos
en Certificados. En la pestaña actual (Personal)
pinchamos en Importar y seguimos los pasos del asistente.
Deberemos seleccionar el archivo "keystore.p12" generado
anteriormente e introducir la contraseña del mismo
("blablabla"). En el último paso dejamos marcada la
opción Seleccionar automáticamente el almacén
de certificados en base al tipo de certificado, pulsamos
Siguiente y Finalizar.
Ahora debemos cerrar todas las ventanas del Explorer y volver
a arrancarlo.

Si intentamos acceder de nuevo a https://recargas.musica.com:8443/
veremos lo siguiente:

Pinchamos en Aceptar para que el Explorer utilice el
certificado mostrado para autenticarse y... ¡estamos dentro! :)

Una nota final. La clave privada asociada al certificado
regargas.cert se encuentra en el almacén "keystore.p12".
Cuando se exporta el certificado dicha clave no es exportada (lo cual
es bastante evidente, pero como todo esto es un poco lioso no está
de más señalarlo). Por tanto, para importar el
certificado de cliente en el firefox, por ejemplo, éste debe
acceder a "keystore.p12", no a recargas.cert

Hasta la próxima.

Configurar dos conexiones a internet en una máquina linux

2006-10-20T19:43:00.000+02:00

Antes de nada, un par de links sobre el tema (pues lo de configurar dos conexiones puede aplicarse para diversos fines, y en estas páginas comentan varios):

http://linux-ip.net/html/adv-multi-internet.html

http://lartc.org/howto/lartc.rpdb.multiple-links.html

Ahora, el ejemplo concreto que he realizado. Estos días he estado implementando un sistema MONITOR, el cual realiza peticiones HTTP periódicamente a los distintos subsistemas de mi empresa, midiendo tiempos de respuesta, errores en la conexión, etc.

El sistema se configuró para que empleara las dos conexiones a internet que tenemos en la empresa (cable y ADSL), de forma que las peticiones HTTP se hiciesen tanto por una conexión como por la otra. Esto aporta una serie de ventajas, como puede ser la comparación de un ISP con otro, etc.

La idea era hacer eso instalando el sistema MONITOR en una localización única (no valía poner dos monitores corriendo en máquinas distintas una configurada con el ADSL y otra con R) por lo que surgió la duda de cómo configurar un linux para que

tenga dos conexiones a internet disponibles

decidir, a voluntad, qué conexión se quiere utilizar en cada momento

[Otra posibilidad, discutida en uno de los links anteriores, sería realizar un balanceo de carga automático y utilizar las dos (o más conexiones) de forma transparente.]

Según he visto, no es posible hacer esto con los comandos clásicos "ifconfig" y "route" del linux. Es necesario emplear las tools "iproute2" (vienen con todos los linux de hoy en día, no problem). La navaja suiza de dicha suite es el comando "ip". Con él podemos hacer absolutamente todo lo relacionado con la configuración de la capa ip del kernel.

Datos varios:

IP gateway ADSL: 192.168.0.253

IP gateway cable: 192.168.1.200

IP host MONITOR: 192.168.0.150

(Nota del autor: este documento será absolutamente práctico. Para comprender los conceptos detras de todo esto por favor acudan a http://linux-ip.net/, que el tío se explica mejor que yo O:))

Pasos necesarios:

Añadir una IP en la red 192.168.1.0/24 (crear un alias)

# ip address add 192.168.1.150 brd + dev eth0 label eth0:R
Crear una tabla de enrutado nueva llamada "R", p.e. en el slot 200:

# echo 200 R >> /etc/iproute2/rt_tables
Añadir una regla de enrutado que diga "si la dirección ip fuente, es la 192.168.1.150 trata de enrutar el datagrama IP usando *primero* la tabla R":

# ip rule add from 192.168.1.150 table R
Añadir la siguiente ruta a la tabla 'main' (suelta por eth0 todos los datagramas dirigidos a la red 192.168.0/24):

# ip route add 192.168.1.0/24 dev eth0
Añade el gateway de R a la tabla R:

# ip route add default via 192.168.1.200 table R
Un último paso (por prudencia): limpia la cache de enrutado

# ip route flush cache

Y ya está. Cuando queramos "salir" por R tendremos que especificar a la aplicación que usemos que utilice "192.168.1.150" como ip fuente. Para testear el correcto funcionamiento de los pasos dados podemos comprobar qué ip pública nos devuelve www.whatismyip.com utilizando wget:

wget www.whatismyip.com -O - | grep "WhatIsMyIP.com -"

Titulo: WhatIsMyIP.com - 80.135.23.45

li> wget --bind-address 192.168.1.150 www.whatismyip.com -O - | grep "WhatIsMyIP.com -"

Titulo: WhatIsMyIP.com - 123.45.67.32

Por supuesto, toda esta configuración se irá al garete al reiniciar la máquina. De alguna forma hay que hacer esas instrucciones se ejecuten al arrancar el sistema (/etc/rc.local por ejemplo).

Hasta la próxima!

HttpUnit se cuelga...o eso parece.

2006-10-04T11:10:00.000+02:00

Pues ya está bien de tanta fiesta jolgorrio, un poco de seriedad y cultura geek.

Muchos conocereis la suite HttpUnit. Se trata de una pequeña maravilla que permite implementar unidades de test al estilo JUnit, pero donde los módulos a testear son páginas web (servlets, páginas jsp, php, cgi's, lo que sea...). HttpUnit nos permite simular el acceso a un portal web, hacer "click" en los links, consultar las cookies, ejecutar código Java Script, etc.

Pues bien, en la ejecución de un test comprobé que el test se quedaba colgado. Para consultar en qué punto se congelaba la ejecución del test, en vez de hacer una sesión de debug o de plagar el código de líneas de logueado (soy demasiado vago para hacer eso...) utilicé otra pequeña maravilla, el JConsole.

Este lindo programilla nos permite conectarnos a una JVM y comprobar el estado de la memoria, los threads, el tiempo de ejecución y muchas otras cosas interesantes. Para que el JConsole se pueda conectar a una JVM ésta deberá arrancarse (java 5.0) con la propiedad

-Dcom.sun.management.jmxremote

(en el NetBeans podemos especificar esta propiedad en las propiedades del proyecto: Run->VM Options).

El JConsole, al arrancar, nos muestra una pequeña ventanita donde lista los PIDs de las aplicaciones java que permiten el "Remote Management". Una vez conectado a una JVM concreta nos mostrará información sobre la misma.

La que nos interesa en este punto es la relativa a los distintos hilos de la aplicación en cuestión. En la parte inferior de la pestaña Threads veremos una lista con todos los hilos vivos. En mi caso, dado que la ejecución del test no es multi-hilo el thread que me interesa es el llamado main (primer hilo de toda aplicación java). Seleccionando dicho hilo podré ver la stack trace del mismo y ver en qué punto de la ejecución se encuentra.

En mi caso el resultado fue el siguiente:

Refrescando la stack trace del hilo main (simplemente pulsando las flechas abajo y arriba, para deseleccionar y volver a seleccionarlo) comprobé que el hilo estaba bloqueado en el método java.net.SocketInputStream.socketRead0(), es decir, en una operación de lectura sobre un socket.

Mmmm, esto tenía toda la pinta de ser un problema con la configuración de los timeouts de los sockets. Busqué en el código de HttpUnit (ya sabeis, a falta de una buena documentación bueno es el código, jeje) y vi que en ningún sitio (salvo en un par de tests, no en la librería en sí) se invocaba el método setSoTimeout(), que establece el timeout de lectura de un socket dado.

Leyendo por ahí comprobé que el timeout por defecto es, infinito!. Ahí la razón del "cuelgue". La simple solución, dado que estoy utilizando una librería y, a pesar de ser de código abierto, no quiero pasar el engorro de modificar el código fuente y recompilar (por vagancia, una vez más, y porque de esa forma estaría creando un "fork" nuevo, incompatible con posibles actualizaciones de la librería...), pasa por establecer las siguientes propiedades:

sun.net.client.defaultConnectTimeout (timeout en ms. usado en el establecimiento de la conexión)
sun.net.client.defaultReadTimeout (timeout en ms. usado en las operaciones de lectura de una conexión ya establecida)

Para ello podemos invocar la JVM con los parámetros
-Dsun.net.client.defaultConnectTimeout=20000
-Dsun.net.client.defaultReadTimeout=20000

o, como finalmente hice, hacerlo programáticamente:

System.setProperty("sun.net.client.defaultConnectTimeout", "20000");
System.setProperty("sun.net.client.defaultReadTimeout", "20000");

A partir de ese momento, el test no se colgó más pero..., claro, excepción java.net.SocketTimeoutException al canto cada vez que hay un timeout! (como no podía ser de otro modo). Sin embargo, dicha excepción puede ser capturada y controlada, de forma que la ejecución del test de larga duración no se quede colgada.

Hasta otra.

Referencias:

JConsole:
- Using JConsole
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html
- Using JConsole to Monitor Applications
http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html

HttpUnit:
- HttpUnit Home
http://httpunit.sourceforge.net
- Black Box Web Testing with HttpUnit
http://www.onjava.com/pub/a/onjava/2003/05/07/blackboxwebtest.html

Java Socket Timeouts:
- Java Networking Properties
http://java.sun.com/j2se/1.5.0/docs/guide/net/properties.html
- Handling Network Timeouts in Java
http://www.javacoffeebreak.com/articles/network_timeouts

Turismo por Cantabria: II - Cantabria

2006-10-01T23:59:00.000+02:00

Más fotucas desta linda tierra...

Santo Toribio de Liébana (centro de peregrinaje, cercano a los picos de europa, famoso por... poseer el trozo más grande de la cruz de Cristo!!, vayamuviiiiiiiiiiiiida!):

Haciendo amigos en una noche de marcha en Castro Urdiales:

Esa nueva amistad fruto del alcohol, jeje:

Esa bonita Mariasun!:

Mariasun en Santillana del Mar:

Y, para acabar..., la prueba de que Mortadelo existe!!! (aunque en la realidad no es tan alto como en los comics):

Mañana vuelta al curro... qué ganas! (grrrrr...)

Ustedes lo pasen bien.

Turismo por Cantabria: I - Bilbao

2006-09-29T09:43:00.000+02:00

Cousa bonita esta Cantabria! Montañas encima del mar, prados verdes, vacas por todos lados... qué más se puede pedir? jeje
Ahí van unas fotucas (así dicen por aquí...). Algunas de Cantabria y algunas de Bilbao (aivalaostia!).

Esta es la bonita playa de Ris, en Noja:

Aquí vemos a un Andrés impresionado por las bellas vistas del nacimiento del Asón (si alguna vez pasais por Laredo/Santoña/Castro Urdiales no dejeis de visitar este curioso nacimiento):

Ahora unas cuantas fotillas de Bilbo.

Ese vilete marcando bíceps con el teatro Arriaga de fondo:

Esa bonita Mariasun, mi guía turística en Cantabria/Euskadi:

Aquí se me ve en el impresionante guggen... estooo, guggenheim? :)

Ese peaso de guardián del guggen, el "pupi":

Y de momento ya está bien, tengo más fotos de Cantabria pero tengo que bajarlas de la cámara.

Me voy a comer rico marmite de la abuela de Mariasun!

The beginning...

2006-09-28T11:04:00.001+02:00

Bien, ya era hora. 28 años, programador desde hace dos y medio y sin blog, esto no podía continuar así...

Benvidos ao meu blog!
Bienvenidos a mi blog!
Welcome to my blog!