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.

load "" <enter>

Si no conoces su significado es que, probablemente, has nacido en los 80 (o después) y/o descubierto los ordenadores en los 90 (o después), para ti la informática siempre ha sido de 16bits o más y ha tenido forma de PC y esto es lo más parecido a una calculadora que conoces:

Hubo un tiempo en que los 8bits dominaban el mundo, no sólo en ordenadores personales sino también en consolas (con Nintendo NES y Sega Master System en cabeza). Ni Almodóvar ni la Movida Madrileña, los 80 fueron y serán toda la vida del ZX Spectrum. Después estaban Amstrad, Commodore Amiga y MSX :P.

Corría el año 1984 cuando descubrí la informática con un flamante ZX Spectrum 16k, sí, 16k de memoria ram, no 2GB. Pronto descubrí que con 16ks no se podía hacer mucho, para hacer algo útil necesitaba la friolera de 48k, pero yo sólo tenía 16 y con eso tuve que conformarme. A partir de ahí comenzó una relación de amor odio que dura hasta nuestros días, sin embargo, mi vida no hubiese sido la misma sin un personaje, un visionario, Sir Clive Sinclair, el inventor de tal artilugio.

Después de haber inventado la primera calculadora de bolsillo en los 60, en 1980 este señor ya quería colocar un ordenador en cada casa y para lograrlo ideó el primer ordenador personal como tal, pequeño y barato, sobre todo comparado con los IBM PC’s de la época. Para hacernos una idea, creo que un PC costaba más de medio millón de las antiguas pesetas mientras que un Spectrum salía por unas 22.000. Tendrían que pasar 20 años más para que alguien volviese a querer poner un ordenador en cada casa. Sir Clive no lo logró, pero permitió que toda una generación de chavales que merendábamos bocatas de chorizo con Barrio Sésamo e interrumpíamos nuestro partido en la calle los sábados por la tarde para ver V conociésemos los ordenadores y aprendiésemos mucho más de lo que nuestros padrés se habrían imaginado.

Tras el Z80 y el Z81, Research International Ltd. lanza en 1983 el ZX Spectrum en versiones 16 y 48k con un sistema BASIC empotrado en una ROM de 16k, tecnología punta para aquella época. Fue un bombazo en Europa y se vendieron varios millones de equipos, llegando incluso a penetrar en Estados Unidos y Japón. La empresa de Sir Clive facturaba en 1984 más de 3.000 millones de pesetas. Sin embargo en 1986 el fracaso de otras de sus ideas le llevaron a tener que vender la empresa a su más directo competidor, Amstrad (¿os suena?). Esto llevó al lanzamiento del último modelo de la saga Spectrum, fotocopia de los CPC128, el 128k+2 y el 128k+3, mismo modelo pero con unidad de disquettes 3” en vez de cintas. Sí, también tuve uno de estos, el de cinta.

¿Qué hacía especial al Spectrum? Todo en sí mismo. Se conectaba al televisor, sí, ¡a la tele!, venía con un radiocasette y traía de serie un manual de programación BASIC, nuestra futura biblia. Espera, ¿has dicho radiocasette? Así es, queridos niños, en el mundo Spectrum los juegos y programas se distribuían en cintas de audio normales y corrientes y se necesitaba un reproductor para cargarlos en el ordenador, lo que conducía a horas y horas de espera para jugar a un juego, y eso con suerte, ya que tres de cada cinco veces la carga fallaba y había que comenzar de nuevo. Quien alguna vez escuchó el característico ruido de cargar un programa en Spectrum no lo olvidará en su vida, ese pitido chirriante… cuando ya lo conocías sabías perfectamente por el sonido cuando se había fastidiado la carga del juego y había que rebobinar.

¿Quién no ha destrozado las teclas del casette del 128k rebobinando y dando al play? También aprendimos lo que era el tornillo del azimut, indispensable para conseguir cargar con éxito un juego y que tarde o temprano dejaba de funcionar, así que o bien hacías presión con tus manos sobre la cinta para tratar de que cargase el juego o te tocaba tunear el Spectrum, que sí, que has leído bien, he dicho tunear el Spectrum.

MicroHobby fue, es y será un mito. Era LA REVISTA con mayúsculas. Todo lo que se cocía alrededor del Spectrum aparecía en MicroHobby. En casa de mis padres aún conservo la colección casi completa de MicroHobby’s, desde el número 1. Con esta revista aprendimos a programar y crakear los juegos, que sí, que has vuelto a leer bien, a crakear, con los famosos POKEs y PEEKs consegías saltar de fases o conseguir vidas infinitas, lo único que hacías era modificar determinadas posiciones de memoria y a disfrutar. Microhobby editó por capítulos el mejor libro de la historia para programar el Spectrum en ensamblador, un libro mítico que también tengo encuadrenado. MicroHobby tenía su parte de Bricomanía, y en uno de sus capítulos mostraba como añadir un radiocasette externo al 128k+2, así que me puse manos a la obra. Un par de orificios por aquí, un par de puentes por allí y un par de jacks hembra por el otro lado y tenemos los clásicos mic y ear para conectar un aparato externo. Aún recuerdo los sudores al abrir el Spectrum por primera vez y soldar dentro de él. Fué mi primer tuning de ordenadores.

El pirateo tampoco es nuevo, de hecho ya lo hacíamos por aquél entonces. Como los juegos iban en cinta, era tan sencillo copiarlos como copiar una cinta de música. El colega que tenia una doble pletina era la envidia de todos puesto que tenía la copia perfecta asegurada. Mientras tanto, los demás debíamos conformarnos con puentear los mic y ear de dos radiocasettes. Eso sí, conseguías tener una docena de juegos en una cinta de 60′.

Algo que la mayoría no sabrán es que por aquella época España era la principal potencia mundial en desarrollo de videojuegos. Quién no recuerda nombres como Opera Soft (Livinstone Supongo, La Abadía del Crimen), Topo Soft (Las tres luces de Glaurung, Perico Delgado), Dinamic (Abu Simbel Profanation, Sgrizam) o Zigurat/Made in Spain (Sir Fred)… todas de aquí y con títulos que se vendían a medio mundo en versiones Spectrum, Amstrad y MSX. Si te interesa conocer la historia no deberías perderte esta serie de artículos,

Hoy Sir Clive Sinclair sigue desarrollando ideas y vendiéndolas, pero nunca con el éxito que alcanzó con el ZX Spectrum, más aún, creo que lo importante no fué el éxito en sí mismo sino la influencia que tuvo en la gente de mi generación.

Return sin gosub, POKE, PEEK, CLS, DATA… Cuántas horas aprendiendo a programar. Sí, aprendimos aprogramar en aquello que hoy no sería más que una calculadora avanzada, y menudas obras de arte se hacían con tan poco.

Vaya desde aquí mi más sentido homenaje para ese visionario.

Prometo recuperar mis dos ejemplares de Spectrum (16k y 128k+2) de casa de mis padres y hacerles una vitrina.

A nadie le cabe duda hoy por hoy que una de las tareas más importantes y necesarias en el trabajo de los departamentos de sistemas es la monitorización, tanto de máquinas como de servicios.

Hoy en día está de moda Nagios, no es la primera oferta de trabajo que veo donde buscan desarrolladores de plugins para Nagios. Antes fue Big Brother, todo un clásico de la monitorización. Ámbas son muy semejantes y su funcionalidad es parecida, la diferencia está en que Nagios es Open Source y Big Brother es comercial. En general, su utilidad es comprobar la disponibilidad de servicios en los servidores (http, pop, smtp…). Si en un periodo de tiempo determinado no hay acceso a un determinado servicio (es decir, se ha intentado varias veces sin éxito), se lanza una alerta puesto que se supone que puede haberse caído. Las alertas son ampliamente configurables, se pueden crear grupos de usuarios que la recibirán y pueden ser de distinto tipo (email, pager, sms…). Como herramienta de alertas es perfecta, sin embargo, como herramienta de monitorización se limita a ser un almacén de semáforos, mientras todos están en verde, no hay problemas, cuando uno se pone en rojo, salta a alarma. Así de sencillo. Sin embargo no nos responde a algunas de las preguntas más interesantes:

• ¿Por qué se ha caído el servicio?
• ¿Qué estaba ocurriendo en la máquina cuando se cayó?
• ¿Qué otros servicios de esa máquina podrían estar influyendo en el problema?

Nos informa de la disponibilidad pero no de las posibles causas.

Cacti responde a esas cuestiones de un modo muy eficaz. Cacti es otro concepto de monitorización. Si conoces MRTG sabes de lo que hablamos. Cacti también se base en rrdtool para generar gráficos de actividad periódica. El día que tenga ganas jugaremos con rrdtool puesto que es una experiencia interesantísima, aunque hace ya tres o cuatro años que no lo toco.

Veamos un ejemplo para ir entendiendo sus ventajas. Aquí tenemos una gráfica de uso de CPU con bastante detalle.

Alguno dirá, bueno, está bien, pero con mrtg hago cosas parecidas. Vale, veamos el segundo ejemplo, ahora con dos CPU’s, gráficas independientes y combinada.

Vale tío, pero no me has enseñado nada nuevo, se puede hacer con otras herramientas algo parecido. Seguro, pero no con la facilidad de Cacti. Pero mira lo que te voy a enseñar ahora:

No se vayan todavía, aún hay más…

Si a estas alturas no estás sorprendido creo que no deberías seguir leyendo :P.

Como veis, podemos llegar a tener gran cantidad de información de cada uno de los servicios que tenemos corriendo en el servidor, no sólo tráfico de red o actividad de CPU. Ahora podemos responder a muchas más preguntas en caso de error:

• ¿Qué actividad de Apache había?
• ¿Y de MySQL?
• ¿Cómo íbamos de tráfico de correo?
• ¿Y de DNS? A ver si vamos a estar teniendo un DoS a través del DNS…

Más aún…

• ¿Será un fallo hardware por la temperatura o los ventiladores de la máquina?
• ¿Falta de espacio en disco?
• ¿Nos hemos quedado sin memoria?
• Por curiosidad… ¿como vá el SAI de nuestra máquina?

Con un sólo vistazo a las gráficas respondes a todas las preguntas de golpe.

¿Qué servicio está provocando el incremento de CPU? No hay más que revisar las gráficas de actividad de los principales servicios y ver cual tiene una actividad por encima de lo normal.

Conocí Cacti hará unos cuatro años y desde entonces no puedo vivir sin el. Pero Cacti es mucho más que eso. Llegados a este punto, pensarás:

Si tenemos comprobaciones periódicas de los servicios, ¿por qué no ofrecer una funcionalidad semejante a Nagios en cuanto a disponibilidad?

Voila, parece que alguien ya lo había pensado antes y tenemos un plugin para Cacti que nos ofrece los famosos semáforos verde/rojo.

Bueno vale, pero ¿qué pasa con las alertas?. Sencillo, tenemos otro plugin para lanzar alertas al más puro estilo Nagios.

Según mi experiencia, la combinación Cacti/Nagios roza la perfección y se complementan entre ellos.

Hay cientos de plugins para comprobar y registrar servicios desde Cacti, prácticamente todos los servicios conocidos tienen algún plugin, y, si no encuentras lo que necesitas, siempre puedes hacértelo tú mismo. Puedes incluso crear un pequeño script en tu servidor que genere los datos que necesites y configurar un trap snmp que los lea y los devuelva a una llamada remota, de esta forma integras a la perfección tus registros personalizados con un estándar como es snmp con el que Cacti se comunica a la perfección.

Si aún no monitorizas tus servidores… tarde o temprano vas a pasarlo mal :).

Leo en el blog de Mario Casario esta entrada donde anuncia la disponibilidad gratuita y bajo licencia Creative Commons de la guía Adobe AIR 1 for JavaScript Developer en formato PDF.

Para los que no lo sepáis, Air es la tecnología de Adobe para desarrollar rápidamente aplicaciones de escritorio utilizando otras tecnologías ya existentes: HTML, Javascript y Flash. Así de sencillo, aplicando lo que ya sabes puedes generar aplicaciones de escritorio multiplataforma (Windows y Mac ahora mismo, Linux en camino).

Air está de moda y más desde la compra de Twhirl por parte de Seesmic, de hecho Twitter es de lo más utilizado para crear aplicaciones Air.

Con Air puedes crear rápidamente pequeñas aplicaciones con acceso al sistema de archivos local, bases de datos locales (SQLlite), arrastrar y soltar… todo lo que necesitas para crear tus aplicaciones.

Os aseguro que es increíble lo que se puede hacer con poquísimas líneas de código.

Hace unos días me llegó desde la lista de correo de dev.mobi un interesante artículo sobre la creación de sitios para móviles con Joomla.

No es que me encante Joomla, de hecho probablemente haga un artículo crítico al respecto, pero creo que es muy interesante para determinados websites por su aparente sencillez. El problema que tenía es que quería una solución que me permitiese, a partir de un portal web, tener acceso desde el móvil a una versión adaptada. Gracias a este artículo encontré este plugin que prácticamente te lo da todo hecho.

Hay algo, sin embargo, que no tiene en cuenta el plugin: las imágenes. Las imágenes que insertas en tus artículos serán, normalmente, de un tamaño bastante elevado, sobre todo si hablamos de terminales móviles donde la media es de 174px de ancho de pantalla. La solución pasa por toquetear un poco el plugin haciendo que las imágenes de los articulos pasen a través de un redimensionador automático que crearemos nosotros. Os recomiendo los artículos que escribí acerca del escalado de gifs transparentes y animados (aquí y aquí) para tener una idea de como hacerlo. La solución llega en dos pasos

1) Parcheando el plugin

Este es el cambio que debemos hacer en el archivo pdabot.php del plugin. Busca al final de todo la función onAfterRenderer y haz que quede asi:

Como ves, sustituimos el atributo src de todas las imágenes por nuestro script de autoescalado redimensionar.php al que le pasamos la url original de la imagen. Además aprovechamos para quitar los atributos de width y height porque en este punto no sabemos cuales serán los resultantes, si los dejásemos se vería a su tamaño original. Hemos terminado con el plugin.

2) Escalando las imágenes

Si has entendido todo el proceso hasta aquí estarás pensando, vale, pero nos falta un dato: ¿a qué tamaño escalamos las imágenes?. En efecto, no lo sabemos… todavía.

Y aquí viene W urfl en nuestra ayuda. Wurfl es una base de datos de características de terminales móviles que te permiten conocer datos como el ancho de pantalla simplemente pasándole el UserAgent del mismo. No voy a explicar el funcionamiento de Wurfl puesto que se sale del alcance de este artículo, pero en su web tienes todo lo necesario.

Crearemos entonces nuestro redimensionar.php donde simplemente buscamos mediante Wurfl el ancho de pantalla del terminal cliente y reescalamos la imagen al tamaño adecuado. Es recomendable no hacerlo al 100% para evitar que los scrolls verticales reduzcan el espacio útil y nos aparezca también el scroll horizontal (suele pasar en los Nokia). Yo suelo descontar 10px al ancho. Para imágenes de artículos puedes aplicar un escalado porcentual, pueden no quedar bien imágenes muy grandes, déjalas al 70% por ejemplo.

Conclusiones

Rápidamente y de un modo sencillo hemos adaptado para terminales móviles tu portal en Joomla, no se puede pedir más. No olvides diseñar la plantilla pda a tu gusto y necesidades.

En webs móviles es habitual utilizar una imagen como cabecera del portal. Puedes utilizar también tu redimensionador para adaptarla automáticamente al ancho de pantalla de los clientes.

Se podrían hacer muchas más cosas si integramos Wurfl directamente en el plugin, incluso podríamos hacer que el código generado estuviese adaptado a las capacidades del terminal del cliente (xHTML, iMode, WML) creando plantillas para cada lenguaje distinto. ¿Te atreves a hacerlo tu?

El pasado miércoles 9 de abril Adobe liberó una actualización de su Flash Player numerada como 9.0.124. Esta noticia pasaría completamente desapercibida si no fuese por las implicaciones que tiene. De hecho no entiendo como una actualización con los cambios que conlleva se ha numerado como una actualización menor y no se le ha dado más importancia.

El cambio fundamental de esta nueva versión radica en el modelo seguridad de la máquina virtual Flash al de acceder a sockets remotos y al utilizar headers HTTP. Recordemos que la opción de abrir sockets binarios y conectarse a ellos permitiendo aplicaciones bajo cualquier protocolo apareció en julio de 2006 junto a la versión 9 de Flash Player. Hasta ahora el modelo de seguridad de sockets era el mismo que para cualquier llamada remota bajo Flash, el famoso crossdomain.xml. Según esto, para acceder a cualquier archivo que no resida bajo el mismo host que sirve el swf que hace la llamada, el host servidor debe autorizar a la maquina virtual Flash la carga de ese archivo a través de ese crossdomain.xml, si no existe o no se autoriza el acceso, no se podrá acceder. Este es, por tanto, un archivo de políticas de seguridad y decide quién puede conectarse con Flash a tu servidor. A mi, personalmente, siempre me ha parecido algo ridículo, es como si para cargar un archivo de cualquier host desde tu navegador tuviesen que autorizártelo, pero siempre habrá quien encuentre ventajas en la seguridad. Si el archivo está publicado en Internet se supone que ya estas autorizado a leerlo, ¿para qué complicar más todo el proceso requiriendo más políticas de seguridad?. Y vaya si se complica…

Hasta ahora los sockets se trataban como archivos en lo que a políticas de seguridad se refiere, es decir, el crossdomain.xml del host al que conectábamos nos autorizaba el acceso igual que con cualquier llamada http. Si tienes una aplicación que utiliza sockets y actualizas a Flash Player 9.0.124 verás que ahora no te funciona, te salta una excepción de seguridad. Los chicos de Adobe se han inventado un sistema de políticas de seguridad exclusivo para sockets e independiente de las llamadas http.

Desde Adobe se han currado una ayuda/explicación de 7 páginas. Ninguna pega a no ser porque llegas al final de la lectura con la pregunta, vale, pero ¿qué tengo que hacer para que funcione? Es decir, mucha lectura pero poca, muy poca ayuda, da la impresión de que repiten lo mismo en todas las páginas sin aclarar nada.

La solución es sencilla a la par que curiosa y complicada para muchas aplicaciones. Debes crear una pequeña aplicación que, bajo el puerto 843 por defecto (aunque puedes usar otros puertos), debe responder a las peticiones de acceso con el crossdomain.xml. La mayoría de la gente ha entendido que debes tener tu servidor web a la escucha en el puerto 843 y devolver el crossomain.xml desde allí (como veis no está clara la documentación), pero NO es eso, no es una llamada HTTP la que te va a hacer el swf para pedir autorización. Veámoslo con un ejemplo práctico. Supongamos que fuese una solicitud HTTP, a grosso modo haríamos:

telnet www.tuhost.com 843
GET /crossdomain.xml HTP/1.0

HTTP/1.x 200 OK
Date: Tue, 15 Apr 2008 17:24:26 GMT
Server: Apache
Last-Modified: Thu, 28 Oct 2004 21:57:25 GMT
Content-Length: 128
Content-Type: text/xml

<xml version="1.0" encoding="UTF-8">.....</xml>

El xml final sería nuestro crossdomain.xml. Esto sería lo mismo que si cargamos el crossdomain.xml desde el puerto 80. Vale, pues esto es lo que NO va a hacer el swf, por tanto, no sirve. Esto es lo que va a hacer:

telnet www.tuhost.com 843
<policy-file-request/>

<xml version="1.0" encoding="UTF-8">.....</xml>

La diferencia es evidente, en el segundo caso, al contectar con el servidor simplemente le decimos <policy-file-request/> y nos debe devolver el xml del crossdomain.xml. No es el protocolo HTTP, es uno inventado que sólo responde a una petición.

El puerto no tiene porqué ser el 843, puedes modificarlo, pero Adobe pretende que 843 sea el estándar y, de hecho, está solicitando su homologación con el IANA.

Desde Adobe incluso se han puesto cachondos y te dicen que lo ideal es modificar tu aplicación en el servidor para que acepte la llamada <policy-file-request/> y responda con el XML, así no necesitarás una aplicación adicional. Pues nada chicos, a modificar todos los servidores smtp, pop, irc (nuestro caso), ftp… para que acepten la llamada. ¡Qué ridículo!

Como soy un tío enrollado os paso la solución completa. En esta URL tenéis un ejemplo de servidor en TCL/TK que funciona a la perfección y no consume recursos. Configura el puerto y la ruta al crossdomain.xml y a funcionar. Recuerda que si el puerto es inferior al 1024 deberá ser un usuario privilegiado quién ejecute la aplicación, deberías, entonces, enjaularla (chroot) para evitar posibles puertas. En realidad lo que hacemos es responder con el crossdomain.xml a cualquier petición que nos hagan, sea la correcta o no, ¿qué mas da? No vamos a hacer absolutamente nada más con ese puerto. Tendréis que preocuparos también de que se quede residente como demonio en vuestro servidor y, además, habrá que comprobar periódicamente que sigue a la escucha. Para esto recomiendo hacer un script que haga llamadas reales y espere el código XML necesario, comprobar simplemente con un netstat que el servidor ocupa el puerto no nos salvará de que el servidor se quede zombie. Por supuesto no olvides abrir tu firewall a ese puerto.

Actualización.
Acabo de terminar el artículo y a través de flexcoders me llega este enlace, mucho más claro y sencillo que la ayuda inicial. Ah! y con ejemplos de servidores en Perl y Python. En líneas generals viene a contar lo mismo que acabo de contar yo :P.

Hace un tiempo necesitábamos crear un sistema de compras a través de PayPal con la particularidad de que teníamos recibir confirmación instantánea del pago para reflejar esas compras al usuario. Esta era la diferencia principal respecto de un carro de compra de una web donde vendes algo físicamente, en este caso no necesitas saber el estado de una compra, cuando el equipo de almacén prepare el pedido ya comprobará si se ha realizado el pago antes de servirlo. Nuestro caso es más complicado. Vendemos servicios que pueden ser suscripciones, créditos de uso en la web, servicios premium, acceso a zonas privadas… todo este tipo de opciones donde el usuario, después de pagar, vuelve a tu web para disfrutar de los servicios que ha comprado.

Al querer cobrar a través de PayPal tienes dos opciones, o creas botones estáticos (Comprar Ahora) desde la web de PayPal o generas los tuyos propios. El problema de crearlos estáticos es que debes crear uno por cada usuario y para cada servicio que necesites vender, algo absurdo para el caso que tratamos ya que estarías ante miles de botones. Al generar los tuyos propios puedes hacerlos normales o seguros, para que no se puedan modificar por el camino. Este es el método que deberías utilizar normalmente ya que, en los normales, un usuario experimentado puede modificar el importe a cobrar, algo que no deseas que ocurra.

Para que el sistema funcionase bien deberíamos recibir en una URL las compras realizadas de alguna manera que nos permitiese identificar al usuario que habia hecho la compra para añadirle los servicios en cuestión. La solución es crear botones firmados online utilizando como identificador de producto de compra el idUsuario de tu base de datos, de esta forma las confirmaciones de compra te indican el usuario al que pertenecen y ya puedas darle los servicios por los que ha pagado. Puedes utilizar combinaciones más elaboradas para reutilizar el sistema para distintos productos, por ejemplo idUsuario-idServicio (12345-3). Al recibirlo, con dividir la cadena por el guión ya tienes todo lo necesario. En nuestro caso había varios tipos de servicio pero se indentificaban por el coste del mismo, con lo cual con el identificador de usuario teníamos suficiente.

Aparentemente es sencillo el proceso, pero se complica ya que la documentación, a pesar de ser extensa, no esta del todo claro. Por un lado no está nada claro cómo configurar tu cuenta de PayPal para tener el sistema completo y por otro es bastante lioso el modo de crear los botones y recibir las confirmaciones. Vamos a explicarlo detalladamente ya que es un interesante ejercicio de programación en PHP.

Configurando la cuenta de PayPal

Lo primero que tienes que hacer es crear un certificado público X.509, único sistema que acepta PayPal.

Las instrucciones detallas las tienes aquí. básicamente necesitas tener openssl funcionando, cualquier sistema Linux lo tendrá instalado y sino tienes versiones para Windows.

Con esto generamos primero la clave privada y a continuación el certificado público X.509 de esa clave. Es importante el parámetro -days, lo hemos puesto a 10 años para no tener problemas. En mi caso, la primera vez puse 365 días tal como viene en el ejemplo y al año dejó de funcionar sin que te dieses cuenta, fueron los usuarios los que nos avisaron. Guarda los dos archivos, my-prvkey.pem y my-pubcert.pem pues los necesitaremos a continuación.

Ya tenemos nuestro certificado preparado. Ahora debemos subirlo a PayPal para que sepa desencriptar nuestros botones. En tu cuenta de PayPal debes ir a:

Perfil->Configuración de pago codificado

Desde ahí, por un lado descargas el certificado público de PayPal, lo necesitaremos para codificar nuestros botones, y por otro subes tu certificado público que hemos llamado my-pubcert.pem. Obtendrás un ID de certificado, apúntatelo.

Si todo ha ido bien, ahora debemos configurar la cuenta para que PayPal sólamente acepte botones firmados, de manera que nadie pueda suplantar nuestra identidad con botones a otros precios, un detalle muy importante. Vamos entonces a:

Perfil->Preferencias de pago en el sitio Web

Primero activas Transferencia de datos de pago y te copias el Código Personal de Identidad que te indica, lo necesitaremos más adelante. A continuación, en la sección Pagos en el sitio Web codificado activamos la opción Bloquear pago en el sitio Web no codificado. Como véis no estaba tan claro el proceso.

Este paso no es obligatorio, pero haciéndolo conseguimos que el usuario vuelva a tu web una vez haya realizado el pago y, si ha sido correcto, tenga ya sus servicios disponibles. Activa la opción Retroceso automático e indica la URL de devolución, es decir, la URL donde será devuelto tu cliente, por ejemplo: http://www.tudominio.com/index.php?accion=creditos_paypalok

Finalmente activaremos la opción que nos permitirá recibir notificaciones de pagos online. Para ello vamos a:

Perfil->Preferencias de Notificación de pago instantánea

Y activaremos la notificación indicando la URL donde las vamos a recibir, por ejemplo, http://www.tudominio.com/secure/paypal/ipn.php.

Si has llegado a este punto, ya tienes todo lo necesario para comenzar con el código. Como recordatorio, necesitas:

• Tu clave privada, my-prvkey.pem.
• Tu certificado público, my-pubcert.pem.
• Tu ID de certificado en PayPal
• Tu Código Personal de Identidad
• Certificado público de Paypal, paypal_cert_pem.txt.

Nos quedan, entonces, tres tareas pendientes:

• Crear botones de compra
• Crear el script de recepción de cobros realizados
• Crear el script de vuelta después de una compra

Creando los botones

Comenzamos con el código. El único requerimiento es que tu instalación de PHP debe tener configurada la extensión openssl imprescindible para trabajar con los certificados. Con esta clase que encontré en su momento (me costó bastante localizar algo sencillo) tienes todo el proceso automatizado, sólo debes preocuparte por indicarle los datos que hemos ido guardando, los certificados y el ID del tu certificado en PayPal, simple ¿no?.

El código es bastante claro.
Ya lo tenemos, $form5 contiene el código de tu botón.
Los parámetros importantes son:

• item_name: informativo, para que tu cliente sepa lo que compra. Por ejemplo: compra de suscripción a noticias.
• item_number: Aquí configuramos el idUsuario de tu cliente en tu base de datos, así sabes quién compra.
• amount: Precio que le cobras, en este caso 5 euros.

Modifica estos y los demás parámetros para reflejar tus opciones y adecuarlos a tu aplicación. Al sacar el código de $form5 en tu página tienes listo el sistema de compra.

Recibiendo las notificaciones

La recepción de notificaciones es la piedra angular del sistema para estar seguros de que un cliente ha pagado por un servicio. PayPal ha pensado que puedes llegar a tener problamas temporales de conectividad que te impidan reconocer una compra, con lo cual obliga a que le confirmes que has recibido la confirmación reenviándole los mismos parámetros que te ha enviado. Un sistema curioso pero efectivo, no puedes suplantarlo puesto que no sabes los identificadores de operación que te va a enviar, así que sólo el receptor de la confirmación podrá confirmar la recepción. Lo que hacemos es crear una solicitud HTTP POST con todos los parámetros que nos ha enviado y se la devolvemos a PayPal. Si todo ha ido bien recibiremos un VERIFIED y podremos aceptar esa transaccion como válida y hacer el procesado que estimemos oportuno, comenzando por comprobar la duplicidad de la transacción ya que PayPal podría estar reenviándola y terminando por otorgar al usuario el servicio por el que ha pagado.

Ya hemos recibido la confirmación de pago de PayPal, la hemos guardado en nuestra base de datos y le hemos dado a nuestro cliente su servicio, este proceso será distinto para cada aplicación así que no lo explicaremos, haz el tuyo como creas oportuno. Lo que sí te recomiendo es guardar una tabla con todas las transacciones recibidas a modo de log, te servirá para buscar errores o reclamaciones de usuarios.

Cabe señalar que PayPal sólamente lanza este proceso con las transacciones correctas, aquellas se que se han cobrado correctamente, nunca con las erróneas (falta de saldo, tarjeta incorrecta, etc.).

Devolviendo al usuario a nuestra web

Una vez que el usuario ha terminado su transacción en PayPal deberíamos enviarlo de nuevo a nuestra web para que comience a utilizar el servicio por el que ha pagado. Para ello PayPal nos provee del método Retroceso automático que mandará al usuario a la URL que le hayamos especificado indicando los parámetros de la transacción, entre ellos si ha sido válida o no. PayPal, además, ha pensado en todo: no puedo devolver a un usuario a la web de origen sin antes haberle comunicado el éxito de la transacción (el paso anterior). Así el mecanismo de PayPal retrasa el reenvío del usuario unos segundos para intentar que tu servidor ya esté informado de esa transacción. Simplemente genial. Ahora utilizaremos tu código personal de identidad que hemos obtenido al configurar la cuenta en PayPal. Es el parámetro que en el código llamamos $auth_token.

El proceso es parecido a la confirmación de transacciones. Debemos comunicar a PayPal que hemos recibido al petición de vuelta del usuario y que somos nosotros quién lo hacemos, sólo así nos dará los datos de la transacción. De nuevo un método curioso. Para hacerlo, nos indica por GET el identificador de la transacción y debemos devolvérselo junto a nuestro código personal de identidad mediante otra llamada HTTP POST, de este modo nos aseguramos de que somos nosotros quienes solicitamos la información. Si todo ha sido correcto PayPal nos devuelve los datos de la transacción como respuesta a esta llamada. Otra vez genial el sistema.

¿Por qué no hacerlo como en el paso anterior? Sencillo, el método IPN es transparence al usuario, es una llamada interna que hacen los sistemas de PayPal a los tuyos, nadie va a saber que datos se envían, con lo cual puedes utilizar esos datos para confirmar la transacción. En el método de retroceso, esta URL llega al usuario, con lo que podría hacer cosas que no deseamos con los datos, con lo que no nos envían nada en la solicitud, simplemente el identificador de la transacción para que internamente nosotros pidamos los datos validándonos con el código personal.

La respuesta que recibimos es una respuesta HTTP estandar, con lo cual debemos ser conscientes de que vamos a recibir primero todas las cabeceras HTTP de la respuesta, después dos saltos de línea y a continuación la respuesta propiamente dicha. En una petición normal esta respuesta sería el código HTML de tu página, pero en este caso recibimos la lista de parámetros de la transacción, uno por línea y del tipo:

parámetro1=valor1
parámetro2=valor2
...

El código tiene esto en cuenta y, al recoger la respuesta, regenera la lista de parámetros/valores recibidos con lo que tenemos los datos necesarios.
La primera línea va a ser SUCESS ó FAIL, está claro el dato, una indica que la transacción ha sido válida y la otra que no. Obviamente debes informar al usuario de que la operación ha sido correcta y que ya tiene su servicio disponible.

Si has entendido bien todo lo explicado hasta ahora, verás que los sistemas de recepción de notificaciones y retroceso automático son muy similares, de hecho puedes utilizar este último para validar las transacciones de igual modo que con el primero y no necesitarías éste. Pero ¿qué ocurriría si sólo implementas el segundo y el usuario cierra la ventana del pago mientras está en esos segundos de espera antes de reenviarlo a tu web? Simplemente que el usuario no tendría su servicio disponible ya que nunca ha llegado a realizar el proceso del Retroceso automático. Para solucionarlo implementamos los dos. Con el primero aseguramos que la mayoría de transacciones válidas son procesadas y los servicios otorgados al cliente, con la segunda, además de informar al cliente del éxito o fracaso se su operación, tenemos un sistema de redundancia por si el primer procedimiento hubiese fallado. Como en ámbos tenemos el identificador de transacción, simplemente debemos comprobar que esa transacción ya existe y no hacer nada o procesarla si no existe.

Y eso es todo amigos. Con esto hemos aprendido a tener un sistema de compras de servicios seguro y dinámico en PayPal. Cómo habéis podido observar, el procedimiento es bastante complejo en cuanto a configuración y desarrollo, pero es muy interesante el estudio del resultado para tener una idea más amplia de como implementar sistemas seguros.

Tenía una deuda pendiente con Morella. Llevaba mucho tiempo con ganas de ir y al final lo hemos conseguido.

Morella está situada al norte de la provincia de Castellón, a la altura de Vinaroz pero al interior, casi ya en Teruel, en plena zona del Maestrazgo. Fue declarada conjunto Histórico-Artístico en 1963 y actualmente trabaja para su reconocimiento por la UNESCO como Patrimonio de la Humanidad.

Fijáos en la impresionante panorámica que te recibe nada mas llegar a Morella. Se puede apreciar la muralla medieval que rodea la ciudad coronada con el castillo.

Morella es de esos lugares en los que te sientes transportado a épocas pasadas. Cabe decir que esta ciudad ha sufrido todas las invasiones y guerras habidas y por haber: celtas, griegos, romanos, bereberes, reconquista, Guerra de Sucesión, independencia contra las tropas napoleónicas, guerras Carlistas… No se ha librado de nada. Imaginaos la historia que encierran sus rincones.

Si a algo le he de poner pegas es al acceso al Convento de San Francisco y al Castillo. Se realiza desde el propio Convento, pero apenas hay un pequeño cartel colgado de un caballete de pintor en la puerta. Si no es porque vimos salir gente, no nos hubiésemos acercado. Por 2€ tienes acceso a los dos edificios. Eso sí, prepárate para caminar y caminar, la subida al castillo, pronunciada y más larga de lo que parece, se hace pesada. El paseo completo llevará alrededor de 45 minutos y cuando ya crees que estás cerca de la Plaza de Armas te encuentras con un largo camino de escaleras que te hace llegar derrotado.

Del castillo cabe decir que fue construido aprovechando la propia montaña, con varias dependencias excavadas en la propia roca de la montaña, una de ellas los calabozos.

Sant Mateu

Aprovechando el viaje de vuelta y por consejo de Álvaro, alias Rachandras, hicimos una parada en Sant Mateu, declarado Monumento Nacional. La verdad, he de decirlo, esperábamos más, y, si tienes en cuenta que bajábamos de Morella, te parece menos aún de lo que en realidad es. Aún así, es un buen lugar para hacer una parada en el camino.

Lo mejor, sin duda, las murallas medievales que caen hacia el lado del río y fueron restauradas en 1996.

Y eso es todo por hoy, de vuelta a casa a descansar un poco que al día siguiente tocaba trabajar.

Si hay una herramienta de diseño de bases de datos conocida dentro del software libre, ésta es, sin duda, DBDesigner. Si a estas alturas no la conoces es que no diseñas bases de datos o lo haces sobre la marcha, tu sabrás lo que haces :).

Hace algunos años MySQL compró Fabforce, la empresa que desarrollaba aquél software. No he podido encontrar la fecha exacta, pero ya en agosto de 2005 se anunciaba el lanzamiento de la primera alpha de su sucesor, MySQL Workbench. Obviamente algo tiene que haber trastocado los planes iniciales de lanzamiento puesto que en abril de 2008 estamos todavía con versiones beta, eso sí, en estado ya Release Candidate. Cabe señalar que la última versión de DBDesigner es nada más y nada menos que de 2003, y aún así se sigue utilizando.

Lo interesante de este nuevo producto es que está basado completamente en su antecesor, el equipo de desarrollo es exactamente el mismo e incluso han dejado una opción para importar diseños creados con DBDesigner.

Tal como indican en el antiguo foro del programa, fabForce mantendrá el sitio web de DBDesigner hasta que se publique la primera versión de MySQL Workbench, a partir de ese momento desaparecerá. Parece que el momento está cerca.

Mi impresión es que, a pesar de los planes que tenían para el producto después de la compra por MySQL, se antepusieron productos nuevos. Nada más ni nada menos que el conjunto de nuevas utilidades bajo entorno gráfico que aparecieron hace un par de años: MySQL Administrator, QueryBrowser y Migration Toolkit, todas ellas desarrolladas por el equipo de DBDesigner, fantásticas utilidades por cierto. Recordad que hasta entonces no había ninguna herramienta visual oficial para trabajar con MySQL, las que había eran todas de terceros, una clara desventaja dentro del sector de pequeña y mediana empresa en el que pretendían entrar después del gran éxito en entornos web.

¿Qué hacía de especial a DBDesigner?

Lo primero y fundamental, una herramienta visual para modelar bases de datos y crear diagramas e/r al más puro estilo de Oracle DBDesigner o los Diagramas de SQL Server. A esto hay que añadir las increíbles funciones de sincronización e ingeniería inversa. La primera permite reflejar automáticamente en tu diseño los cambios realizados sobre tu base de datos en el servidor y viceversa, no es necesario crear toda la base de datos de nuevo. La segunda permite leer una base de datos completa desde tu servidor y crear automáticamente el esquema. Si no los has probado no sabes lo que te pierdes.

Otra de las funcionalidades era la posibilidad de crear plugins para extender sus utilidades. Traía algunos de serie, uno de ellos, SimpleWebFront, permitía generar una aplicación CRUD completa de tu diseño en PHP sin tocar una sóla línea de código.

Finalmente debemos señalar que se podía trabajar ya en aquel momento con otros gestores de bases de datos, Oracle, MSSQL, SQLLite, ODBC…

¿Qué hay de nuevo?

Han tenido que pasar cinco años para que veamos una nueva versión de una de las mejores herramientas que han existido para MySQL. Algo nuevo tiene que aportar. Básicamente se ha mantenido la esencia de la antigua aplicación modernizando la interfaz y añadiendo algunas opciones nuevas.

La mala noticia es que saldrán dos versiones, la de comunidad, gratuita, y la comercial. La diferencia fundamental es que las opciones de sincronización e ingeniería inversa contra el servidor se han dejado para la versión de pago, pero aparece una opción en la libre que permite hacer lo mismo con archivos SQL en vez de en vivo. La mayoría de nuevas funciones se incluirán en la versión comercial, pero os aseguro que no son indispensables, hablamos distintas opciones de debug y notación.

Entre los planes de MySQL figuran crear una comunidad de desarrolladores de extensiones y plugins que permitan nuevas opciones, con lo cual no sería de extrañar que la primera en aparecer fuese una versión libre de las opciones en vivo antes comentadas.

Lo mejor es que la pruebes y obtengas tu propias conclusiones. Para mi siempre es el primer paso al preparar una nueva aplicación. Si tienes un buen modelo visual es muy sencillo preparar tus clases del modelo o decirle a alguien lo que tiene que hacer sin tener que estar revisando continuamente la estructura desde el servidor.

La versión final está al caer. Mientras tanto puedes descargar la última beta desde aquí.