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.

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