Novedades en la categoría Usabilidad
En 1981 se publica uno de los documentos más importantes de la internet, el famoso RFC 793, que define el protocolo TCP, que es el principal protocolo de internet, y que es la base de la mayoría de los protocolos usados en la red.
En este documento Jon Postel escribe, lo que ha llegado a conocerse como el Principio de Robustez, o la Ley de Postel:
Las implementaciones TCP deben seguir un principio genera del robustez: ser conservador en lo que haces, ser liberal en lo que aceptas de otros.
TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
Dependiendo de tu sistema valórico, encontrarás el consejo de Postel como algo bueno, e incluso recomendable para otros aspectos de la vida, no sólo en los protocolos de transmisión de datos.
Este principio ha sido criticado por cierto, porque aparentemenente promueve una tolerancia pasiva, o por ser demasiado liberal, y eventualmente permite aplicaciones inseguras.
La verdad es que no era la intención de Postel ser demasiado permisivo con los protocolos, y decir que las validaciones no eran necesarias. Pero, efectivamente, el principio de robustez ha sido mal interpretado, y eso nos ha generado muchos problemas, principalmente con la seguridad de las aplicaciones.
Pero no hay que olvidar que el principio de robustez tiene una mirada puesta en las necesidades de los usuarios finales.
En la actualidad esto tiende a olvidarse, y muchos desarrolladores, sobre todo los más rígidos (y sobre todo los más jóvenes), exigen que se cumplan los estándares, sin ninguna excepción, aunque eso atente contra las necesidades de los usuarios.
Consideren el caso de HTML. ¡Un verdadero caos! hay cientos de implementaciones de HTML, con miles de bugs, parches y soluciones ad-hoc incrustadas en la web y en los navegadores de internet.
En algún momento se optó por establecer estándares basados en XML como la solución definitiva del problema, y con esto se quiebró la Ley de Postel.
XML es un protocolo estricto. En teoría un documento XML inválido no debe ser aceptado. Pero habrán documentos inválidos, eso es casi inevitable.
Un ejemplo clásico es lo que pasa con la sigla "AT&T", de acuerdo a la especificación XML se debe escribir: "AT&T", pero eventualmente alguien escribirá "AT&T". Las aplicaciones que privilegien los deseos de los usuarios y acepten documentos XML escritos en forma no tan estricta (piensen en los varios tipos de browsers disponibles), terminarán imponiéndose (porque son aplicaciones más robustas).
XML nos pide que rompamos el principio de Postel, XML exige que seamos intolerantes con lo que recibimos. Esto puede atentar contra las necesidades del usuario.
Ese es un problema que aparece también en protocolos como SOAP, y en general casi todas las recomendaciones de interoperatividad basados en estándares rígidos, como XML. "La ley de Postel no acepta excepciones", cuando vamos contra este principio el que lo paga eventualmente es el usuario.
¿Qué opinan ustedes? ¿conocen otras situaciones donde al tratar de romper este principio perjudicamos la experiencia del usuario?
Los lectores habituales de este blog saben que no me gustan los captcha, pero la verdad es que me tienen aburrido los comentarios spam, se pierde bastante tiempo administrándolos, y me tiene cansado el tema.
Así que vamos a habilitar captchas, y vamos a usar el default de Movable TYpe, y espero que no les aparezca uno tan aberrante como este.
Incidentalmente, sin querer habilité el captcha hace unos meses atrás y creo que funcionó, aunque sospecho que demasiado bien, porque los comentarios llegaron casi a 0 :(
La verdad es que creo que hay otras opciones mejores, pero no tengo mucho tiempo por ahora para implementarlas, así que espero me disculpen, y si alguien sabe de una alternativa que funcione con movable type 4, que me deje una nota (si el captcha se los permite).
Resulta que tomando las ideas de Johny Chung Lee un grupo de profesores gallegos construyeron una pizarra electrónica usando un control remoto de una WII y un proyector. Tal como se muestra en el video:
Las instrucciones para lograr esto están acá (en gallego).
Esto me parece que es bastante más barato que cualquier tecnología similar disponible en el mercado.
Gallegos astutos
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.
Hace rato que TinyUrl venia molestando por su insistencia en hacer campaña política.
Ahora hay una alternativa chilena, gracias a Carlos Fuentealba, se trata del sitio dev.cl.
Funciona perfectamente con Twitter, y es mas corto que una url en TinyURL.
Para los que son del pasado, este servicio permite acortar una URL grandota (como http://www.channel4.com/entertainment/tv/microsites/I/itcrowd/) en una mas pequeñita como (http://dev.cl/vj1c).
Si no saben que es una URL, bueno, ¿que hacen leyendo esto?
¡Buen trabajo Carlos!
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.
Recibí un comentario en mi post Un Laptop por Gato, creo que es interesante destacarlo, porque por es un testimonio de como están percibiendo en Uruguay este proyecto:
ACLARACION:
1. Creo que he cometido un error al publicar este comentario de manera destacada, con esto solo he alimentado a los trolls.
2. No es la percepción de Uruguay, sólo la de una persona: Alejandro Lavarello, y ese es mi segundo error, dada la redacción original.
Por lo tanto, he decidido dar un nivel de indirección al comentario, y deberán leerlo donde fue publicado por su autor.
Gracias FT, porque su comentario me hizo reflexionar (lo que demuestra que hay que siempre aprender de los profesionales). Antes de publicar, hay que revisar las fuentes.
