Español | Inglés

He aquí la primera versión pública del captcha gráfico que desarrollé para el formulario de registro de Blogs Teoriza.

• Prueba online! [en Español (de España) e Inglés]

Introducción:

Cuando me enfrenté al gran desarrollo del sistema de usuarios quise destacar de los demás formularios. Ante todo quería que fuese usable, sencillo y al grano. En definitiva minimalista, fiel a mi tendencia evidente.

Por supuesto el formulario de registro debe tener un control captcha, es decir, un obstáculo que solo es capaz de sortear un humano. Solo así puede estar protegido un formulario en Internet. Y aquí entra en juego este programa que hoy tengo el placer hacer público, muy fácil de implementar.

Descripción:

Animal Captcha es un pequeño programa en lenguaje PHP, orientado para su uso en páginas web, que permite adjuntar a un formulario una imagen aleatoria de un animal que cualquier humano conoce, y sin embargo un robot es incapaz de identificar.

Ventajas:

• Belleza: es más agradable ver una foto de un animal que un código alfanumérico.
• Rapidez: los usuarios ahorran tiempo, ya que se tarda mucho menos en identificar y escribir un animal conocido que un código aleatorio de 5 cifras, por ejemplo.
• Efectividad: los usuarios aciertan con más probabilidad, aportando una excelente experiencia.
• Seguridad: esta es la razón principal, en Internet hay desarrollos que consiguen resolver algunos captchas de códigos alfanuméricos, con cierto éxito. Sin embargo, ojalá pudiese una máquina identificar a un animal! Es imposible teóricamente. Aunque la aleatorizacion de imágenes, para que sean únicas, puede no ser firme.
• Multi-lenguaje: permite responder en varios idiomas, incluso varios nombres para un mismo animal (ejemplo: halcón y águila son equivalentes).

Una buena y una mala noticia.

La buena es que la gente de la comunidad Hispalug ha sido capaz de organizar el evento de Lego más importante que he visto nunca en España, la mala es ya ha ocurrido. Fue en Cataluña, el 8 y 9 de Diciembre del 2007.

En una cruzada con mi segunda etapa de LEGO descubrí la comunidad Hispalug. Es un punto de reunión de AFOL’s (aficionados adultos de LEGO), lleno de artistas en la materia y organizados en Internet. Un gran hallazgo, porque gracias a encontrar ese rincón me empezó a picar la curiosidad del LEGO lo cual me ha hecho recuperar mis antiguas piezas, organizarlas y… comprar más!

Cuando descubrí esta comunidad conocí el evento Hispabrick (2007) que organizaron en un centro comercial durante 2 días. Allí expusieron dioramas de ciudades enteras, trenes y un sin fin de MOC’s (creaciones propias) y Sets montados (cajas de LEGO).

Con la intención de dar difusión y apoyo a las futuras Hispabrick’s (en 2008 otra, confirmado) he creado el grupo Hispabrick en Flickr. Y con el permiso de sus autores he subido un monton de fotos de la Hispabrick. El objetivo de mi iniciativa es hacer que se vean mas cómodamente y con potentes posibilidades (comentarios, etiquetas, usuarios) para disfrute de todos vosotros.

He aquí algunas fotos de Hispabrick 2007! (recordar que no soy el autor de las fotos ni de los modelos, en cada foto está especificado)

Nave espacial SULACO II, uno de los MOC’s más grandes del mundo, construido por manticore durante meses. Es tan grande que su tamaño NO queda reflejado en esta foto. Dificilisimo modelo tanto en su construcción, transporte, suministro de bricks (piezas)… hasta hacerle una foto es dificil! Toda la historia la encontrarás en este apasionante hilo.

GBC, o máquina de movimiento perpetuo. Sistema que consigue mover las pelotas en un circuito cerrado de forma cíclica. Para la próxima Hispabrick 2008 se ha propuesto hacer un GBC mucho mas grande, gracias al exito de este modelo de Jetro.

Uno de tantos dioramas de temas City y Train expuestos en la Hispabrick, todos los sets y elementos son aportes de los miembros de esta grandisima comunidad.

+ Fotos!

Si después de leer todo esto te sientes identificado y crees que eres un AFOL, no dudes ni un momento en registrarte en la comunidad Hispalug y presentarte en el foro de Bienvenida! Recomendadisimo!

Enlaces interesantes:

• Hispalug (foro)
• Hispabrick 2007
• Grupo en Flickr de Hispabrick (recomendado para echar un vistazo!)
• Más fotos de Hispabrick
• Foro, zona de bienvenida (si eres un fan de LEGO serás bienvenido!)

Segunda parte de una serie de artículos divulgativos sobre una de mis aficiones de mi trabajo, optimizar la carga web.

Parte II: Gzip estático

El único problema que tiene la compresión con Gzip (explicado en la Parte I) es que sacrifica consumo de CPU a cambio de obtener archivos 4 o 9 veces mas pequeños. En mi opinion realmente ahorra CPU, sin embargo existe esa delgada linea de rendimiento.

La solución que he desarrollado soluciona por completo este problema.

Ventajas:

1. Elimina la necesidad de comprimir Gzip on-the-flight (en cada petición). Solo se hará una sola vez, cuando se genere una caché del archivo.
2. Ahorra de 4 a 9 veces espacio en disco, ya que reduce el tamaño de los archivos. Para una caché es magnifico, como explicaré en el ejemplo práctico.
3. Permite activar el nivel más potente de compresión (9) sin ningún miedo a colapso, ahorrando un poco más de espacio en disco, CPU por transferir más rápido y tiempo de carga.
4. Además conserva todas las ventajas del Gzip (explicadas extensamente en la Parte I)

En qué consiste:

Consiste en guardar una copia pre-comprimida del archivo a transferir. El concepto es sencillo, evita la necesidad de comprimirlo al vuelo (on-the-flight) cada vez que se pide ese archivo de texto plano como ocurriría con Gzip normal.

Esto alivia radicalmente el consumo de CPU conservando, incluso aumentando la ventaja de comprimir a más nivel.

Ejemplo práctico:

La herramienta más usada de Blogs Teoriza es el Caché Web. Para el que no lo conozca es una sencilla aplicación web que genera una copia en texto plano de una pagina web dada.

Ahora funciona con este nuevo método. Con ello doy un paso de gigante en cuanto a rendimiento, uno más ya que conseguí desarrollarlo sin uso de MySQL y con apenas 10 lineas para presentar cada caché. Sin embargo permanecia la poca ventaja del gasto de CPU al comprimir las paginas.

Ahora las comprime una sola vez, cuando genera cada caché. Sirviendolas sin apenas procesar. Ligerísimo.

Antes aseguraba que aguantaba cualquier avalancha de visitas extremas… ahora ya doy por sentado que jamás conseguirán colapsarlo.

Ejemplo del resultado:

• Caché de este mismo post, como puede verse perfectamente aquí.
• Corresponde a este archivo Gzipeado que probablemente no verás bien porque esta comprimido.

Donde aplicarlo:

Recomiendo usar esta metodología para los siguientes casos:

• Cachés de cualquier tipo. (especialmente útil al ahorrar también tremendo espacio en disco)
• CSS y javascript: en la mayoría de los casos estos archivos son totalmente estáticos y rara vez son modificados. Por lo tanto son candidatos perfectos a ser pre-gzipeados y ahorrar así enormes gastos de CPU.
• Cualquier archivo en general que cumpla estas tres condiciones:
  • Texto plano. (html, css, javascript…)
    
  • Contenido estático (cuando no tiene variables, cuidado con formularios).
  • Pocas modificaciones.

Cómo aplicarlo:

La clave del asunto es la función gzencode($datos, 9) para PHP.

Usándola de la siguiente manera se crea una copia de un archivo con terminación .gz y comprimido con Gzip al máximo en el disco duro del servidor.

<?php
if ($_GET[”archivo”]) {
$file = $_GET[”archivo”];
$data = implode(”", file($file));
$gzdata = gzencode($data, 9);
$fp = fopen($file . “.gz”, “w”);
fwrite($fp, $gzdata);
fclose($fp);
}
?>

[Aviso: este código es una herramienta sencillísima de ejemplo para generar archivos pre-gzipeados.]

Pegando este código en un archivo PHP, por ejemplo gziper.php y dando los permisos de escritura (777) correspondientes vía FTP podrémos crear versiones Gzipeadas de cualquier archivo que se encuentre en ese directorio ejecutandolo de la siguiente forma:

http://www.tuweb!.es/gziper.php?archivo=style.css

Con esto obtendremos la creación de un nuevo archivo style.css.gz pre-comprimido con Gzip.

Una vez creado el archivo, recomiendo enmascararlo con .htaccess. También se puede mejorar un poco la cosa, detectando si el navegador acepta Gzip para descomprimir el archivo en su defecto.

Otro punto a tener en cuenta es que hay que modificar la cabecera del archivo. Se resuelve desde .htaccess o fácilmente añadiendo esta linea PHP al principio del código:

header(”Content-Encoding: gzip”);

@include(”style.css.gz”);

Y eso es todo para una interesante Parte II, espero que sirva a la comunidad.

Este es el primer artículo de una serie de métodos que he conseguido implementar con éxito ahorrando CPU y transferencia, haciendo que mis servicios web soporten más lectores online, sirviendo más rápido y con menos hardware.

Parte I: Compresión Gzip

Este método ya es bastante familiar, casi todo el mundo que lo necesita realmente lo utiliza, pero no lo aprovecha al máximo.

La compresión Gzip hace que el servidor comprime los archivos de texto antes de transferirlos, reduciendo su tamaño entre 5 y 9 veces el original. Como por arte de magia consigue que la información que envía el servidor hacia el cliente sea notablemente menor.

Por ejemplo, un archivo que pesa 68 Kb gzipeado se queda en 9 Kb ahorrando mas de 7 veces el tamaño

Conseguimos de un plumazo tres enormes ventajas:

1. Mayor capacidad de carga: ahorrando tiempo en transferir archivos se minimiza la carga de CPU y RAM del servidor.
2. Mejor velocidad de carga: al transferir menos información las paginas cargarán bastante más rápido, la experiencia de tus usuarios será mejor y evade la necesidad de que el server esté en el país objetivo.
3. Considerable ahorro de dinero: el gasto elemental de un servidor web es la transferencia mensual, esta se mide en Gb/mes. Comprimiendo con Gzip el ahorro será tremendo.

[Curiosidad: existe una supuesta delgada linea de eficiencia, algunos dicen que activando Gzip on-the-flight se gasta más CPU que en modo normal. Por mi experiencia pienso que se ahorra CPU, sin embargo en la Parte II explicaré un método muy interesante para hace Gzip estáticamente (mas magia)]

Puede parecer trivial, ya que mucha gente lo conoce y lo aplica. Sin embargo mi truco “avanzado” es que recomiendo activar Gzip en TODOS los archivos planos y no solo a las páginas HTML como veo en la mayoría de webs. Cualquier archivo plano se debe gzipear, me refiero especialmente a archivos html, estilos css y archivos javascript. El ahorro triple será más significativo aún.

Distintos métodos para implementar Gzip:

• Con Wordpress: es fácil, Opciones > Lectura > Marcar opción Gzip (abajo). Sin embargo el error común es olvidarse aquí del tema, un error porque con esta opción solo consigues comprimir las páginas html olvidandote del archivo css y posibles javascripts.
• Con PHP: para comprimir una página html donde puedes ejecutar PHP has de añadir estas lineas de código al principio de cualquier proceso:
  

  <?php ob_start(”ob_gzhandler”); ?>

  Al final de cualquier código:

  <?php ob_end_flush(); ?>

• Para CSS y javascript (recomendado)
  En .htaccess

  AddHandler application/x-httpd-php .css .js
  php_value auto_prepend_file /home/… RUTA LOCAL …/public_html/gzip-start.php
  php_value auto_append_file /home/… RUTA LOCAL …/public_html/gzip-end.php
  

  En gzip-start.php

  <?php ob_start(”ob_gzhandler”); ?>
  

  En gzip-end.php

  <?php ob_end_flush(); ?>

• Combinando htaccess + PHP: poner en .htaccess:
  

  php_flag zlib.output_compression on
  #Con el numero se controla el nivel de compresion donde 0 es null y 9 el maximo
  php_value zlib.output_compression_level 5
  AddHandler application/x-httpd-php .css .js
  #Poner una ruta local cualquiera hacia un archivo php
  php_value auto_prepend_file /home/…/public_html/gzip-head.php

  Crear el archivo gzip-head.php con el siguiente contenido:

  <?php
  $pathinfo = pathinfo($PHP_SELF);
  $extension = $pathinfo[”extension”];
  if ($extension == “css”) {header(”Content-type: text/css”);}
  if ($extension == “js”) {header(”Content-type: text/javascript”);}
  ?>

Y esto es todo…

En la Parte II explico un interesantísimo metodo para comprimir con Gzip estáticamente, en vez de on-the-flight gastando 0 CPU en comprimir cada pagina, completando el circulo de eficiencia perfecta.

Mi tío me enseñó un día esta moneda antigua que conservaba desde hacía mucho tiempo. Me dijo que posiblemente tiene un gran valor por su antigüedad y rareza.

(Pulsa en la foto para ampliar a máxima resolución)
Aquí comienza la búsqueda y captura. Es un reto por simple curiosidad, me gustaría averiguar de que año es, qué es realmente, que indican sus signos y cuanto valor tiene.[Actualización: gracias a mi colega posavasos (experto en buscar) que encontró en ebay más monedas similares y la correspondiente información que complemento a continuación. También gracias a Edu por la traducción.]

Info:

• Es una moneda de Marruecos llamada falus (también felus), corresponde al valor de 3 falus (identificado porque tiene orlas a rayas y es de mayor tamaño que la de 2 falus).
• El número inscrito en el anverso indica el año en árabe (1288 A.H.) que corresponde al año 1871 D.C. de nuestra era.
• Es de bronce.
• Acuñada por Mohamed IV (1859-1873, sultán de Marruecos, dinastía Alauita).
• Una Estrella de David en el reverso.
• Es bastante común en España y Andorra (dicho por varios expertos en foros y concuerda con la cantidad de monedas en eBay).
• Su estado de conservación es muy bueno en comparación con las demás monedas idénticas que he encontrado.
• Se venden en eBay más monedas muy similares cuyo valor parece ser pequeño :(
• Ejemplar idéntico vendido en eBay, aunque en peor estado.
• Más info y más info.

¿Alguien me puede ayudar por favor? (moneda perfectamente identificada en menos de 4 horas, gracias a todos vosotros)

Surfeando por Internet, como quien dice, he descubierto algo que me parece increíble y de haberlo descubierto de niño me habría alucinado completamente.

Resulta que hay una comunidad de radioaficionados a los satélites, pudiéndose utilizar algunos satélites para intercambiar comunicaciones.

Explicaré los conceptos que he aprendido. Quiero aclarar que no he tenido la suerte de comprobar todo esto de forma práctica, pero he leído suficientes teorías como para hacer esta pequeña introducción superficial.

Los satélites de radioaficionado permiten a cualquiera enviar y recibir voz o información (fonía o packets). Para un radioaficionado un satélite es como un espejo o una antena repetidora terrestre. Este recibe y vuelve a emitir hacia la Tierra. Solo hay un canal donde se realizan todas las comunicaciones entre los aficionados que estén escuchando.

La cobertura de los satélites tiene grandes limitaciones. Para empezar no hay ninguno geoestacionario (confirmado), todos se mueven en órbita alrededor de la Tierra. Esto significa que no siempre están disponibles, ni mucho menos. Es más, dado que normalmente giran 5 o 6 veces la Tierra cada día el periodo de cobertura sobre España, por ejemplo, puede ser de entre 10 y 30 minutos por ejemplo. Los que hacen órbitas elípticas permiten ampliar este tiempo un poco más, pero su frecuencia es menor.

Por supuesto los satélites no se pueden dirigir ni nada parecido, eso es un mito de las películas. Los geoestacionarios están inmóviles porque se han colocado (y empujado) con precisión girando al unísono con la Tierra, es el caso del los satélites de la tele. Las parabólicas apuntan siempre hacia el ecuador, en el caso de los radioaficionados tendrían que moverse constantemente.

El equipo necesario para realizar comunicaciones con satélites es sorprendentemente, solo hace falta un equipo VHF/UHF y una antena larga direccional, con el mayor numero de elementos para dar la mayor ganancia posible. También se necesita una licencia que se obtiene previo pago más un pequeño examen.

El punto clave importantísimo (a parte de conocer las pautas de comunicación y las frecuencias) es saber donde se encuentran los satélites de radioaficionado en tiempo real. Esto lo podemos hacer cualquiera gracias a programas como el WXtrack (mi preferido) o SatScape y por supuesto a los keplerianos.

Simplificando: los keplerianos son parámetros (en texto plano) que indican con dos vectores temporales la dirección, posición y altitud de un satélite en el tiempo. Esto significa que teniendo los keplerianos de un satélite y el programa adecuado podrás saber donde se encuentra en cualquier momento! (aunque hay que mantener estos elementos keplerianos actualizados una vez al mes para evitar sorpresas).

Un ejemplo de elementos keplerianos, en concreto de la estación Espacial Internacional (ISS, tripulada permanentemente) que curiosamente tiene un repetidor para radioaficionados funcionando actualmente en 145.825 MHz:

ISS
1 25544U 98067A 07262.51637699 .00020000 00000-0 20000-3 0 9002
2 25544 51.6353 337.1650 0009650 22.0216 338.1362 15.76879361 25661

El resultado es el siguiente:

Esta captura muestra mi recopilación de todos los keplerianos que he podido encontrar, introducidos en el WXtrack y visualizados en tiempo real. Resulta evidente que los que están en linea son los geoestacionarios, como los Meteosat.

Tal es la fascinación con los satélites (me alegra descubrir que no soy el único) que se pueden avisar algunos satélites a simple vista si se sabe hacia donde mirar y se tienen las condiciones adecuadas.

Enlaces interesantes:

• Estatus de satélites de radioaficionado junto con sus datos técnicos.
• La biblia de las introducciones a los satélites radioaficionados.
• WXtrack. (necesité instalar esta librería para que funcionase en mi XP)
• SatSpace. Otro tracker de satélites, parece muy vistoso pero no me gusta su interfaz.
• Información técnica sobre adaptación de antenas para uso con satélites.

[Nota: Dado que no soy un aficionado de la materia, simplemente un curioso ocasional, seguiré cualquier comentario que se haga en este post, haciendo las pertinentes correcciones. Si ves algún error avísame!]

Los discos duros tienen los días contados. Serán sustituidos por una nueva generación de dispositivos de almacenamiento basados en la tecnología SSD (Discos de estado solido). Funcionan de forma similar a una memoria RAM, no tienen mecanismos ni platos magnéticos girando a toda velocidad.

Veo un gran avance en la tecnología SSD especialmente en un par de cualidades (en adelante explico) en las que creo que puede provocar un salto en cuanto a rendimiento del hardware.

Siempre he soñado con desarrollar un Buscador de Internet, empezando en mi propio garaje y todo eso (y nunca pararé hasta conseguirlo). Sin embargo, hoy en día no es posible. Haría falta una millonaria inversión para solo intentar alcanzar a Google, y luego habría que intentar ser mejor que ellos con menos recursos, lo cual veo improbable.

Sin embargo en los discos SSD hay una oportunidad para alcanzar al gigante de la información.

Actualmente Google funciona gracias a cientos de miles de ordenadores. Estos almacenan y procesan la información para devolver las búsquedas web. El punto clave para conseguir una buena experiencia de búsqueda y resistir tanta demanda es la rapidez de respuesta (a parte de repartir datacenters espejo por todo el mundo).

Esta rapidez se consigue distribuyendo el trabajo de cada búsqueda que hacemos en decenas de miles de ordenadores que procesarán simultáneamente para confeccionar el resultado. Si, cada vez que se hace una simple búsqueda estas activando alrededor de 10.000 servidores (salvo que la búsqueda esté cacheada, tendrías que hacer una búsqueda peculiar para activar toda la maquinaria, se nota en el tiempo de respuesta).

Esta rapidez se consigue gracias a que gran parte de la información se almacena en la memoria RAM de todos esos servidores (suman decenas de terabytes fácilmente), reduciendo al mínimo el acceso al disco duro magnético que es lento y torpe.

Y aquí llega el punto clave de la cuestión. Los nuevos SSD tienen una bajísima latencia, su tiempo de respuesta es 100 veces más veloz que un disco duro magnético resultando tan veloz como una SDRAM. El acceso a la información es tan solo de 0,01 milisegundos.

Para rematar la jugada, la velocidad de lectura de datos aleatoria es tan rápida como una lectura continua. En este punto los discos duros son muy lentos porque deben mover la aguja hasta el lugar determinado de lectura. Para realizar búsquedas este punto es importantísimo ya que permitiría ampliar 100 veces (teóricamente) la capacidad de almacenaje y búsqueda de cada servidor.

Por lo tanto mi teoría es que dentro de poco habrá una oportunidad estratégica para crear un datacenter más potente que el de Google con 100 veces menos servidores. Con lo cual la necesidad de ser rico sera menor y quien sabe… habrá que ahorrar.

[Nota: actualmente los discos SSD son carísimos y tienen una duración de vida extremadamente corta lo que obliga a usar un sistema de archivos especial que evita que se gasten rápido. Doy por hecho que en el futuro se superarán estos problemas técnicos y que pronto esta tecnología estará lista para usarse a un precio competitivo.]

[Nota2: por cierto, equivocado o acertado, en un futuro cercano el formatear se va a acabar. Los discos SSD pueden borrar toda su información instantáneamente.]

Hay muchas formas de venderse al Diablo en la vida. Una de ellas es poseer o promocionar un Casino Online en Internet.

Supongo que todo el mundo sabe que funcionan como los del Mundo Real, pero mucho más inseguros y abusivos. Es decir, la banca te roba más. Sin embargo quiero aportar una razón de peso, que creo que no deja lugar a duda.

Resulta que los casinos proliferan, porque son extremadamente rentables, pero escasean los jugadores. Por lo tanto necesitan las más agresivas campañas y técnicas para captar incautos.

Tanto es así, que da lugar a la siguiente tragicomedia:

La cantidad CPA [Coste Por Acción] oscila entre $180-$200 [..] por cada jugador que haga un depósito mínimo de $50

(Visto en un sponsor de casinos)

Es decir, la situación está así: anuncias el casino en tu web, por cada nuevo cliente que lleves al casino y que ingrese los 50 dolares te pagan entre 180 y 200 dolares. Increíble!

¿Se da cuenta? Invierten por cada jugador el cuádruple de lo que ingresa inicialmente.

Han hecho sus estadísticas para saber a ciencia cierta (por eso invierten en riesgo, que paradoja) que el jugador perderá al menos 4 veces el dinero que ingresó inicialmente solo para recuperar el coste de la promoción. A esta perdida hay que sumar el retorno de los premios-anzuelo que le haya podido tocar, más los propios beneficios del casino!

En fin, esto solo es el principio. Hace unos días vi de pasada un partido de fútbol, creo que eran el Valencia y el Madrid. Sus patrocinadores principales eran dos casinos online de Internet.

Adivinen en qué país están ubicados físicamente… Gibraltar, tragicomedia al canto que además es ilegal en España.