La vida es Corta ---------------- Hasta que cumple veinticinco, todo hombre piensa cada tanto que dadas las circunstancias correctas podría ser el más jodido del mundo. Si me mudara a un monasterio de artes marciales en China y estudiara duro por diez años. Si mi familia fuera masacrada por traficantes colombianos y jurara venganza. Si tuviera una enfermedad fatal, me quedara un año de vida y lo dedicara a acabar con el crimen. Si tan sólo abandonara todo y dedicara mi vida a ser jodido. -- Neal Stephenson (Snow Crash) A los veinticinco, sin embargo, uno se da cuenta que realmente no vale la pena pasarse diez años estudiando en un monasterio, porque no hay WiFi y no hay una cantidad ilimitada de años como para hacerse el Kung Fu. De la misma forma, cuando uno empieza a programar cree que cada cosa que encuentra podría rehacerse mejor. Ese framework web es demasiado grande y complejo. Esa herramienta de blog no tiene exactamente los features que yo quiero. Y la reacción es "¡Yo puedo hacerlo mejor!" y ponerse a programar furiosamente para demostrarlo. Eso es bueno y es malo. Es bueno porque a veces de ahí salen cosas que son, efectivamente, mucho mejores que las existentes. Si nadie hiciera esto, el software en general sería una porquería. Es malo porque la gran gran mayoria de las veces, tratando de implementar el framework web número 9856, que es un 0.01% mejor que los existentes, se pasa un año y no se hace algo original que realmente puede hacer una diferencia. Por eso digo que "la vida es corta". No es que sea corta, es que es demasiado corta para perder tiempo haciendo lo que ya está hecho o buscándole la quinta pata al gato. Hay que sobreponerse a la tristeza de que nunca vamos a usar 100% programas hechos por nosotros y nuestros amigos, y aplicar la fuerza en los puntos críticos, crear las cosas que no existen, no las que ya están. Antes de decidirse a empezar un proyecto hay que preguntarse muchas cosas: * ¿Me va a dejar plata? * ¿Qué es lo nuevo de este proyecto? * ¿Tengo alguna idea de implementación que nadie tuvo? * ¿Tengo alguna idea de interface original? * ¿Por qué alguien va a querer usar eso? * ¿Tengo tiempo y ganas de encarar este proyecto? * ¿Me voy a divertir haciéndolo? Las más importantes son probablemente la última y la primera. La primera porque de algo hay que vivir, y la última porque es suficiente. Si uno decide que sí, que va a encarar un proyecto, hay que tratar de programar lo menos posible. Una de las tentaciones del programador es afeitar yaks [#]_: es una actividad inútil en sí misma, que uno espera le dé beneficios más adelante. .. [#] Frase inventada por `Carlin Vieri `_ Yo estoy escribiendo este libro que tiene links a URLs. Yo quiero que esas URLs sean válidas para siempre. Entonces necesito poder editarlas **después** de que se imprima el libro y me gustaría un "acortador" de URLs donde se puedan editar. Como no lo encuentro lo escribo. Si siguiera con "y para eso necesito hacer un framework web, y un módulo para almacenar los datos"... estoy afeitando yaks. Para poder hacer A, uno descubre que necesita B, para B necesita C. Cuando llegás a D... estás afeitando yaks. Si necesitás B para lograr A, entonces, buscá una B en algún lado, y **usala**. Si realmente no existe nada parecido, entonces ahora tenés dos proyectos. Pensá si te interesa más A o B, y si podés llevar los dos adelante. Es un problema. En este capítulo lo que vamos a hacer es aprender a no reinventar la rueda. Vamos a elegir un objetivo y vamos a lograrlo sin afeitar ningún yak. Vas a ver como creamos un programa útil con casi nada de código propio. El Problema ~~~~~~~~~~~ Recibí algunas quejas acerca de que algunos links en mis libros no funcionaban cuando fueron publicados. Para el próximo libro que estoy escribiendo, le propuse a mi editor crear un sitio para registrar las referencias mencionadas. Usando referencias ascii cortas y únicas a lo largo del libro, es facil proveer un servicio sencillo de redirección a la URL de destino, y arreglarlo cuando cambie (simplemente creando un alerta de email si la redirección da error 404). -- Tarek Ziadé en `URLs in Books `_ Ya que no tengo editor, lo voy a tener que hacer yo mismo. Me parece una buena idea, va a ser útil para este proyecto, no encuentro nada hecho similar [#]_, es un buen ejemplo del objetivo de este capítulo... ¡vendido! .. [#] El que me hizo ver esa cita de Tarek Ziadé fué Martín Gaitán. Con el capítulo ya escrito, Juanjo Conti me ha hecho notar http://a.gd Una vez decidido a encarar este proyecto, establezcamos las metas: * Un redirector estilo tinyURL, bit.ly, etc. * Que use URLs cortas y mnemotécnicas. * Que el usuario pueda editar las redirecciones en cualquier momento. * Que notifique cuando la URL no sirva, para poder corregirla. Además, como metas "ideológicas": * Un mínimo de afeitado de yaks. * Que sea un programa relativamente breve. * Código lo más simple posible: no hay que hacerse el piola, porque no quiero mantener algo complejo. * Cada vez que haya que hacer algo: buscar si ya está hecho (excepto el programa en sí; si no, el capítulo termina dentro de dos renglones). Separemos la tarea en componentes: * Una función que dada una URL genera un slug [#]_ * Un componente para almacenar las relaciones slug => URL * Un sitio web que haga la redirección * Un mecanismo de edición de las relaciones .. [#] Slug es un término que ví en Django: un identificador único formado con letras y números. En este caso, es la parte única de la URL. Veamos los componentes elegidos para este desarrollo. Twill ~~~~~ Una de las cosas interesantes de este proyecto me parece hacer que el sistema testee automáticamente las URLs de un usuario. Una herramienta muy cómoda para estas cosas es `Twill `_ que podría definirse como un lenguaje de testing de sitios web. Por ejemplo, si todo lo que quiero es saber si el sitio www.google.com funciona es tan sencillo como:: go http://www.google.com code 200 Y así funciona:: $ twill-sh twilltest.script >> EXECUTING FILE twilltest.script AT LINE: twilltest.script:0 ==> at http://www.google.com.ar/ AT LINE: twilltest.script:1 -- 1 of 1 files SUCCEEDED. Ahora bien, twill es demasiado para nosotros. Permite almacenar cookies [#]_, llenar formularios, y mucho más. Yo tan solo quiero lo siguiente: .. [#] Como problema adicional, almacena cookies en el archivo que le digas. Serio problema de seguridad para una aplicación web. 1. Ir al sitio indicado. 2. Testear el código (para asegurarse que la página existe). 3. Verificar que un texto se encuentra en la página (para asegurarse que ahora no es un sitio acerca de un tema distinto). O sea, solo necesito los comandos twill ``code`` y ``find``. Porque soy buen tipo, podríamos habilitar ``notfind`` y ``title``. Todos esos comandos son de la forma ``comando argumento`` con lo que un parser de un lenguaje "minitwill" es muy fácil de hacer: .. class:: titulo-listado pyurl3.py .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl3.py :start-at: from twill.commands :end-before: # Usamos storm para almacenar los datos Veamos minitwill en acción: .. code-block:: pycon >>> minitwill('http://www.google.com','code 200') ==> at http://www.google.com.ar/ True >>> minitwill('http://www.google.com','code 404') ==> at http://www.google.com.ar/ False >>> minitwill('http://www.google.com','find bing') ==> at http://www.google.com.ar/ False >>> minitwill('http://www.google.com','title google') ==> at http://www.google.com.ar/ title is 'Google'. False >>> minitwill('http://www.google.com','title Google') ==> at http://www.google.com.ar/ title is 'Google'. True Bottle ~~~~~~ Esto va a ser una aplicación web. Hay docenas de frameworks para crearlas usando Python. Voy a elegir casi al azar uno que se llama `Bottle `_ porque es sencillo, sirve para lo que necesitamos, y es un único archivo. Literalmente se puede aprender a usar en una hora. ¿Qué Páginas tiene nuestra aplicación web? * ``/`` donde el usuario se puede autenticar o ver un listado de sus redirecciones existentes. * ``/SLUG/edit`` donde se edita una redirección (solo para el dueño del slug). * ``/SLUG/del`` para eliminar una redirección (solo para el dueño del slug). * ``/SLUG/test`` para correr el test de una redirección (solo para el dueño del slug). * ``/SLUG`` redirige al sitio deseado. * ``/static/archivo`` devuelve un archivo (para CSS, imágenes, etc) * ``/logout`` cierra la sesión del usuario. Empecemos con un "stub", una aplicación bottle mínima que controle esas URLs. El concepto básico en bottle es: * Creás una función que toma argumentos y devuelve una página web * Usás el decorador ``@bottle.route`` para que un PATH de URL determinado llame a esa función. * Si querés que una parte de la URL sea un argumento de la función, usás ``:nombrearg`` y la tomás como argumento (ej: ver en el listado, función borrar) .. raw:: pdf PageBreak Después hay más cosas, pero esto es suficiente por ahora: .. class:: titulo-listado pyurl1.py .. class:: listado .. code-block:: python :linenos: :include: codigo/2/pyurl1.py Para probarlo, alcanza con ``python pyurl1.py`` y sale esto en la consola:: $ python pyurl1.py Bottle server starting up (using WSGIRefServer())... Listening on http://127.0.0.1:8080/ Use Ctrl-C to quit. Apuntando un navegador a esa URL podemos verificar que cada función responde en la URL correcta y hace lo que tiene que hacer: .. figure:: pyurl1-1.print.jpg :width: 57% La aplicación de prueba funcionando. Autenticación ~~~~~~~~~~~~~ Bottle es un framework `WSGI `_. WSGI es un standard para crear aplicaciones web. Permite conectarlas entre sí, y hacer muchas cosas interesantes. En particular, tiene el concepto de "middleware". ¿Qué es el middleware? Es una aplicación intermediaria. El pedido del cliente va al middleware, este lo procesa y luego se lo pasa a tu aplicación original. Un caso particular es el middleware de autenticación, que permite que la aplicación web sepa si el usuario está autenticado o no. En nuestro caso, ciertas áreas de la aplicación sólo deben ser accesibles a ciertos usuarios. Por ejemplo, un atajo sólo puede ser editado por el usuario que lo creó. Todo lo que esta aplicación requiere del esquema de autenticación es saber: 1. Si el usuario está autenticado o no. 2. Cuál usuario es. Vamos a usar `AuthKit `_ con OpenID. De esa manera vamos a evitar una de las cosas más molestas de las aplicaciones web, la proliferación de cuentas de usuario. Al usar OpenID, no vamos a tener ningún concepto de usuario propio, simplemente vamos a confiar en que OpenID haga su trabajo y nos diga "este acceso lo está haciendo el usuario X" o "este acceso es de un usuario sin autenticar". ¿Cómo se autentica el usuario? Yahoo Ingresa ``yahoo.com`` Google Ingresa ``https://www.google.com/accounts/o8/id`` [#]_ Otro proveedor OpenID Ingresa el dominio del proveedor o su URL de usuario. .. [#] O se crean botones "Entrar con tu cuenta de google", etc. En ``views/invitado.tpl`` puede verse como hacerlo usando `openid-selector `_ una muy interesante solución basada pricipalmente en javascript. Luego OpenID se encarga de autenticarlo via Yahoo/Google/etc. y darnos el usuario autenticado como parte de la sesión. Hagamos entonces que nuestra aplicación de prueba soporte OpenID. Para empezar, se "envuelve" la aplicación con el middleware de autenticación. Es necesario importar varios módulos nuevos [#]_. Eso significa que todos los pedidos realizados ahora se hacen a la aplicación de middleware, no a la aplicación original de bottle. Esta aplicación de middleware puede decidir procesar el pedido ella misma (por ejemplo, una aplicación de autenticación va a querer procesar los errores 401, que significan "No autorizado"), o si no, va a pasar el pedido a la siguiente aplicación de la pila (en nuestro caso la aplicación bottle). .. [#] Hasta donde sé, necesitamos instalar: * AuthKit * Beaker * PasteDeploy * PasteScript * WebOb * Decorator .. class:: titulo-listado pyurl2.py .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl2.py :start-at: # Middlewares :end-before: @bottle.route .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl2.py :start-at: if __name__=='__main__': Para entender esto, necesitamos ver como es el flujo de una conexión standard en Bottle (o en casi cualquier otro framework web). [#]_ .. [#] Este diagrama es 90% mentira. Por ejemplo, en realidad ``route`` no llama a ``pyurl2.alta`` sino que la devuelve a ``app`` que después la ejecuta. Sin embargo, digamos que es metafóricamente cierto. .. figure:: middleware1.graph.pdf :height: 6cm Una conexión a la URL "/". 1. El usuario hace un pedido via HTTP pidiendo la URL "/" 2. La aplicación web recibe el pedido, ve el PATH y pasa el mismo pedido a ``route``. 3. La función registrada para ese PATH es ``pyurl2.alta``, y se la llama. 4. ``pyurl2.alta`` devuelve datos, pasados a un mecanismo de templates -- o HTML directo al cliente, pero eso no es lo habitual. 5. De una manera u otra, se devuelve el HTML al cliente, que vé el resultado de su pedido. Al "envolver" ``app`` con un middleware, es importante que recordemos que ``app`` ya no es la misma de antes, tiene código nuevo, que proviene de AuthKit. [#]_ El nuevo "flujo" es algo así (lo nuevo está en linea de puntos en el diagrama): .. [#] Nuevamente es muy mentiroso, estamos ignorando completamente el middleware de sesión, y sin eso AuthKit no funciona. Como excusa: ¡Es con fines educativos! todo lo que hacen las sesiones para nosotros es que AuthKit tenga un lugar donde guardar las credenciales del usuario para el paso 6. .. figure:: middleware2.graph.pdf :height: 6cm Una conexión a la URL "/" con AuthKit. 1. El usuario hace un pedido via HTTP pidiendo la URL "/" 2. La aplicación web recibe el pedido, ve el PATH y pasa el mismo pedido a ``route``. 3. La función registrada para ese PATH es ``pyurl2.alta``, y se la llama. 4. Si ``pyurl2.alta`` decide que esta página no puede ser vista, sin estar autenticado, entonces en vez de mandar datos al template, pasa una excepción a ``app`` (Error 401). .. class:: titulo-listado pyurl2.py .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl2.py :start-at: @bottle.route('/') :end-before: @bottle.route('/:slug/edit') 5. Si ``app`` recibe un error 401, en vez de devolverlo al usuario, le dice a AuthKit: "hacete cargo". Ahí Authkit muestra el login, llama a yahoo o quien sea, verifica las credenciales, y una vez que está todo listo... 6. Vuelve a llamar a ``pyurl2.alta`` pero esta vez, además de el request original hay unas credenciales de usuario, indicando que hubo un login exitoso. 7. ``pyurl2.alta`` devuelve datos, pasados a un mecanismo de templates -- o HTML directo al cliente, pero eso no es lo habitual. 8. De una manera u otra, HTML se devuelve al cliente, que vé el resultado de su pedido. Para que el usuario pueda cerrar su sesión, implementamos logout: .. class:: titulo-listado pyurl2.py .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl2.py :start-at: @bottle.route('/logout') :end-before: @bottle.route('/') ¿Funciona? .. figure:: pyurl2-1.print.jpg :width: 44% El sitio muestra una pantalla de login (Es fea porque es la que viene por default) .. figure:: pyurl2-2.print.jpg :width: 100% Tal vez, el proveedor de OpenID pide usuario/password .. figure:: pyurl2-3.print.jpg :width: 100% Por una única vez se pide autorizar al otro sitio. .. figure:: pyurl2-4.print.jpg :width: 43% Estamos autenticados y nuestra aplicación de prueba funciona como antes. ¿Puede quedar bueno esto? .. figure:: pyurl-production.print.jpg :width: 95% Este mismo programa, en producción, en http://pyurl.sytes.net Storm ~~~~~ Es obviamente necesario guardar las relaciones usuario/slug/URL en alguna parte. Lo obvio es usar una base de datos. Lo inteligente es usar un ORM. A favor de usar un ORM: No se usa SQL directo, lo que permite hacer todo (o casi) en Python. El programa queda más "limpio" al no tener que cambiar de contexto todo el tiempo. En contra de usar un ORM: Es una dependencia extra, te ata a un producto que tal vez mañana "desaparezca". Puede tener una pérdida de performance con respecto a usar la base de datos en forma directa. No me parece grave: Si tenemos cuidado y aislamos el ORM del resto de la aplicación, es posible reemplazarlo con otro más adelante (o eliminarlo y "bajar" a SQL o a NoSQL). Por lo tanto, en el espíritu de "no inventes, usá", vamos a usar un ORM. En particular vamos a usar `Storm `_, un ORM creado por `Canonical `_, que me gusta [#]_. .. [#] Me gusta más `Elixir `_ pero es bastante más complicado para algunas cosas. En esta aplicación los requerimientos de base de datos son mínimos. Necesito poder guardar algo como ``(url,usuario,slug,test)`` y poder después recuperarlo sea por slug, sea por usuario. Necesito que el slug sea único. Todos los demás campos pueden repetirse. [#]_ .. [#] Sería bueno que la combinación usuario+url lo fuera pero lo veremos más adelante. Veamos código. Primero, definimos lo que Storm requiere. .. class:: titulo-listado pyurl3.py .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl3.py :start-at: # Usamos storm para :end-before: def __init__ Veamos ahora el ``__init__`` de esta clase. Como "truco", se guarda automáticamente en la base de datos al crearse: .. class:: titulo-listado pyurl3.py .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl3.py :start-at: def __init__ :end-before: @classmethod ¿Y de dónde sale self.store? De un método de inicialización que hay que llamar antes de poder crear una instancia de ``Atajo``: .. class:: titulo-listado pyurl3.py .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl3.py :start-after: Atajo.store.commit() :end-before: # Caracteres El código "original", es decir, convertir URLs a slugs y viceversa es bastante tonto: .. class:: titulo-listado pyurl3.py .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl3.py :start-at: # Caracteres válidos en un atajo de URL :end-before: # Usamos bottle para hacer el sitio ¡Veámoslo en acción! .. code-block:: pycon >>> from pyurl3 import Atajo >>> Atajo.init_db() >>> a1 = Atajo(u'http://nomuerde.netmanagers.com.ar', u'unnombredeusuario') >>> a1.slug() 'b' >>> a1 = Atajo(u'http://www.python.org', u'unnombredeusuario') >>> a1.slug() 'c' >>> Atajo.get(slug='b').url u'http://nomuerde.netmanagers.com.ar' >>> [x.url for x in Atajo.get(user=u'unnombredeusuario')] [u'http://nomuerde.netmanagers.com.ar', u'http://www.python.org'] Y desde ya que todo está en la base de datos: .. code-block:: sql sqlite> .dump PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE atajo ( id INTEGER PRIMARY KEY, url VARCHAR, test VARCHAR, user VARCHAR ); INSERT INTO "atajo" VALUES(1,'http://nomuerde.netmanagers.com.ar', NULL,'unnombredeusuario'); INSERT INTO "atajo" VALUES(2,'http://www.python.org',NULL, 'unnombredeusuario'); COMMIT; HTML / Templates ~~~~~~~~~~~~~~~~ BlueTrip te da un conjunto razonable de estilos y una forma común de construir un sitio web para que puedas saltear la parte aburrida y ponerte a diseñar. -- http://bluetrip.org Soy un cero a la izquierda en cuanto a diseño gráfico, HTML, estética, etc. En consecuencia, para CSS y demás simplemente busqué algo fácil de usar y lo usé. Todo el "look" del sitio va a estar basado en `BlueTrip `_, un framework de CSS. Dado que no pienso diseñar mucho, ¡gracias BlueTrip! Necesitamos 3 páginas en HTML: * Bienvenida (invitado): + Ofrece login. + Explica el servicio. * Bienvenida (usuario): + Ofrece crear nuevo atajo + Muestra atajos existentes (ofrece edición/eliminar/status) + Ofrece logout * Edición de atajo: + Cambiar donde apunta (URL). + Cambiar test. + Probar test. + Eliminar. No voy a mostrar el detalle de cada página, mi HTML es básico, sólo veamos algunas capturas de las páginas: .. figure:: pyurl3-1.print.jpg :width: 100% Pantalla de invitado. .. figure:: pyurl3-2.print.jpg :width: 100% Pantalla de usuario. .. figure:: pyurl3-3.print.jpg :width: 100% Usuario editando un atajo. Como las páginas son en realidad generadas con el lenguaje de templates de bottle, hay que pensar qué parámetros se pasan, y usarlos en el template. Luego, se le dice a bottle que template usar. Tomemos como ejemplo la página ``usuario.tpl``, que es lo que vé el usuario registrado en el sitio y es la más complicada. Explicación breve de la sintaxis de los templates [#]_: .. [#] Si no te gusta, es fácil reemplazarlo con otro motor de templates. * ``{{variable}}`` se reemplaza con el valor de ``variable``. * ``{{funcion()}}`` se reemplaza con el resultado de ``funcion()`` * ``{{!cosa}}`` es un reemplazo *inseguro*. En los otros, se reemplaza ``<`` con ``<`` etc. para prevenir problemas de seguridad. * Las líneas que empiezan con ``%`` son Python. Pero.... Hay que cerrar cada bloque con ``%end`` (porque no podemos confiar en la indentación). Ejemplo:: %for x in range(10):
  • {{x}} %end Ignorando HTML aburrido, es algo así: .. class:: titulo-listado usuario.tpl .. class:: listado .. code-block:: html :linenos: :linenos_offset: :include: codigo/2/views/usuario.tpl :start-at: %if mensaje: :end-at: La pantalla para usuario no autenticado es un caso particular: la genera AuthKit, no Bottle, por lo que hay que pasar el contenido como parámetro de creación del middleware: .. class:: titulo-listado pyurl3.py .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl3.py :start-after: app.catchall = False :end-at: openid_path_signedin='/') Backend ~~~~~~~ Vimos recién que al template ``usuario.tmpl`` hay que pasarle: * Un ``mensaje`` (opcional) con una ``clasemensaje`` que define el estilo. * Una lista ``atajos`` conteniendo los atajos de este usuario. También vemos que el formulario de acortar URLs apunta a esta misma página con lo que la función deberá: * Ver si el usuario está autenticado (o dar error 401) * Si recibe un parámetro ``url``, acortarlo y dar un ``mensaje`` al respecto. * Pasar al template la variable ``atajos`` con los datos necesarios. .. class:: titulo-listado pyurl3.py .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl3.py :start-at: @bottle.post('/') :end-at: return data Las demás páginas no aportan nada interesante: .. class:: titulo-listado pyurl3.py .. class:: listado .. code-block:: python :linenos: :linenos_offset: :include: codigo/2/pyurl3.py :start-after: return data :end-before: if __name__ == '__main__': Conclusiones ~~~~~~~~~~~~ En este capítulo se ve una aplicación web, completa, útil y (semi)original. El código que hizo falta escribir fue... unas 250 líneas de python. Obviamente esta aplicación no está lista para ponerse en producción. Algunos de los problemas obvios: * Necesita un robots.txt para no pasarse la vida respondiendo a robots * Se puede optimizar mucho * Necesita protección contra DOS (ejemplo, limitar la frecuencia de corrida de los tests) * Necesita que correr un test no bloquee todo el sitio. * Necesita ser útil para el fin propuesto! * Idea: formulario que toma una lista de URLs y devuelve la lista correspondiente de enlaces acortados. * Necesita *muchísimo* laburo de "UI". Y hay muchos features posibles: * Opcionalmente redirigir en un IFrame y permitir cosas como comentarios acerca de la página de destino. * Estadísticas de uso de los links. * Una página pública "Los links de Juan Perez" (y convertirlo en http://del.icio.us ). * Soportar cosas que no sean links si no texto (y convertirlo en un pastebin). * Soportar imágenes (y ser un image hosting). * Correr tests periódicamente. * Notificar fallas de test por email. Todas esas cosas son posibles... y quien quiera hacerlas, puede ayudar! Este programa es open source, se aceptan sugerencias Tal vez hasta esté funcionando en http://pyurl.sytes.net ... Visiten y ayuden!