Esta semana, a raíz de un mensaje en la lista de correo de Made in Flex, recordé una de las primeras aplicaciones que hice en Flex hace ya dos años con lo cual me lancé a recuperar aquél código, limpiarlo de cosas supérfluas y publicarlo. Os dejo también el enlace a un post mio en la lista Flexcoders donde explicaba como hacerlo, de hecho ha sido mucha la gente que, a partir de ese post, me ha escrito preguntando detalles.

Para los puristas, os aviso de antemano que puede haber cosas que no funcionen bien, código extraño y mil historias más, es un código que tiene dos años, si hacéis cuentas veréis que justo estos días Flex2 cumple dos años. Sí, lo comencé con las primeras betas de aquella versión. Lo único que he hecho ha sido crearlo en Flex3 y dejar la aplicación limpia para que se vea el funcionamiento. Si me váis a dejar un comentario diciendo que tal o cual cosa no funciona bien, podéis ahorrárosla.

Como una imagen vale más que mil palabras, aquí tienes el ejemplo y el código fuente de todo el proyecto.

Todos a los que en algún momento se nos ocurrió utilizar Flex para crear un gestor de contenidos nos hemos dado con un grave problema en la frente: el componente ideal para escribir y actualizar contenidos, RichTextEditor, NO permite, por defecto, insertar imágenes, con lo cual pierde prácticamente su utilidad. Escarbando en la ayuda, sin embargo, te das cuenta de que entre los tag HTML soportados por el componente Textarea se encuentra <IMG>, con lo que, a priori, nada impediría insertar una imagen. En efecto así es y en eso se basa todo este artículo/proyecto. Un detalle importante es que la utilización de imágenes no está bien conseguida en el propio Flash Player, con lo que si comenzamos a añadir y quitar imágenes llegará un momento en el que todo el Textarea será inestable y hará cosas extrañas.

El proyecto se basa en dos componentes, nuestro editor de texto y un explorador de archivos. Desde el editor tendremos un botón Insertar imagen que abrirá un explorador al más puro estilo del escritorio del sistema operativo donde nos mostrará los archivos que tenemos en el servidor, pudiendo subir y eliminar. La lógica del explorador con el servidor la he eliminado al máximo, dejando sólamente unos XML estáticos que listan las carpetas e imágenes disponibles. Para hacerlo bien haríais un script con salida similar a esta pero que liste lo que en realidad hubiese en una ruta de tu servidor.

Nuestro editor de texto

Intentaré explicar como hice todo el proceso, pero fue hace bastante tiempo así que es posible que se me olvide algún detalle.

La idea era hacer un editor avanzado, con las caracteristicas que le faltaban al RichTextEditor original:

• Insertar imágenes.
• Posibilidad de añadir datos tabulados (que no tablas como tales).
• Cambiar el color de fondo del editor para, por ejemplo, crear texto en color blanco.
• Eliminar todo el texto (e imágenes).
• Editor avanzado de links.
• Botón guardar texto (lo insertaría en tu base de datos)

Partimos para ello de un RichTextEditor al que le quitamos el botón predefinido de Añadir link y añadimos nuestros nuevos botones. Siguiendo el código entenderás lo que hacen, por lo que nos centraremos en el de imágenes que es el objeto del artículo. Primero os explico en qué consiste el botón de tabular datos. Es muy sencillo. Si quisiésemos, en el RichTextEditor, crear una tabla de valores con el tabulador, no podríamos, ya que al presionar tabulador saldría el foco del Textarea de escribir  y se iría, por defecto, al selector de fuente. Para solucionarlo añadimos un botón que lo único que hace es añadir un carácter de tabulación (\t) en el texto, con lo que comprobaréis que ya puedes tabular datos perfectamente. Muy útil el truco.

Pasemos pues al botón de insertar imágenes. El botón, tal y como expliqué anteriormente, abre el popup del explorador de archivos, con lo que esta parte la veremos en la siguiente sección. Cuando en el explorador seleccionamos la imagen a insertar se devuelve el control al editor y es éste el que añade la imagen. Para añadir la imagen inserta en la posición del cursor el tag <IMG> con los parámetros necesarios. Aparentemente no tiene más truco, pero al empezar a probar cosas nos damos cuenta que sí que lo tiene.

Para empezar, si guardamos el htmltext de este RichTextEditor en la base de datos y posteriormente intentamos recuperarlo recibiremos un desagradable error de validación XML. Quiero aclarar antes de nada, que este error me ocurría en aquél entonces, quizás, ojalá, las ultimas versiones de Flex lo hayan solucionado, te ahorraría muchos problemas. La causa del error de validación era que internamente, aunque tu añadieses un tag <img … /> (o <img…></img>) válido, el editor te devolvía siempre <img .. > , es decir, el XML sin cerrar, con lo cual al cargarlo de nuevo saltaba error de validación. Para solucionar este problema creamos un método desProcesaTexto que lo que hace es convertir todos los tags <img..> no válidos a tag válidos, con lo que tenemos el primer problema resuelto. Utilizando expresiones regulares será extremadamente sencillo.

Segundo problema. Una vez insertamos una imagen, ¿cómo podemos quitarla o modificarla? Aquí viene parte del truco. La idea, básicamente, es añadir a cada imagen un link de manera que al hacer click en ella se nos abra un popup que nos permita eliminar la imagen o modificar sus atributos. Esto genera otro inconveniente. Cuando queremos recuperar el contenido del Textarea para guardarlo en la base de datos debemos eliminar estos links falsos añadidos para la interfaz de usuario, pero que no queremos que salgan cuando se muestre el texto. Por contra, cuando cargamos un texto desde la base de datos debemos procesar los atributos de imágenes para añadirles este link y podamos operar con ellos.

Como se aprecia en el código, bucamos todos los tags <IMG> y, asumiendo que todos tendrán un tag <A> anterior, reemplazamos el nodo <A> completo por el <IMG> y todo solucionado, más sencillo de lo que parece una vez se entiende el procedimiento.

Para contemplar estas peculiaridades cada vez que asignamos el texto al componente o cada vez que lo recuperamos, tenemos los siguientes métodos:

No hay mucho más que explicar. Como peculiaridad, veremos como procesaríamos los tags <IMG> cuando cargamos un texto nuevo en el componente. La idea, básicamente, es añadir el link que nos permita modificarla, pero este link necesita conocer los datos de la imagen (src, width, height..).

Sencillo.

El explorador de archivos

El explorador de archivos es un componente bastante resultón que, si lo trabajas un poco, te puede solucionar muchas tareas. Igual que el Explorador de Archivos de Windows, tienes a la izquierda un árbol de directorios y a la derecha los archivos de la carpeta seleccionada y sus detalles. Arriba tenemos botones para subir archivos nuevos y crear nuevas carpetas (la lógica de estos botones es cosa tuya) y, sobre todo, un combo para cambiar el modo de ver los archivos de manera que puedes ver la lista de los mismos o las miniaturas. Si, si listas imágenes verás un thumbnail de las mismas, perfecto para nuestro editor. No voy a enrollarme mucho más con el funcionamiento ya que en el código fuente tienes todo lo necesario. El evento interesante es el doble click sobre un archivo, que devuelve el control a una nueva ventana donde puede configurar los parametros de la imagen a insertar. Con el ejemplo lo entenderas.

En tu editor deberás crear los métodos adecuados en el servidor para listar las carpetas y archivos de tu directorio de uploads si quieres que todo sea dinámico y el usuario pueda organizarse por su cuenta los archivos.

Tal como había comentado, no he sido tan explícito como en otras ocasiones. Si tienes algún problema no dudéis en dejar un comentario e intentaré solucionarlo a la mayor brevedad posible.

Aquí tienes el ejemplo y el código fuente de todo el proyecto.

Da igual si no llegas a final de mes, si tu curro es un asco o si sube el Euribor. Da igual la desaceleración, que el IPC crezca desesuradamente o que el paro vaya en aumento contínuo.

Hoy todo es un poquito mejor porque hoy…

 SOMOS LOS MEJORES DE EUROPA

Tenía 8 años cuando un 27 de junio vimos perder a España su merecida Eurocopa ante Francia tras aquél agónico 12-1 a Malta de la fase de clasificación.
Tenía 18 años cuando el codo de Tassoti y la nariz sangrante de Luis Enrique nos mandaron a casa tras una impresionante trayectoria.
Tenía 24 años cuando un penalty fallado por Raúl ante Francia nos mandó a casa en la Eurocopa de 2000.
Tenía 26 años cuando un mal árbitro y el penalty fallado por Joaquín ante Corea nos mandaron de vuelta a casa

Hoy, con 32 años, lo hemos logrado, podemos celebrar algo importante y, lo mejor de todo, lo hemos hecho a lo grande, sin perder ni un partido, sin perder los papeles, limpiamente, jugando al fútbol, con inteligencia.

Por Arconada, por  Luis Enrique y su nariz, por el NO gol de Michel a Brasil en Mexico’86 (y por el 5-1 de Dinamarca, y por los penaltys también), por el penalty de Raúl en la Eurocopa de 2000, por el penalty de Joaquín en Corea 2002, por la medalla olímpica en Barcelona’92, por los penaltys ante Inglaterra en la Eurocopa del 96… y por tantos y tantos sufrimientos que hemos pasado a lo largo de estos años.

Esta vez sí…

PUDIMOS

Me copio de Jose Alberto Hernandis una interesante entrada que, tal y como él comenta, y después de mi artículo Historias y homenajes en 8bits, podría titular también “Historias del abuelete 2″, jejejeje.

Mi primer contacto con Internet se produjo a finales de 1994, recién llegado a la universidad, en la ETSE Telecomunicación de Vigo. Un inocente chaval de 18 añitos entraba en contacto con el mundo exterior. Comenzamos a tener correo electrónico con unos Macintosh prehistóricos, no sé qué modelo eran pero os aseguro que de los primeros. Al poco tiempo se renovó el parque de PC’s de la Escuela por unos flamantes Pentium90 y nos permitieron recauchutar los viejos 286 para montar una red Linux de uso exclusivo para alumnos en un pasillo muerto (había muchos en aquél extraño edificio). Por aquél entonces ya disponíamos de cuentas personales de correo, de acceso a la red y acceso shell. Por cierto, la mía me la bloquearon al poco tiempo .

Corría el año 1996 cuando tuve mi primera conexión en casa, un modem 28.800 de ultimísima generación con una superoferta de RedesTB (después CTV y hoy Wanadoo). Comenzar a utilizarlo fue un caos ya que tenía MSDOS6.22+Windows3.11 (ya existía Windows95 pero me negaba a instalarlo ), así que me tenía que pelear con Trumpet Winsock para lograr conectar a Internet y no había manera así que, después de ver un artículo en PC-Actual sobre cómo conectar con Linux editando no sé cuantos archivos a mano (de aquella tendría un Red Hat 4.1 o similar) decidí a probar suerte con él y así fue como, señoras y señores, mi primera conexión a Internet desde mi casa fue ¡con Linux! (por friki que parezca) y durante muchos meses, hasta que me decidí a migrar mi 486 a Windows95.

Por razones obvias tuve que llegar a un acuerdo con mis padres para hacerme cargo del gasto telefónico porque sí, queridos niños y niñas, hubo un tiempo en este país donde no existían las tarifas planas ni banda ancha y pagábamos una millonada para conectarnos media horita a hipervelocidad, jejejeje. El problema fue que el gasto fue creciendo exponencialmente, sobre todo al descubir los chats y las chavalas que en ellos moraban, pero eso, amigos, es otra historia .

Tal y como he prometido sigo en mi empeño de, como mínimo, dos artículos por semana, así que ahí va el segundo de esta .

Hoy veremos cómo aprovechar un móvil que ya no utilicemos para recibir alertas y ejecutar acciones remotamente en nuestros servidores.

Monté un sistema de este tipo por primera vez allá por 2002 y desde entonces lo hago siempre que tengo nuevos servidores que manejar, sobre todo en aquellos que hacen de monitor (Cacti y/o Nagios) y backup.

La idea inicial era recibir alertas de problemas en el servidor sin tener que estar delante de la máquina. En aquél momento no había más opciones que el email, pero si no estabas delante de la máquina no recibirías nada. Posteriormente aparecieron las primeras pasarelas SMS por HTTP (con una llamada HTTP y los parámetros adecuados, envías un SMS), pero aún hoy tienen un inconveniente, si tu máquina se queda sin conectividad (problemas de red, router, ataques DOS..) nunca recibirás alertas y nunca te enterarás de que algo ocurre.

Se me ocurrió entonces que podría utilizar un Nokia 3210 que acababa de jubilar ya que además me había comprado el cable para conectarlo al ordenador por el puerto serie, pero me faltaba lo más importante, el software. Me puse a investigar y encontré lo que buscaba, era lógico, no iba a ser yo el primero al que se le ocurriese esa idea . La solución se llamaba Gnokii, un software que se comenzó a desarrollar ni más ni menos que a finales de 1998. Por lo que me consta, dejó de actualizarse allá por 2003, aunque probablemente siga funcionando perfectamente en la mayoría de casos, sin embargo hace ya tiempo que apareció un fork de Gnokii, Gammu, que es el que utilizo desde hace ya unos años y sobre el que nos centraremos en este artículo. Además he cambiado la forma de conectar el terminal al ordenador, ya no es por el puerto serie sino por bluetooth.

Podríamos dividir el artículo en cuatro pasos:

1. Conectando el móvil con el servidor.
2. Enviando mensajes.
3. Sistema de mensajería avanzado.
4. Ejecutando acciones.

Conectando el móvil con el servidor

Comenzaremos por configurar el servidor. No voy a explicar detenidamente los pasos puesto que, aunque hoy en día son sencillos, se salen del alcance del artículo. De todos modos configurar el bluetooth hace cuatro o cinco años era bastante más complicado, hoy todas las distribuciones Linux tienen los paquetes preparados.

Lo primero, obviamente, será tener una antena bluetooth en el servidor, con una USB será suficiente y funciona perfectamente, yo lo tengo así desde hace años.

El siguiente paso será instalar los paquetes necesarios para tener conectividad bluetooth, normalmente son dos, bluez-libs y bluez-utils. Si tu sistema operativo es medianamente moderno probablemente los tengas ya instalados, sino estarán en cualquier repositorio.

Como supondremos que estamos trabajando con servidores, lo más probable es que no tengas entorno gráfico, así que lo configuraremos todo a mano. Si tuvieses entorno gráfico hay paquetes gnome para hacer el emparejamiento automáticamente.

En mi Centos5.0 los archivos de configuración se encuentran en /etc/bluetooth, en el tuyo pueden variar. Tendremos que configurar tres archivos:

• hcid.conf: configura los servicios que ofrecerá la antena bluetooth.
• pin: pin de la SIM del móvil para no tener que introducirlo manualmente. Tambien puedes configurar la SIM para que no solicite pin.
• rfcomm.conf: configura los canales de comunicación.

La verdad es que no recuerdo mucho las distintas opciones de hcid.conf, así que me limitare a copiar mi configuración para que tengáis un punto de inicio.

El archivo pin es muy sencillo, simplemente debes poner el pin de la SIM de tu teléfono.

Finalmente configuramos el canal de conexión con el móvil. Para ello debemos averiguar la dirección bluetooth de tu móvil, sería algo así como la dirección MAC, de hecho tiene una estructura semejante. Para ello, inicia el servicio bluetooth, o reinícialo si lo tienes ya iniciado,

/etc/init.d/bluetooth restart

y ejecuta

Esto te devolverá la lista de dispositivos bluetooth a tu alcance con el nombre y la dirección que tienen. Si obtienes algo como Device is not available: No such device, tu antena no está iniciada, quizás no se ha detectado correctamente, consulta el log de inicio con dmesg a ver qué ocurre cuando conectas la antena al USB.

Supondremos que todo ha ido bien y tienes la lista de dispositivos. Busca el del móvil que estás utilizando y apunta la dirección, la necesitarás añadir al siguiente fichero, rfcomm.conf.

Si todo ha ido bien tenemos el sistema bluetooth preparado y enlazado con el móvil.

Enviando mensajes

Instalamos el paquete Gammu. De nuevo, lo más probable es que haya un binario para tu sistema en los repositorios habituales, sino siempre puedes descargar el fuente y compilarlo tu mismo. Configurarlo es muy sencillo. Para empezar tenemos un sólo archivo:

/etc/gammurc

En la primera línea indicamos el canal que vamos a utilizar, que es el que configuramos en el paso anterior y añadimos un log para tener información.

Comprobamos si todo va bien. Para eso preguntamos a nuestro teléfono la hora que tiene su sistema, por ejemplo:

Nos devolverá la hora del teléfono y tendremos todo preparado. Ya podemos probar a enviar mensajes.

Con este sencillo comando podemos configurar cualquier aplicación que necesite enviar alertas para que nos haga llegar un SMS. Así de fácil.

Sistema de mensajería avanzado

Una vez teníamos el sistema anterior montado caímos en la cuenta de que podríamos utilzarlo para hacer más cosas de las que habíamos pensado, sólo necesitábamos saber cómo .

Una de las máquinas que utilizábamos de monitor se encontraba en la oficina, tras una línea ADSL. El router de esta línea tenía algún problema que hacía que bajo ciertas circustancias se colgase y había que reiniciarlo, con lo que había que ir personalmente a la oficina para hacerlo. Se nos ocurrió entonces que, si ya teníamos un sistema de envío de SMS funcionando, ¿por qué no hacer que pueda recibir y ejecutar acciones en base a lo que reciba? Dicho y hecho. En vez de responder a POLI BULERIA , nuestro sistema respondería a ROUTER, aunque posteriormente fuimos ampliando las acciones, como REBOOT que permite hacer un reinicio limpio del servidor y todas las que posteriormente se te ocurran.

Investigando la ayuda de Gammu descubrimos que hay una forma de poner el sistema en modo demonio y que automáticamente recoja los SMS que lleguen al terminal y envíe los que se le encolen. Este procedimiento requiere modificar un poco el sistema, pero una vez configurado ganarás en robustez y efectividad.

La clave es la opción -smsd de gammu que lo pone automáticamente en modo demonio. Este servicio lo que hace es recoger los SMS que se reciban en el móvil y dejarlos como archivos de texto en un directorio específico mientras que coge los SMS que se quieren enviar y que previamente hemos dejado en otro directorio y los envía. Es decir, en vez de hacer los envíos directamente como veíamos antes, los dejas en archivos de texto y automáticamente el demonio los envia. Veamos primero la configuración necesaria. El archivo que maneja toda la configuración es /etc/smsdrc. De nuevo os copio mi configuración tal cual puesto que tiene mucho tiempo y no recuerdo los parámetros.

No tiene mucha ciencia, el primer sector es igual que en el apartado anterior mientras que en el segundo configuramos el PIN de tu SIM y los directorios donde dejar y recoger los SMS tal como explicábamos antes.

Es importante puntializar el formato de los archivos de texto que dejaremos para enviar mensajes los que recibiremos.

• Mensajes salientes: en outboxpath dejaremos los archivos con el nombre siguiento el patrón
  OUT<phone number>.txt,
  por ejemplo con el nombre OUT666777888.txt se enviaría al 666777888 el contenido del archivo de texto.
• Mensajes entrantes: en inboxpath recibiremos los mensajes con el nombre del archivo siguiendo el patrón
  IN<date>_<time>_<serialno>_<phone number>_<sequence>.txt,
  por ejemplo IN20021130_021531_00_+45409000931640979_00.txt. En este caso habríamos recibido el 30/11/2002 a las 02:15:31 un mensaje desde el +45409000931640979. Creo que sobran detalles adicionales.

Teniendo esto claro, podemos lanzar el demonio. Tan simple como

/usr/bin/gammu  --smsd FILES /etc/smsdrc &

Si algo va mal nos devolverá algún error, si no, tendremos nuestro sistema de envío y recepción funcionando. Para probarlo, comprueba la ruta inboxpath, si tenías SMS’s en tu teléfono empezarás a ver como entran los archivos de texto. También puedes probar a crear uno en el outboxpath siguiendo el patrón descrito, verás como lo recibes en el otro teléfono.

Hasta aquí tenemos el nuevo sistema de envío y recepción terminado. Deberás modificar tu sistema de alertas para crear los archivos de texto tal como hemos explicado y lo tendrías automáticamente funcionando. También puedes crear un sencillo script PHP que te permita enviar SMS de una manera cómoda, simplemente dejarás los mensajes en forma de archivos de texto en la cola del directorio y el demonio se encargará de enviarlos.

Ejecutando acciones remotas

Ahora deberemos hacer el script que compruebe los SMS recibidos y decida qué hacer con ellos. Os pondré un ejemplo básico para que tengáis una idea clara de cómo habría que hacerlo, es responsabilidad vuestra asegurar el acceso al sistema de acciones de manera que sólo determinados teléfonos puedan ejecutarlas. Yo, por comodidad, lo haré en PHP, pero podéis hacerlo como queráis, PERL, Python, bash, C,…

El script es muy sencillo, buscamos los archivos del directorio INBOX, analizamos el nombre para ver el número de origen y separamos el contenido por palabras para decidir la acción. Fijáos que con este sistema es fácil crear acciones con parámetros, simplemente se añaden palabras y en el switch se opera como se necesite. En mi caso, cada acción recibida genera una respuesta en modo de SMS a enviar para que sepamos que la acción ha funcionado.

Y esto es todo amigos. Si has seguido bien las instrucciones tendrás un precioso sistema de envío y recepción de SMS desde tu servidor sin necesidad de tener conectividad a Internet. A través de Gammu puedes enviar también MMS, por si te apetece montar un sistema de seguridad que te envíe una captura de una webcam , por ejemplo. El límite está en tu imaginación y en tus necesidades.

Supongo que a estas alturas ya la mayoría os habréis enterado del incendio ocurrido en uno de los CPD’s (centro de proceso de datos) que The Planet tiene en Houston, Texas. Al parecer la causa del incendio fué la explosión de uno de los transformadores que dan servicio al CPD. Debido al incendio se tuvo que cortar completamente sl suministro eléctrico del centro provocando con ello el apagado de unos 9.000 servidores, entre ellos los DNS principales de la antigua EV1, había servicio de respaldo pero los bomberos obligaron al corte completo como medida de seguridad. Creo que han tardado algo más de 24h en restaurar completamente el servicio, desde el foro se pudo seguir la evolución de la incidencia.

El CPD en cuestión era uno de los que EV1 Servers tenía cuando fue adquirida por The Planet hace un par de años y el más antiguo de la compañía.

Pues bien, nosotros tenemos servidores en The Planet desde 2002, de hecho teníamos servidores en ese CPD de EV1 hasta agosto del año pasado cuando, gracias a unas buenas ofertas, los migramos a nuevas máquinas y con ello cambiamos de centro de datos, ahora estamos en Dallas, sino ahora mismo seríamos uno de los afectados.

He leído mucho estos días acerca de lo ocurrido. He llegado a leer si realmente vale la pena llevarte la infraestructura a USA cuando puede ocurrir esto que ha ocurrido. Y yo me pregunto, ¿acaso esto no podría ocurrir en España? Esto y mucho más , los problemas son independientes del lugar, si no es un transformador el que explota es una regleta que se quema, una fuente estropeada o un router colgado. También podría ser otra máquina con la que compartes RACK y/o router que ha sido atacada o mil historias más, ¿verdad Raúl?, pero problemas los hay en todas partes. ¿Acaso por tener tus máquinas en un CPD de Logroño estando tú en Valencia vas a resolver algo que no podrías resolver si están en USA? La respuesta es obvia a no ser que tengas enchufe y te vayan a tratar antes y mejor por ser tú, cosa poco probable para la mayoría. Lo que debes pensar es en tener gente detrás que vaya a solucionarte los problemas que tengas y que no puedas solucionar tú.

Nuestra experiencia, tanto en EV1 primero como en The Planet después, es inmejorable. Rápida respuesta a los pocos problemas que nos han dado, avisos con semanas de antelación de ventanas de actuaciones, soporte rápido y eficaz, etc. Cuando hemos tenido algún problema más grave han hecho las cosas con profesionalidad y siempre preguntando primero, reinicios manuales, fsck’s controlados, cambios de cables de discos defectuosos que estaban provocando problemas, etc. En una ocasión incluso se hizo el cambio de un disco defectuoso con dos parones de unos 5 minutos cada uno, el disco no había dejado de funcionar, simplemente lanzaba errores esporádicos de lectura/escritura. En una parada añadieron un disco duro para que lo preparásemos todo y en la siguiente reemplazaron el original por la copia. Todo funcionó a la perfección y en 24h se cambió un discon sin afectar al servicio. Reconozco que también puede ser que hayamos tenido algo de suerte .

Profundizando un poco más en el asunto, el incendio de The Planet es sólo uno de los problemas que pueden ocurrir y ante los que apenas hay opciones de protección. Recordemos casos como el del Edificio Windsor de Madrid donde había ni más ni menos que un CPD de Colt Telecom, o las inundaciones en Louisiana tras el Katrina donde todo quedó arrasado y devastado. Nadie ni nada puede asegurar que sus servidores estarán seguros 100% y que nunca ocurrirá nada. Por contra, tú si que puedes asegurar que estarás protegido ante estas situaciones y así poder minimizar los efectos. En función del presupuesto de que dispongas podrás estar mejor o peor preparado, pero lo básico es muy barato y sencillo.

Si tu presupuesto lo permite, lo mejor es, sin duda, tener siempre un CPD de respaldo con toda tu infraestructura de producción duplicada, actualizada y preparada para entrar en producción cuando la principal se venga abajo. Obviamente esto es un gasto que casi nadie va a ser capaz de justificar ante sus superiores.

Si, como la mayoría, no puedes permitirte un CPD de respaldo, mantén una buena política de copias de seguridad y un plan de contingencia bien documentado y actualizado. Si lo haces bien, en apenas unas horas podrás tener levantado desde cero una máquina que haya fallado. NO, repito, NO confíes en los RAID1 (espejo) y ve con cautela con los RAID5, he visto muchos servidores completamente perdidos por culpa de la controladora RAID. ¿De qué sirve tener un RAID1 bien chulo si al petar la controladora se van los dos discos a paseo? A la hora de hacer tus backups ten en cuenta que no sólo necesitas los datos propiamente dichos, sé previsor y guarda todos los archivos de configuración y scripts que te has ido haciendo con los años y que sigues utilizando. Documenta en el plan de contingencia cada detalle que estimes oportuno para restaurar el servicio. Apunta cada cambio que haces en la configuración de cada servicio. ¿De qué te va a servir tener todos tus datos si no has guardado la configuración de Apache y ahora tienes que crear uno a uno todos los Virtual Hosts?

Finalmente, aunque parece evidente, llegado el momento muchos se olvidan. Distribuye tus copias de seguridad. NO tengas el backup en el mismo CPD y mucho menos en la misma máquina. A ser posible almacena los backups en varios sitios. A mi me gusta hacerlo en otro CPD bien alejado del de producción y en tus oficinas.

Como último consejo, pon en marcha el plan de contingencia al menos una vez al año. Coge una máquina limpia, tu plan de contingencia y mide el tiempo que tardas en tenerlo todo online y revisa los problemas que te van surgiendo. Alimenta con esta experiencia tu plan de contingencia para hacer frente a posibles imprevistos llegado el momento.

Eso es todo amigos, ojalá nunca tengáis que poner en práctica el plan de contingencia .

He dejado de lado el blog casi un mes. La verdad es que he estado un poco agobiado y sin muchas ganas de contar historias que uno nunca sabe si le interesan a alguien por mucho que Google Analytics diga que sí, pero me apetece contarlas y las cuento, porque yo también leo las cosas que escriben otros que tampoco saben si a alguien le interesa lo que cuenta.

Hoy me había levantado contento, de hecho este fin de semana había casi terminado un buen artículo que saldrá casi con toda probabilidad mañana, sin embargo el pasar del día lo ha cambiado todo. Primero un buen compañero de trabajo y casi amigo nos ha “abandonado”, la vida es así, pronto estarás en otro sitio mejor Diego, no lo dudes. Marta, anima esa carita mujer, que hay cosas peores, que tu vida no depende del Euribor y aquí nadie quiere ver esos ojitos a punto de llorar. Desde aquí tenéis todo mi apoyo para lo que necesitéis.

La tarde no ha sido mejor, he llegado a casa y me he dado cuenta de que no tenía llaves, no sabía si las había perdido por el camino o si las había dejado en casa a mediodía con las prisas, en la oficina no estaban. Menos mal que Luis siempre está ahí como último recurso y me ha tocado recorer en taxi media Valencia de ida y otra media de vuelta para poder entrar. Nunca me arrepentiré de haberle dejado un juego de llaves a un buen amigo. Al final, por suerte, las llaves estaban colgadas en su sitio.

Así que aquí estoy, melancólico y escribiendo. Han pasado miles cosas por mi cabeza, mil cosas personales y varios miles profesionales. Cada vez siento más que necesito un cambio de aires, tanto personal como profesional.

Como decía, he vuelto con fuerzas renovadas y me he hecho unas promesas que voy a cumplir, porque yo soy así y porque yo lo valgo :

• Prometo recuperar la costumbre de escribir un par de artículos por semana como mínimo.
• Prometo terminar los libros que tengo en camino, a saber:
  • The Pragmatic Programmer, de Hunt y Thomas
  • UML y patrones, de Craig Larman
  • Recopilación de artículos sobre desarrollo de proyectos de software de Navegapolis.
  • Y alguno mas que compré en Amazon y no llegué a abrir.
• Álvaro, prometo ser menos serio
• Marcos, me debes unas cuantas comidas cucharete, aunque haya que dejar 5 euros de propina
• Prometo recuperar las ganas de maquinar extraños proyectos que nunca sirven para nada pero que mantienen mi ego y mi cerebelo a 1000 por hora.
• Luis, prometo hacer eso que te debo
• Y no, no voy a apuntarme al gimnasio, no estoy tan desesperado.

Para ir entrando en materia, una recomendación personal-profesional, Fuckovski, memorias de un ingeniero también disponible en pdf. Creo que cuando tu vida se parece en exceso a la de Fuckovski tienes que volar como Rockefeler. Espero no tener que llegar a esos extremos. Quizás un poco de sol y playa lo solucione, aunque está visto que este año se hace de rogar. En todo caso no hay nada que unos días de playa en A Pragueira y unas cuantas churrascadas con amigos no puedan solucionar.

Mientras tanto, me he enganchado de nuevo a Deluxe, Xoel sabe muy bien lo que se hace. Ahora mismo me harto de repetir su Reconstrucción, prefiero eso a los llorones (¿verdad Guillermo?). He recuperado algunas cosas antiguas, Stone Roses, Soundgarden, Placebo, Radiohead… he redescubierto a Wilco y Muse y me he hiper-enganchado a Kaiser Chiefs.

Os dejo también mi pequeña aportación a la historia de Internet hispana, un honor compartir capítulo junto a Iván Martínez, uno de los fundadores de Infojobs.

Os veo pronto .

Ayer lunes entró en producción uno de nuestros proyectos más ambiciosos junto a Irc-Hispano, la red de chat más grande e importante del mundo hispanohablante. Se puede acceder a nuestra aplicación desde aquí.

Hacía muchos años que queríamos algo así pero no existía la tecnología necesaria. Los que usamos Internet desde hace muchos años, en mi caso desde 1994, sabemos que antes de que existiese el Messenger ya estaba el IRC, el chat de toda la vida. El problema era que se necesitaban programas concretos para utilizarlo (Mirc) y después había que saber configurarlo y tener unas nociones básicas (servidores, nicks, canales, kick, ban, join…). Muy complicado para el usuario no experto. Así apareció a finales de los 90 la probablemente mayor utilidad de los applets de Java: el cliente IRC online. Ahora los usuarios ya no necesitaban conocimientos ni instalarse nada, simplemente accedían a la web, ponian su nick, el canal donde querían chatear, y a “relacionarse”. Incluso aparecieron clientes IRC en HTML, muy útiles pero sin las opciones de usabilidad de las otras.

La idea era muy buena, pero nadie había contado con los problemas asociados: necesidad de la máquina virtual de Java, lentitud, pesadez, etc. Los usuarios no tenían más que problemas.

Corría entonces el año 2002 cuando se nos ocurre hacer lo mismo pero en Flash, una tecnología presente en la mayoría de navegadores y con una implantación mucho mayor que la de Java. Nos pusimos a investigar y nos llevamos una gran decepción, no había forma de comunicarse con un servidor IRC estandar, en aquél momento Flash sólo disponía de xmlsocket, que permitía conectarse a hosts remotos pero siguiendo unas especificaciones especiales.

Todo estaba perdido hasta 2006. En junio de este año Adobe (que ya había absorvido a Macromedia) lanzaba Flex2 y junto a él la versión 9 de Flash Player con la funcionalidad más esperada por nosotros: la posibilidad de crear sockets binarios. Con esto ya se podían hacer en Flash clientes pop/smtp, ftp y, por supuesto, IRC. Esto marcó un antes y un después y nos pusimos de inmediato a planificar nuestro sueño. Tardamos más de seis meses en meternos de lleno en el proyecto puesto que ya estábamos trabajando en otros.

Desde el primer día tuvimos que comenzar a pelearnos con el RFC del protocolo IRC, fundamental para conocer el funcionamiento del sistema ya la sintaxis de todos los mensajes de ida y vuelta con el servidor. Una vez tuvimos el núcleo básico fue relativamente sencillo construir toda la interfaz de usuario sobre él, creando los comandos y acciones así como los eventos de respuesta. El primer problema era que había muchas opciones distintas, así que fuimos fijando prioridades y trabajando sobre ellas.

Cuando teníamos una versión básica pero funcional y debido a las políticas de seguridad de la máquina virtual Flash, nos pusimos en contacto con Irc-Hispano y desde el primer momento les encantó la idea, los planes y nuestro prototipo, con lo que fue sencillo llegar a un acuerdo que beneficiase a ámbas partes. Mientras nosotros desarrollábamos, la gente de Irc-Hispano se ocupaba del testing.

Hablando ya técnicamente, y aunque esté mal que yo lo diga, se ha hecho un trabajo impresionante exprimiendo toda la potencia de Flex. Hemos conseguido integrar bastantes cosas que a simple vista son casi imposibles de utilizar en Flex, como los smileys en un área de texto, o los colores de fondo. Documentándonos por aquí y por allí y viendo lo que habían conseguido otros conseguimos adaptar ciertos sistemas a nuestras necesidades quedando el conjunto francamente bien.

Desde el primer momento tuvimos claro que la única forma de conseguir sacar una aplicación de este tipo era usando técnicas de desarrollo ágiles, y así lo hicimos, preparando periódicamente versiones funcionales de lo que hubiese y poniéndola a disposición de los usuarios para que nos aportasen el feedback necesario, no solo de errores sino también de usabilidad y funcionalidad en general. La experiencia ha sido perfecta y todo el equipo ha salido beneficiado de este modo de trabajo, ya que se elimina automáticamente el estrés del miedo a los cambios cuando el producto está ya terminado.

Y así llegamos hasta hoy en que se lanza públicamente. Se han hecho muchas más funcionalidades de las previstas inicialmente y seguramente se irán haciendo muchas más a medida que se vaya utilizando. Por nuestra parte ha sido un esfuerzo enorme en horas de trabajo y quebraderos de cabeza para hacer y solucionar problemas sin respuesta aparente, pero el resultado ha valido la pena.

A partir de ahora esperamos ir corrigiendo bugs y añadiendo mejoras, ideas no nos faltan y seguramente habrá muchas sorpresas ;). Algún día también refactorizaremos :P.

Tras un mes de abril bastante decepcionante (por no decir deprimente) tanto profesional como personalmente dedicimos, mi buen amigo Marcos y yo, irnos de puente las dos parejas para tener unos días de descanso.

Después de la primera edición de lo que hemos dado en llamar Xuntanza Anual Amigos do Lérez (xuntanza es una reunión de amigos en galego mientras que Lérez es el río que pasa por Pontevedra), nos pusimos a organizar la segunda. El destino elegido inicialmente era La Rioja, pero nos fué imposible encontrar un apartamento rural, ni siquiera en Navarra, Zaragoza, Burgos o Ciudad Real, así que terminamos en Jaén, en la Sierra de Cazorla. El lugar elegido fue la Casa del Tío José María en Hinojares. Inicialmente íbamos a ser uno más, pero Emiliano tuvo que dar marcha atrás a última hora por problemas de salud de su padre, ¡que se mejore!. David y Paula tampoco pudieron acudir a esta cita, no os preocupéis, habrá más :).

La vista del pueblo cuando tomas el último desvío es impresionante, para muestra un botón.

Nuestro comentario era que parecía un pueblo en medio de un paisaje lunar, no en vano recoge los últimos restos del desierto de Almería. No os preocupéis que el paisaje mejora después. En el pueblo no hay cobertura de telefonía móvil que no sea Movistar, con lo cual nosotros nos pasamos los cuatro días del puente incomunicados, inicialmente te asustas pero a medida que avanzan los días te alegras, relax 100%.

Ya en la casa nos recibieron cordialmente sus dueños, Rosa y Jesús, y nos dejaron un completo catálogo confeccionado por ellos mismos con rutas, mapas, sitios imprescindibles y hasta restaurantes recomendables en cada ruta. Simplemente genial y de muchísima ayuda.

A partir de aquí comenzamos nuestras rutas turísticas y gastronómicas, aunque la verdad es que estas últimas nos defraudaron bastante en general, esperábamos una zona con muy buenas comidas de carnes (cordero, cabrito, caza…) y nos encontramos con pizzerías y más pizzerías, casi todos los restaurantes de los pueblos eran pizzerías.

Nuestra primera parada nos llevó al Arroyo Guazalamanco, donde remontamos el río durante un buen rato buscando las cascadas que venían en los catálogos, cascadas que por supuesto no encontramos, el río traía muy poca agua, pero aún así valió la pena, la zona es preciosa y el río hace bastantes rápidos y cascadas, aunque sean pequeñas. Por la misma zona nos acercamos al Mirador de La Alcantarilla.

El viernes nos encaminamos decididos a Úbeda y Baeza, declaradas por la Unesco Patrimonio de la Humanidad. Menuda decepción. Tiendes a tener el concepto de que algo con semejante declaración tiene que resultarte impresionante al verlo, con esas ganas íbamos, pero te encuentras con algo que no te llama para nada la atención.

De camino habíamos parado en Cazorla, pueblo que da nombre a la Sierra. Ese sí que es bonito y típico. Vale la pena callejear por su entramado de calles estrechas y subir al Castillo. Aquí tuvimos la peor experiencia gastronómica del viaje, tuvimos que mandar de vuelta dos solomillos de ciervo y un churrasco de ternera (se suponía especialidad de la casa), estaban tremendamente malos, mala carne y muy mal hechos. Nos fuimos sin comer.

Cazorla, ademas de precioso, es un sitio animado. Si buscas algo más que descanso y silencio, este es tu sitio. Las cañas siempre con tapas, pero no un cuenco de patatas fritas, pinchos morunos (uno por caña) o montaditos de morcilla de la zona fueron los nuestros, simplemente genial y a un precio más que asequible.

Después de la mala experiencia con la comida decidimos pegarnos un homenaje por la noche para compensar, así que nos fuimos a una carnicería y nos surtimos de carnes y embutidos de la zona e hicimos una barbacoa en la chimenea de la casa regando nuestras gargantas con un estupendo Campo Viejo Gran Reserva 2001. Eso sí que es comer y beber.

A continuación tocaba cumplir con la mejor de las tradiciones, la queimada, lástima que como siempre se nos olvida el conxuro.

El tercer día fué, sin duda alguna, el mejor en cuanto a rutas culturales. Comenzamos la jornada en el Santuario de la Virgen de Tíscar, considerada la Covadonga del sur, con el Castillo Peñas Negras a sus espaldas y la impresionante Cueva del Agua al frente. Lástima que no hubiese una indicación hacia la cueva que nos evitase hacer unos 60km de sinuosas carreteras de montaña para acabar volviendo al punto de partida. Aún así mereció la pena.

Fijaos en la primera foto, la entrada a la cueva se hace a través de un pequeño túnel escavado en la misma montaña por el que hay que pasar agachado.

Para finalizar el día nos acercamos a Castril, ya en la provincia de Granada. Un pueblo precioso y pintoresco, aquí si que te sientes Lorca en Granada.

En Castril hay dos cosas que no te puedes perder. La primera es simplemente impresionante, la pasarela de madera sobre el río Castril, con su puente colgante y su cueva de varios metros de largo.

La segunda es el castillo… si consigues subir. Para un hombre con mucho vértigo como yo fué un verdadero reto, y más aún viendo la barandilla que han puesto para que te agarres, te da de todo menos seguridad. Aún así una vez llegas a la cima es impresionante.

Aquí finalizamos nuestro segundo día, el más intenso y bonito de todos. Al día siguiente, el último, tocaba madrugar para hacer una ruta a caballo. Los chicos no habíamos montado nunca y las chicas hacía mucho que lo habían hecho. Nosotros íbamos muy pero que muy cagaos, pero al final la experiencia fue flipante y terminamos galopando un poco y jugando entre nosotros.

Para finalizar el día fuimos hasta Baza, donde comimos, pueblo sencillo. Finalizamos la tarde en el Castillo de La Calahorra, a escasos 18km de Guadix. Lástima que estuviese cerrado.

Y con esto y 450km más, de vuelta a casa y al estrés de la rutina diaria. ¿Para cuando la próxima?

Marcos y Nines decidieron continuar camino y prolongar el puente un día más en Granada para ver la Alhambra y el casco histórico. Creo que tuvieron algunos problemas para conseguir entrar, aunque al final lo lograron. Pero esa es otra historia que nos contará él mismo.

Marcos lo cuenta aquí, aquí, aquí, aquí, aquí, aquí y aquí.
Y aquí…
Y aquí…
Y aquí, aquí, aquí y aquí.

Webalizer (con su excelente fork continuado awffull) y awstats han tenido históricamente fama de contar visitas y páginas de más, sobre todo desde que Google abrió al público su Analytics y ya nada volvió a ser lo mismo. Hace años tuvimos alguno de nuestros proyectos auditado por OJD y la diferencia con webalizer era mínima, sin embargo las distancias con Analytics son abismales.

Analitycs surge de la compra de Urchin por parte de Google en 2005, otro clásico del software para estadísticas web. Analytics se lanzó primero en beta muy cerrada y bastante después la abrieron completamente al público. Desde el primer día todos nos hemos dado cuenta de las enormes diferencias de datos que había entre lo que contaban nuestros analizadores de logs y lo que contaba Analytics.

Recientemente necesitaba valorar las estadísticas de acceso a distintos proyectos móviles y la única herramienta de la que disponía era el querido webalizer, pero ¡cómo fiase de sus datos!. Analytics no es una opción en este entorno ya que la inmensa mayoría de terminales no soportan Javascript, con lo cual no va a funcionar la contabilización de páginas. Se me ocurrió entonces probar Urchin Software, la última versión del software comprado por Google y que ellos mismos distribuyen y en el que, se supone, se basa Analytics. Aunque el precio de la licencia sea posiblemente prohibitivo para la mayoría, tenemos una versión de prueba de 3 meses, así que dicho y hecho, la descargamos la instalamos y comenzamos a monitorizar nuestros sites móviles. La sorpresa fue mayúscula al cabo de un par de días cuando comprobamos que el resultado es prácticamente el mismo que con webalizer. No nos lo podíamos creer, así que decidimos monitorizar sites también controlados por Analytics para comparar, comenzando por el blog Restaurantes en Madrid. Al cabo de unos días volvimos para comparar el resultado y nos sorprendimos de nuevo. Resultados semejantes a webalizer y completamente distantes de Analytics. Pero ahora la diferencia era enorme, estamos hablando del doble con creces de visitas y páginas que nos muestra Urchin respecto a Analytics.

Urchin (o webalizer, o awstats) se basa en el análisis de logs de acceso del servidor web, mientras que Analytics lo hace a través de Javascript. No cabe duda alguna de que el primer método ha de ser, por fuerza, mucho más creíble y eficaz ya que se basa en peticiones HTTP recibidas de verdad, mientras que el segundo método confía en que el cliente tenga Javascript. Pero ¿qué ocurre con clientes sin Javascript?, más aún, ¿qué pasa con los accesos a feeds?, ¿son visitas no contabilizadas y perdidas? Pues sí. Osea, la herramienta de estadísticas web por excelencia está contabilizando, al menos, un 20% (según he leído en algún sitio) de tráfico menos de lo que en realidad tienes y aún así se ha convertido en el estandar, no lo puedo entender. ¿Los que te leen por RSS no son visitantes también? Se ve que no… La única razón que se argumenta en favor de Analytics es que así no cuenta tráfico proveniente de los robots de los buscadores, pero no dicen nada de los efectos colaterales.

Las críticas que se puedan aplicar a webalizer o a awstats son exactamente las mismas que puedes echar sobre Urchin, con la diferencia de que este último cuesta la nada desdeñable cifra de 3.000 euros. Sin embargo te habrás gastado este dineral para obtener unas cifras nada parecidas a Analytics. Cuando vayas a vender tus espacios publicitarios qué datos vas a enseñar, los de Urchin o los de Analytics, o mejor aún, cuales te van a pedir tus anunciantes?.

Creo que ya todos os habéis dado cuenta que me gusta el interior de la provincia de Castellón. En contraste con el turismo de playa de su costa (Benicassim, Oropesa del Mar, Peñíscola…), dispone de una impresionante colección de pueblos en su interior montañoso.

Hoy nos vamos a Culla. Situada a unos 130km de Valencia, Culla es el típico pueblo medieval bien conservado y con mucho encanto. Para llegar a Culla hemos de pasar por varios pueblos de la geografía castellonense donde puedes hacer parada y no te arrepentirás. Nosotros hicimos dos paradas:

• La Pobla Tornesa, para almorzar y comprar pan, ¡pan de verdad! Es una vieja costumbre que tengo, comprar pan cuando voy a los pueblos, es lo más auténtico que puedes encontrar y nada que ver con el que comes a diario en las ciudades :).
• Benassal, con parada en el balneario Font d’En Segures donde puedes aprovechar para beber y llevarte algo de agua. Íbamos con unos conocidos de allí y nos llevaron a conocer la zona.

Durante el camino tendrás casi siempre a la vista el Penyagolosa, el segundo techo montañoso más alto de la Comunidad Valenciana con 1813m y declarado Parque Natural por la Generalitat Valenciana en 2006.

Y llegamos a Culla, declarado conjunto histórico artístico y con su casco antiguo rehabilitado, pertenece, al igual que Morella, a la zona conocida como El Maestrazgo.

Enclavada en la base de un antiguo castillo árabe, Culla pasa a dominación cristina en 1233. Las ruinas actuales del Castillo son fruto de las Guerras Carlistas. Culla conserva restos de murallas, torreones y palacetes. Puedes apreciar bastantes escudos heráldicos a lo largo de las calles del pueblo.
Desde lo alto del castillo tendrás unas impresionantes vistas de la zona.

Continuando por la carretera de Culla a Torre Embesora nos encontramos con La Carrasca de Culla, considerada la encina más grande de España y Europa y declarada Árbol Monumental de la Comunidad Valenciana. Creedme que impresiona. La tradición popular dice que bajo su copa se pueden sentar mil personas.

Justo al lado del árbol nos encontramos con el Restaurante La Carrasca, donde haremos parada para comer. Posiblemente todo estará impresionante, pero nosotros íbamos directos y con las mandíbulas babeando a por una gran torrà de chuletas de cordero y embutidos acompañados de ajoaceite. No hay fotos del momento, no tengo costumbre de fotografiar los platos, prefiero dejar esos menesteres a los chicos de Cucharete, pero os puedo decir que nadie salió defraudado. La gastronomía de Culla, al igual que toda la zona, se basa en carnes a la brasa y embutidos.

Para finalizar la ruta siempre puedes terminar después de comer con un paseo por Morella.