Archivos Tecnología: Diciembre 2007
Este post estaba en borrador, y ahora lo completé como respuesta a una pregunta de FT via twitter,
Si algún día TinyURL o Dev.cl dejan de prestar servicio... ¿mueren todas las URLs cortas creadas?
La respuesta corta es Sí.
Incidentalmente, cuando traté de acortar la url de este post dev.cl me devolvio la url http://dev.cl/.
Ahora la respuesta entretenida:
Aunque las urls cortas tienen varias aplicaciones y ventajas, incluso sirven para comprimir imágenes ;) la verdad es que hay varios problemas:
Jeff Atwood resume varios de estos problemas:
- Si el servicio desaparece, las urls quedan rotas para siempre. Tal como teme FT.
- El otro problema es la calidad del servicio, efectivamente un servicio de este tipo que funcione esporádicamente (con "apagones") puede ser una situación aún peor.
- Se pierde la cualquier pista sobre el contenido de la url, al ser todas esta homogéneas, y estar resumidas en un codigo críptico. Esto es malo para la experiencia usuario del que está haciendo click en el enlace.
- Hay servicios de redireccionamiento de urls que han sido usados en formas cuestionables, por ejemplo spammers (fue el caso de lnk.to).
Otros problemas que Atwood no identifica son:
- La redirección introduce latencia.
- No es bueno usar esto para cosas como ajax, o web services.
- Si tu firewall o proxy reverso bloquea el servicio lo hace inutilizable
- El servicio puede estar lleno de basura, como urls que ya no estan vigentes, al perder la pista no te enteras hasta que haces el click.
- Si una url falla no sabes si es el servicio de compresion el que falló o si la url original la que tiene problemas.
- Tinyurl no maneja bien algunas "urls extrañas" con caracteres como la coma (',').
A pesar de esto, las urls cortas son útiles en diversos contextos, como lo demuestra su uso en twitter, o para enviarlas en emails, o en mensajes SMS.
¿Por qué Google no provee este servicio?
Esa es una buena pregunta, y como dice Atwood, probablemente esto le daría mayor seguridad al servicio.
A lo mejor han analizado el problema y no ven el negocio para este servicio, o no quieren complicarse con el problema de los spammers.
Aunque sospecho que no quieren ponerse en una situación tan incomodamente hegemónica.
Una alternativa sería descentralizar el servicio, una especie de P2P de urls cortas, una idea que no he explorado, pero puede ser interesante.
(Lo que sí he explorado es la idea de eliminar el DNS, pero eso quedará para otro post.)
Quizás un análisis interesante sería ver que pasa con estos servicios y el principio de que las urls cools no cambian.
En primera instancia uno pensaría que al agregar un nivel de indirección esto servicios pueden ayudar a preservar este principio, pero si observamos con mayor detención, en realidad complican más el problema.
Efectivamente, si la url inicial cambia, además hay que propagar ese cambio a todas las urls cortas de todos los servicios de este tipo.
Ahora bien, el problema de la persistencia de las URLs es más complejo aún, y la caida de servicios tipo tinyurl es sólo una clase de los problemas asociados a la persistencia de las URLs.
** ¿Cómo implementar un servicio como este? **
Ahora, para finalizar, déjenme criticar la propuesta de Atwood de usar hash como mecanismo para generar URLs cortas.
Aunque a primera vista parece bueno (algoritmo O(1)), no parece la forma más práctica para implementar este servicio. Los hashes que muestra generan strings mucho más largos que los que observamos en estos servicios.
Mejor optar por un algoritmo O(N log (N)) como el siguiente:
- Existe una tabla URL, indexado por ID y URL_LARGA
- Se recibe una url y se busca por URL_LARGA obteniendo ID o NULL.
- Si se obtiene NULL se inserta un nuevo elemento en la tabla y la URL corta sera la raiz del sitio mas el ID expresado en base 64.
Que nos permite generar urls bastante cortas, y es facil de implementar.
No creo que sea fácil encontrar una función hash que genere strings más cortos que los que genera este algoritmo.
Como Tip adicional, en vez de realizar la redirección usando PHP, o Python, yo optaría por escribir un modulo apache en C, o en PERL, esto aceleraría en al menos un orden de magnitud el servicio (si es que no más). O quizás creando mi propio servidor web. Y por último, trataría de mantener la tabla en memoria, o al menos un caché de las URLs más visitadas.
Dado el exito de mi anterior post sobre las innovaciones con el WiiMote, les vuelvo a publicar este video del brazo robot manejado por un WiiMote.
Les quiero presentar un par de innovaciones del investigador Johnny Chung Lee, postulante a doctorado en la Universidad de Carnegie Mellon.
La primera innovación la descubrí a través de un post en
Botón Turbo.. Lamentablemente en ese blog no entendieron muy bien que es lo que sucede, así que permitanme explicarlo, antes de presentarles el video.
En este caso Chung Lee escribe un programa en C# y utiliza el control de la Wii como dispositivo de entrada conectado a su Laptop, corriendo Windows. En ningún momento ha escrito código que se ejecute en la consola de Nintendo, todo ocurre en el laptop, y lo que se usa es el WiiMote. La característica principal de esta innovación es que utiliza el control de la Wii al revés, mueve el sensor infrarrojo en vez del WiiMote.
Noten el efecto que se produce al introducir el marco, una técnica usada en computación gráfica. Claro que sólo sirve para un usuario, el que esté portando el sensor infrarrojo a la altura de sus ojos. Como explica Chung Lee, esta innovación le da nuevas posibilidades a la Wii.
La segunda innovación de Chung Lee, y que a mí me parece más interesante es cómo usa este concepto de usar el WiiMote para seguir el rastro de un lapiz infrarrojo. Con esto monta una pizarra interactiva, y luego construye su propia versión del Surface, claro que a una centésima parte del costo (una WiiMote cuesta unos 50 dolares, y un Surface unos 5000).
¡¡Con esto se pueden montar pizarras interactivas en cualquier colegio, a una fracción del costo!!
Lo mejor es que todo el código fuente de estos proyectos está publicado, les sugiero explorar la página de proyectos de Chung Lee y sorprenderse con este innovador.
Estos proyectos han sido desarrollados en Windows usando como base la Managed Library for Nintendo's Wiimote escrita por Brian Peek y publicada en el blog de Microsoft Coding4Fun.
No, si usas un sistema operativo de 32 bits no puedes usar más de 4 GiB de memoria RAM.
Punto.
Con 32 bits sólo puedes acceder a 2 elevado a 32 posibles direcciones. Existen mecanismos propuestos para acceder a direcciones sobre los 4 GiB, pero tienen sus problemas. (Cuando el mundo era joven, y usabamos el 286, había un truquillo para usar memoria por segmentos, pero eso si que era un dolor de cabeza, algo similar a lo que hace PAE).
De todas maneras, este es un "acceso virtual" a más de 4GiB, que se logra con 4 bits adicionales de indirección, en un momento dado, la CPU sólo accede a 4GiB.
De todas maneras, el modo PAE crea bastantes inconvenientes, así que no es una solución real al problema.
Otros sistemas soportan PAE, pero insisto, siempre estás accediendo en forma indirecta a la memoria adicional, es mejor irse por un sistema de 64bits, porque te dará menos dolores de cabeza y sin degradar el desempeño.
Y no se trata de una limitación de Windows, con Linux (de 32 bits) tampoco vas a poder, no importa lo que te digan los talibanes.
Si quieres usar más de 4GiB de RAM debes tener un procesador de 64 bits, y un sistema operativo de 64bits.
Les recomiendo leer este artículo de Kriptópolis al respecto, (ah! y Bill Gates nunca dijo que 640 Kb de RAM eran suficiente)
