Texto coloreado en LibreOffice

Software — Martes 25 de Abril de 2017, 19:12


A los que armamos presentaciones mostrando programitas o pequeñas porciones de código siempre se nos presentó un inconveniente: ¿cómo mostrar ese código apropiadamente coloreado?

Con "apropiadamente coloreado" no me refiero a pintarrajeado como adolescente que sale a bailar, o decorado con florcitas, soles, y/o aviones de guerra, sino a algo que es típico en el mundo de la programación donde los editores le ponen distintos colores a las palabras que forman el código en función de qué tipo de palabra son: un color para las variables, otro para los textos, otro para los nombres de las funciones, otro para...

No voy a entrar en detalle sobre qué es ese coloreado (que en inglés llamamos "syntax highlighting"), pero les muestro un ejemplo:

Ejemplo de código coloreado

En fin, volviendo a meter código coloreado en LibreOffice. Lo charlé bastante en su momento con varias personas, lo mejor parecía capturar una imagen del código y meter eso, pero es una porquería porque no queda bien ante el menor cambio de tamaño, y si encima hay que tocar cualquier cosa de ese texto es imposible.

También buscando encontré Coooder, que es una extensión de LibreOffice que hacía exactamente eso. El verbo hacer de la oración anterior está en pasado porque sólo funciona para los LibreOffice del 3.3 a 3.6 (yo actualmente tengo 5.1).

Finalmente encontré la manera de hacerlo! No es la más directa, pero el resultado es el que estaba buscando: un texto coloreado dentro de LibreOffice. Genial!

Los pasos se dividen en dos partes grandes:

  • generar un documento en formato RTF
  • meter este doc RTF en la presentación

Cómo generar el doc RTF:

  • Abrir el código con gvim
  • Escribir :TOhtml, lo cual abrirá otra ventana con el código HTML correspondiente a nuestro texto coloreado.
  • Escribir :saveas /tmp/cod.html, lo cual grabará ese HTML en el path ahí especificado
  • Cerrar cualquier libreffice abierto (sino el próximo paso falla :/).
  • Desde una terminal, ejecutar unoconv -f rtf /tmp/cod.html lo cual nos dejará un archivo en /tmp/cod.rtf justamente con el código nuestro, en formato RTF.
  • Abrir el LibreOffice Impress
  • Ir al Menu, Insertar, Archivo; un par de clicks en "siguiente" y ya tenemos el texto adentro.
  • Seleccionar el texto que acabamos de insertar, y cambiarle la tipografía a alguna monoespaciada.

Voilà!


Teclas multimedia con Exaile en sistemas modernos

Software — Jueves 13 de Abril de 2017, 07:15


Hace rato que Exaile es mi reproductor de música de cabecera. Tiene todo lo que quiero, y el resto de las cosas que no quiero no son intrusivas ni me molestan (no tengo que pelearme con el programa para usarlo, digamos).

Y está hecho en Python :). Es una ventaja a la hora de debuguear algún problema (y si no recuerdo mal algún parche he mandado por algún bug...).

Exaile

Con las idas y venidas de Ubuntu en el escritorio, en algún momento tuve problemas usando la versión oficial o última liberada, y en ese momento lo resolví saltando directamente a usarlo desde el proyecto. Cuando decidí hacer eso probé directamente master, y me anduvo, así que me quedé ahí.

Es un toque riesgoso (a nivel de estabilidad) porque estás probando lo último que meten los desarrolladores, pero por ahora estamos (casi) bien; hay que tener en cuenta que no lo actualizo todo el tiempo, sino cuando estoy buscando alguna corrección específica que se haya hecho.

El otro día vi que habían solucionado algo que me molestaba (un detalle nomás, relacionado con el arrastrar canciones en la playlist), e hice git pull para actualizar a lo último. Algunas cosas mejoraron (puntualmente lo que estaba buscando, joya), pero unos minutos después me di cuenta que no me andaba mi hotkey de teclado para pausar y rearrancar la música.

Yo estoy muy acostumbrado a apretar ctrl-shift-espacio para hacer que la música se frene, y el mismo golpe de teclas para que la música reanude, y de repente no me funcionaba más :(.

Empecé a investigar qué era, y me di cuenta que Exaile no tenía más el plugin gnomemmkeys, que es el que le permite "recibir las teclas de multimedia que uno aprieta" (así muy entre comillas, porque no es la descripción más realista de lo que sucede, pero transmite la idea).

Buscando (en el proyecto mismo) en qué momento eso desapareció encontré un commit que hacía referencia a mpris2, que resulta que es una interfaz de D-Bus para controlar reproductores de sonido/video.

Caution, geek

Aprendiendo sobre esta tecnología encontré que había un cliente de mpris de linea de comandos, así que lo instalé (sudo apt-get install mpris-remote) y configuré en el sistema para que ctrl-shift-espacio sea mpris-remote pause.

Nota: el comando que puse arriba manda la señal "pause", que pausa y "despausa", ojo, no confundir con "play", que arranca la próxima canción (no sigue de donde estaba).

Nota 2: después de que lo había implementado, me dijeron en el canal de IRC de Exaile que directamente podía hacer exaile --play-pause desde la linea de comandos. Me quedé con la implementación original, sin embargo, porque es más rápida (solo manda una señal, no levanta todo un reproductor de música solo para mandarla).


Como no perder las fotos del teléfono

Software — Jueves 19 de Mayo de 2016, 13:32


La combinación de tener buena cámara en el teléfono, y tener el teléfono todo el tiempo a mano, hace que uno saque fotos con dicho dispositivo bastante seguido. Por no decir todo el tiempo.

Lo que no es tan fácil o automático es cómo guardar las fotos, cómo salvarlas de manera que no perderlas si te roban el celular, o lo perdés, o se te rompe, o se rompe la memoria interna, etc. Y además, cómo tenerlas siempre a mano: poder ir a buscarlas fácil para meterlas en un documento y mandarlas por mail, o mezclarlas con las fotos de la cámara grande, etc.

Yo tengo algo armado que me soluciona esto, hace rato, y me está funcionando tan bien que pensé en compartirlo. ¿Es trivial de montarlo para que funcione? No. Pero una vez armado todo, anda pipí cucú. Y gratis :D

Yes!

El setup o configuración tiene tres partes: un servicio online, el teléfono, y la compu o laptop donde trabajes normalmente.

El servicio online que uso es Flickr. Podés sacar una cuenta gratis, te da 1000 GB de almacenamiento. Son cuatro clicks, dale.

Luego, te instalás la aplicación de Flickr en el teléfono, y la configurás para que automáticamente suba las fotos a la nube cuando estés conectado por WiFi. Acá, algunos detalles. Está piola que las suba automáticamente, pero no te consuma internet de la compañía de teléfonos, así que no vas a terminar pagando más a fin de mes. Y funciona bien el "subirlas automáticamente", si estás conectado te las sube al toque, y no es para nada intrusivo. Además, te las sube por default en modo "no compartido con nadie", así que no tengas miedo en sacarte fotos en bolas o al resumen de la tarjeta de crédito, que nadie va a ver esas fotos (a menos que vayas al sitio web de Flickr, las elijas, y les cambies los permisos).

Hasta acá, tenés un backup automático de las fotos. Todo lo que saques lo vas a tener en la nube. Queda el último paso, que es tener las fotos bien a mano.

Para eso, yo tengo un script que corro cada dos horas automáticamente (lo puse en el crontab; dos horas parece mucho, pero no quería pegarle a Flickr todo el tiempo indiscriminadamente, y de última si quiero bajar algo que recién subió y no quiero esperar que se cumplan las dos horas, corro el script a mano). El script va a Flickr, se fija qué fotos nuevas hay en el álbum donde la aplicación del teléfono las sube sola, y las baja. Simple y efectivo.

Lo ejecuto así:

    baja_flickr.py --quiet album_id algun_path

El --quiet es para que si todo funciona como es esperado no tire ninguna salida, así crontab no me manda mail al cuete (al principio, especialmente al probarlo a mano, no le pongan esta opción). El album_id es el identificador del álbum en Flickr donde se suben las fotos automáticamente, la forma más fácil de saber este numerito es ir al sitio de Flickr, ir al álbum donde están estas fotos, y sacar el código de la URL. Finalmente, algun_path es el directorio donde querés que el script te ponga las fotos que baja.

Un detalle importante, para que esto funcione. Como dije arriba, las fotos no son visibles para cualquiera, así que el script tiene que autenticarse como ustedes. Esto se maneja automáticamente, pero el script tiene que saber unos datos de ustedes; como pueden ver en el script, tienen que poner dos claves en dos archivos, más vuestro id de usuario de flickr en una constante. Las dos claves esas las sacan de acá.

Finalmente, un comentario sobre cómo se guardan las fotos bajadas. El script arma el nombre del archivo como, por ejemplo, el siguiente:

    20160507-201900-26273387653_c1da64d753_o.jpg

Básicamente el nombre se arma primero con la fecha y hora de cuando fue tomada la foto, y luego con el nombre original que le puso Flickr.


Regalo de año nuevo: Encuentro 4.0

Software — Martes 05 de Enero de 2016, 17:02


Para arrancar el año pum para arriba, ¿qué mejor que una nueva versión de Encuentro?

Lo más destacado de esta nueva versión es que hay dos backends nuevos!

Por un lado, ahora se puede descargar de Contenidos Digitales Abiertos (también conocido como CDA), con casi 4000 episodios de centenares de documentales y series para mirar.

Por otro lado, trae más de 180 charlas TED del capítulo TEDx de Buenos Aires (que incluye TEDxBuenosAires, TEDxRíodelaPlata, TEDxJoven, y un par más).

Encuentro

También tiene varias mejoras importantes, como que se limpian los nombres de archivos para que puedan ser grabados en cualquier lado (pen drives, fat32, etc), o que rearmé el esquema de downloads y ahora es mucho mucho más robusto que antes. E incluso estuve mejorando los scrappers para backends que ya estaban incluidos en versiones anteriores, pero ahora tendrán mejores títulos, nombres más prolijos, etc.

Y claro, varias correcciones menores también, y seguramente algún par de bugs nuevos :p.

Las instrucciones para bajar Encuentro en tu sistema (Debian, Ubuntu, Arch, Windows, o cualquier otro sistema), junto con el detalle de los cambios, instrucciones, y todo eso, en la página del proyecto.

¡Disfruten!


fades y un hito personal

Software, Python — Lunes 30 de Noviembre de 2015, 22:11


¡¡Salió la versión 4 de fades!!

Mucho mucho laburo le pusimos con Nico a esta versión (y tuvimos bastante ayuda de otros colaboradores, en particular durante el último PyCamp).

¿Pero qué es fades? Es un sistema que maneja automáticamente los virtualenvs de sistemas Python en los casos que uno normalmente encuentra al escribir scripts y programas pequeños, e incluso ayuda a administrar proyectos grandes.

Crea automáticamente un nuevo virtualenv (o reusa uno creado previamente) instalando las dependencias necesarias, y ejecutando el script dentro de ese virtualenv.

Todo lo que se necesita hacer es ejecutar el script con fades (en lugar de Python) y también marcar las dependencias necesarias. Más detalles en la documentación misma.

fades

¿Qué hay de nuevo en esta release?

  • Nueva opción para usar iPython en el interprete interactivo: --ipython (gracias Ariel Rossanigo)
  • Ahora es posible ejecutar un programa dentro del virtualenv con -x (gracias Ricardo Kirkner). Por ejemplo es posible crear un proyecto de django sin tener django instalado en tu sistema usando: fades -d django -x manage startproject foo
  • Podés ejecutar fades como un módulo de python. Simplemente hay que ejecutar python3 -m fades (gracias Javi Mansilla)
  • Soportamos Python 3.3 para ejecutar fades
  • Si sos un usuario especial y no te alanzan las opciones que tenemos tenemos cosas para vos!  Podes pasarle opciones a virtualenv con --virtualenv-options, también a pip con --pip-options, e incluso es posible eliminar un virtualenv con --rm <uuid>
  • Tenemos un logo!! (el que se ve arriba, claro)
  • Los tests de fades se ejecutan con fades! No hay necesidad de instalar nada previamente
  • Se pueden crear virtualevs con --system-site-packages
  • Varios bug fixeados y otros nuevos ;)

Para instrucciones de cómo obtenerlo o instalarlo, miren en la página del proyecto o la de PyPI.

Por otro lado, con Nico habíamos decidido que era importante para fades que puede ser instalado con apt-get install en Debian y Ubuntu.

Entonces, me puse con eso, pedí en el laburo si algún Debian Developer quería darme una mano para meter fades en Debian, y se copó uno de los mejores: Barry Barsaw. Me estuvo ayudando un montón, contestándome preguntas simples y complicadas.

Nosotros ya teníamos un .deb, pero no del todo bien armado. Al final, terminé dando vuelta completamente todo pero quedó todo más simple, más limpio, y con mejor forma. El .deb que generamos es un lujo, y además fades terminó entrando en Debian, en unstable al principio y luego en testing, :D. Es mi primer programa que entra en Debian, y para mí es todo un orgullo :).

El camino natural es que entre en Xenial Xerus (Ubuntu 16.04), que es LTS, así que seguramente liberaremos la v5 la primer quincena de febrero.

Rock.


Magicicada: the evolution of file sync

Software — Miércoles 16 de Septiembre de 2015, 13:28


I spent my first years in at Canonical working in the Ubuntu One project, particularly in what we always called "filesync": the pure file synchronization server (which was propietary at that time), the client, and the protocol (both always open source).

Then, the company didn't push the project anymore, I started to work on other areas, and eventually the project was cancelled. When they cancelled it, they made the promise of opensourcing the server, which will allow to anyone put the full stack to work and have their own personal filesync cloud.

Time passed by, and at some point I got instructions to put daily time on that opensourcing work. I've been working the whole day on this for several weeks, and even more weeks part time, massaging all the code and dependencies for the project to be public. Then the project was released.

Was the project easily usable for anyone to start syncing files? Not really, my goals when working in the project to make it available for everybody were:

  • use only dependencies and libraries from a standard Ubuntu Precise environment and from freely available code from Launchpad
  • "make test" to pass ok, which means that further development can be easily started
  • "make start-oauth" to start and work ok, which means that the server actually works and sync files

However, there's a lot to do for the service to be really used in a production environment where we can put our files and trust it, including but not limited to:

  • keep cleaning the project, lot of quirks and small weirdness to fix
  • make it to store files not in AWS but in the local filesystem
  • (after last item because some internal working reasons involving resumable upload that won't explain here) make it work in Trusty, or even in any modern (Ubuntu or not Ubuntu) environment
  • make it work nicely in a production environment (currently, for example, everytime it starts it uses a fresh database!)
  • simplify it: the server will not longer be used to hold a million users so features like use PostgreSQL in several shards are not worth it anymore
  • and several etceteras

Note that part of this work already started!! Naty Bidart and myself are working actively in some of those points.

Where? Well, with Natalia we already had the Magicicada Project, which was a GUI to interact with the client. So we forked the rest of the projects and naturally put them under that namespace.

So, the whole solution stack currently is:

  • Magicicada Server: the one that "lives in the cloud" and holds the files so all your clients can access them.
  • Magicicada Client: the application that runs in background in each of your computers, uploading/downloading new/changed files from/to the server.
  • Magicicada Protocol: a project with common code between client and server, particularly all the protocol implementation that allows them to talk each other.
  • Magicicada GUI: a small graphical utility that lets you interact and supervise what the client is doing in your computer.


Magicicada

All further work will be done in those projects. If you want to participate please suscribe to the mailing list or say hi in the IRC channel (#magicicada in Freenode). Also, you can file issues for any bug you find or new features/changes you want (be sure to choose the right project: server, client, protocol or gui).

If you're a bzr impaired developer, we have mirrors in GitHub (currently, only for the server, others will be added in the following weeks, ping us if you want any of these to happen sooner).

In any case, you may want to follow the Magicicada twitter account, where will be posting all kind of progress notifications.


Decime quien sos vos

Software — Martes 25 de Noviembre de 2014, 23:07


El título de este post es robado a un maravilloso programa de Eduardo Aliverti.

Es un programa de radio que sale desde hace años por Radio Nacional los domingos a las 10hs. Se basa en una entrevista de Aliverti a alguna personalidad, armando un diálogo tranquilo, profundo, inteligente.

La dinámica es bastante minimalista: sólo Aliverti charlando con el entrevistado. Nada más. La producción es de Roxana Russo, de extensísima carrera, y directora de la carrera de Periodismo en ETER (escuela donde terminé el curso de Locución y Técnicas Vocales hace un par de meses, :) ).

En palabras de ellos mismos:

        "Decime quién sos vos" es un programa de entrevistas tan distendidas como agudas e intimistas donde convergen personalidades emblemáticas del pensamiento, la cultura, el arte, el espectáculo, el deporte.

¿Por qué les cuento esto? En parte porque el programa se merece ampliamente una recomendación: es uno de los (casi ningún) programas de radio y televisión que escucho religiosamente.

Pero también porque van a poder bajarlo de forma fácil usando Encuentro, a partir de la versión 2.1 que acabo de liberar.

Meter "Decime quien sos vos" en Encuentro me llevó *muchísimo* trabajo (incluso tuve que hacer una biblioteca para parsear SWFs en Python), pero la posibilidad de buscar fácilmente entrevistados para poder bajar el programa lo valía.

Entonces, ahora es muy fácil escuchar entrevistas de calidad a (entre otros) Pepe Soriano, Hector Larrea, Teresa Parodi, Carlos Ulanosvsky, Horacio Fontova, Lalo Mir, Horacio Verbitsky, Lito Vitale, Adrián Paenza, Walter Malosetti, Luis Salinas, Roberto Perfumo, Abelardo Castillo, Gonzalo Bonadeo, Luis María Pescetti, Alejandro Dolina, Lito Cruz, etcétera, etcétera, y recontra etcétera.

Bajen/instalen el nuevo Encuentro, refresquen la metadata, y además de todo lo que pueden encontrar ahí, filtren u ordenen por este nuevo programa, y van a ver que el contenido es invaluable.

Que lo disfruten, :)


Un testrunner a todo vapor

Software — Viernes 23 de Mayo de 2014, 01:03


En este post detallé todo lo que querría tener en el testrunner ideal, con la idea de trabajar un poco sobre eso en el último PyCamp.

Así fue. Nos sentamos un rato largo con Martín Gaitán y empezamos a ver si con nosetest podíamos lograr parte o todo de lo que queremos.

Algo en lo que no nos metimos mucho es la integración de nosetests con frameworks que proveen un reactor (o main loop). Buscando un poco ví que hay algo para integrarlo con Twisted, bastante sencillo, pero no encontré nada para GTK o Qt... no sé si porque no se puede, o es automático :p

Entonces, vayamos a los bifes... ¿qué necesitamos para tener el testrunner ideal?

Keep testing


Los componentes

El primer paso, obvio, es instalar el nosetests base. Con esto tenemos el primer par de puntos de lo que queríamos en mi post original: que soporte recibir un directorio y que busque de ahí para abajo, y que al recibir un archivo que corra los tests de ese archivo.

El primer plugin que necesitamos para ir a donde queremos es "nose-progressive". Este es un plugin que nos cambia bastante la forma de ver los resultados de los tests. Por ejemplo, no hace falta que muestre cada linea de cada test ejecutado, en jerarquía, porque ante un error nos va a dar un pequeño resumen donde podemos ver la info del test que falló.

También nos va a dar un lindo OK en verde si todo salió bien... y si hubieron problemas vamos a ver esos resúmenes, coloridos, con un montón de info copada.

De la info que nos da en ese resumen también podemos extraer el path para correr el test sólo, o toda la clase, todo el archivo etc. Pero también tenemos otro plugin, el "nosecomplete" que hace que podamos ir escribiendo el path para un test, autocompletando de una forma muy piola, descubriendo lo que hay para correr.

Para correr más de un test, un subconjunto que matchee con una regex, tenemos el "nose-selecttests", que nos permite pasarle un --select-tests= que hace que le podamos pasar luego aquello que queremos que coincida.

Finalmente, tenemos varios detalles. Le podemos decir que corte en el primer test que falla, y que no siga, con -x. También podemos pedirle que no esconda ni los prints que hagamos ni lo que logueamos, con --nocapture y --nologcapture. Y le podemos pedir que nos tire un buen resumen de cuales tests tardan más con --with-timer (necesitamos el plugin "nose-timer").


Armando el entorno

Lo primero, obviamente en el virtualenv de tu proyecto, es instalar nose y todos sus plugins:

    pip install nose nose-progressive nose-selecttests nose-timer nosecomplete

Para el plugin de autocomplete, como autocompletamos desde el shell, realmente, tenemos que hookear al mismo con el plugin de nose. Es copiar y pegar algo, nada más, las instrucciones acá.

Finalmente, hay que decirle a nose, cuando lo ejecutamos, que use tal o cual plugin, y de qué forma. Acá viene mezclada la mano... algunas configs la podemos poner en el el $HOME/.noserc...

    [nosetests]
    with-progressive=1
    nologcapture=1
    verbose=1

..., pero otras las tenemos que especificar al ejecutarlo:

    nosetests --progressive-bar-filled=2 --progressive-function-color=1 --progressive-dim-color=5

Esto último se podría meter como un alias del bash, o simplemente encapsularlo en un script 'test' en el proyecto (junto con algún pyflakes o pylint, etc).

En fin. Lo importante es: Keep Testing :)


Encuentro 2.0

Software — Sábado 03 de Mayo de 2014, 21:30


Como varias veces ya les conté, Encuentro es un simple programa que permite buscar, descargar y ver contenido del Canal Encuentro, Paka Paka, BACUA, Educ.ar y otros.

Hoy estoy liberando la versión 2.0, una versión importante ya que hace que todo vuelva a funcionar correctamente, luego que Encuentro y Conectate reconfiguraran sus portales. En otras palabras... actualizá, sí o sí.

Encuentro

La versión 2.0 trae los siguientes cambios con respecto a la versión anterior:

  • Vuelve a funcionar luego de los cambios de backend de Encuentro y Conectate
  • Maneja las temporadas de los programas; no se repiten nombres y graba agrupado a disco
  • Sólo anota (y no requiere aprobación del usuario) al tener errores en la descarga
  • Mejor manejo de las imágenes de los episodios, con lo cual ahora se ven las de Bacua
  • Actualiza automáticamente la metadata si se la encuentra demasiado desactualizada
  • El proyecto tiene menos dependencias, es más simple hacerlo funcionar en más sistemas
  • Soporta ser ejecutado en un virtualenv
  • Varias correcciones y detalles para hacerlo más usable y robusto

Hay muchas formas de instalarlo, todo bien explicadito en la página oficial. ¡Que lo disfruten!


Algunas herramientas piolas

Software — Lunes 17 de Marzo de 2014, 22:44


Hace rato que vengo con ganas de hablar acerca de una serie de herramientas interesantes que he encontrado.

Son de lo más variadas. Lo único que tienen en común es que solucionan un problema específico que tuve o tengo. Y que me parece que son piolas :)

Limitando el ancho de banda: ¿Tienen una aplicación que les usa mucho la red? Aunque la misma no esté preparada para autolimitarse, siempre se puede hacer desde afuera, y para ello nos viene a ayudar trickle, un utilitario que hace justamente lo que queremos: ejecutar otro programa limitándo su ancho de banda usable para download, para upload, o ambos.

Midiendo uso de recursos: Muy relacionado con lo anterior, a veces vemos que la red se está usando, pero no sabemos por qué proceso. Para contestarnos esto tenemos dos herramientas, IPTraf y NetHogs,  que nos muestran la info pertinente de forma bastante distinta, por lo cual está bueno tener ambas a mano, para probar cual nos va mejor en cada momento. También nos pasa parecido con el uso del disco. en este caso nos salva las papas el iotop. Para recursos como memoria y CPU tenemos el clásico top, obviamente, pero muchas veces uso htop que es más interactivo y me facilita la exploración.

Fijate si cambió:¿Alguna vez les pasó que tiran un comando en la terminal cada algunos segundos para monitorear algo, tratando de ver si algún dato cambia o viendo cómo cambia? En estos casos lo mejor es usar watch, que nos ejecuta el programa que queremos, cada los segundos que le especificamos, y encima nos resalta los lugares donde hubo cambios con respecto a la ejecución anterior. Más útil de lo que parece.

Mandando muchos mails:Me pasa seguido, para organizar jodas en casa, o eventos en PyAr, o cursos, etc, que tengo que mandar el mismo mail a mucha gente. Mandar uno por uno es mucho trabajo; mandar todos en "copia oculta" es muy impersonal; y ponerlos a todos en "copia visible" es una mala práctica. Por suerte está Mail Merge, un plug-in para Thunderbird que hace todo sencillo: uno pone todos los destinatarios en el campo de "Para:", pero luego en lugar de hacer click en "Enviar", se elige la opción de MailMerge, y en vez de salir uno para todos, el plug-in manda un mail a cada uno. Limpio, y útil. Y tiene opciones para lograr cosas más complejas, pero no lo exploré demasiado, con esta funcionalidad básica por ahora me alcanza.

Seguridad, seguridad: Por último, la herramienta que más me tiene fascinado estos últimos tiempos. Se llama KeePassX, y marcó un antes y un después en mi administración de contraseñas. En el pasado, yo tenía tres o cuatro claves... una genérica, una para lugares de "alta seguridad" como el banco, etc, y las repetía en varios sitios. Así y todo, las claves no eran demasiado complejas (usaba mayúsculas, minúsculas y números, pero no caracteres extraños, y nunca superaba los 10-12 caracteres). ¿Por qué? ¡Por que me las tenía que acordar! Con KeePassX, sin embargo, ya no me las tengo que acordar: se guardan en un archivo (cifrado con una clave que sí tengo que acordarme, y la hice complicada y larga, pero es una sola). El programa no es mucho más que eso, pero también te permite relacionar campos con la clave (en qué sitio va, el nombre de usuario,etc), y también tiene campos genéricos donde uno puede escribir cualquier cosa. Ah, y también te autogenera claves... entonces, la realidad es que ni siquiera veo las alguna vez! Todo esto, sumado a la facilidad de uso (por ejemplo, ctrl-B sobre una entrada te copia el nombre del usuario, y ctrl-C te copia la clave) y que tiene clientes para muchas plataformas (incluida Android), hace que sea una herramienta maravillosa.


Un largo camino al .exe

Software — Miércoles 29 de Mayo de 2013, 12:43


Algunas versiones de Encuentro (si no recuerdo mal la 0.5 y 0.6) estaban empaquetadas para Windows (con instalador y todo).

Pero hacer ese trabajo era un perno. En este caso lo hacía un muchacho que se llama Javier Andalia, pero después no lo continuó. El drama es básicamente que GTK, la biblioteca que se usaba para la interfaz gráfica es muy poco amigable para hacerla andar en Windows. Siempre fue un dolor de muelas, lo sigue siendo, y no creo que cambie.

Todo empeoró cuando del lado del server cambiaron todo obligándome a cambiar un montón de cosas de mi lado. Ahí salió la versión 0.7, que funcionaba correctamente con el estado actual de situación, pero dejaba a los usuarios de Windows sin tener algo que les funcione.

Y la verdad es que el contenido de Encuentro, Conectate, BACUA, etc, está buenísimo y da para que lo disfruten todos, aunque el usuario tenga un sistema operativo de mierda.

Entonces, encaré el laburo de migrar de GTK a Qt. Y una vez estuvo eso, empaqueté nuevamente para Windows y armé el instalador.

Luego de un par de semanas de "beta", tengo el orgullo de presentarles Encuentro 1.0, :D

Es una release rara porque a nivel funcionalidad real no hay mucho impacto, pero internamente cambió todo.  Igual, lo importante acá es el nuevo público al que puede llegar.

Ah, y mañana jueves con Diego Mascialino (el otro gran desarrollador de Encuentro) hacemos la release party de esta versión... o sea, nos juntamos a tomar algo y jugar unos pooles en Wrangler's... el que quiere venir que venga, están todos invitados! (pero cada uno se paga lo suyo :p).


Kilink, el pastebin útil

Software — Domingo 05 de Mayo de 2013, 22:03


Con el gran Nico César hace tiempo definimos lo que serían los términos de un servicio que queríamos ofrecer. Por cuestiones varias de la vida, al final nunca terminamos armando algo que cumpla con todos estos requisitos, aunque arrancamos con el proyecto. Pero lo arrancamos en un repo privado.

Muchos meses después, viendo que jamás vamos a seguir eso, le pedí permiso para liberar el código y las especificaciones que armamos. Entonces, subí el código del proyecto a GitHub, y tengo reservado el dominio kilink.com.ar para ofrecer el servicio ahí.

Este proyecto, entonces, lo declaro abierto a la comunidad, para el que quiera participar, participe. Yo lo voy a empujar en el PyCamp de este año!


Descripción general

La idea es ofrecer un "espacio de colaboración de corta vida".  Algo así como un pastebin dinámico, pero que al mismo tiempo sea fácil de usar. En definitiva, algo útil.

Los kilinks van a poder ser editables, y cada nueva edición será hija del kilink editado (cada "submit" es un commit en un virtual versionado de código). Aclaración importante de terminología: el kilink es *uno solo*, que tiene distintas versiones; este kilink único tiene siempre la misma URL, el mismo "kilink id".

Habrá tener coloreado de código, como todos los pastebines, pero con dos grandes diferencias: detección y coloreado automático de tipo de texto, y edición coloreada.

La autenticación será lo más sencilla posible para que un visitante pueda decir "soy Fulano" en la menor cantidad de clicks posibles. La idea es ofrecer de esas autenticaciones que son tan automágicas ahora: openid, via twitter, o facebook, etc, o de última un "usuario/clave" por si la persona no tiene ninguno de los otros mecanismos fáciles.

No hay mecanismos de "compartición" de los kilinks: cualquiera puede acceder a cualquier kilink (en general por la URL que se comparte, pero también buscando, ver abajo).

La autoría del kilink y la responsabilidad sobre ese texto es del usuario que lo pegó ahí. Hay que declinar explícitamente responsabilidad.  El texto incluido en el mismo es de "dominio público" y puede ser mostrado/usado indiscriminadamente.

¿Por qué usar kilink?

  • Se puede usar anonimamente...
  • ...pero recuerda quien sos
  • Permite compartir un texto en pocos clicks
  • Se da cuenta del lenguaje
  • Es amigable a nivel de interfaz
  • Copia el texto directamente a tu clipboard
  • Se puede integrar el texto en donde quieras, por versión o siempre actualizado!


Facilidad de uso / primera impresión

El diseño tiene que ser simple y efectivo, orientado a bajar la barrera de entrada del visitante, el "costo" que el usuario tiene que pagar desde que llega a la página hasta que tiene el kilink en su portapapeles para pegarlo en otro lado. Esto se ve en varios detalles, por ejemplo:

  • que el cursor por default esté en el textarea destino
  • que el textarea, en lugar de estar 100% vacío, tenga adentro un "pegar acá" o algo similar en gris, suavecito, que desaparezca al pegarle algo.
  • que entre el textarea y el botón de submit no haya nada que distraiga
  • que el botón de submit se llame "crear kilink" o lo que corresponda
  • que pueda llevar la url del kilink creado sin tener que seleccionar un texto
  • que se pueda crear un kilink sin registrarse ni loguearse
  • botones para copiar automaticamente al clipboard: URL y texto del kilink
  • download as file
  • botón de imprimir, y CSS especial para que quede linda la impresión
  • etc

Visualmente, la página tiene que ser lo menos intrusiva posible, hay que minimizar la "polución visual", pero sin dejar de ofrecer la información necesaria (al hacer hover con el mouse, o en colores que no llamen demasiado la atención).

Otras características:

  • una URL o kilink ID que casi funciona como  URL corta, ej: kilink.com.ar/4g3jxd
  • el contenido del kilink debería ser indexado por google y otros buscadores


Contribución anónima

Se va a poder crear o editar un kilink sin tener que registrarse ni loguearse, pero va a aparecer "Anonymous" como autor (o algo más divertido).

Dicho esto, al usuario le conviene autenticarse, ya que de esta manera puede tener distintas ventajas:

  • Es autor de los tuits que cree (figura su nombre, digamos)
  • Como es autor, puede borrar sus tuits
  • Tiene en su perfil preferencias para adaptar mejor kilink a sus necesidades (habría que ver cuales :p )


Edición, versionado, diffs

Un gran detalle con respecto a la edición es que va a ser "in place". En otras palabras, en lugar de ofrecer un texto estático y un área nueva (como la mayoría de los pastebines), queremos mostrar el texto del kilink, y que el usuario lo pueda editar ahí mismo.

Obviamente, poder editar nos va a generar una estructura de árbol para las versiones. Este árbol será mostrado de forma explícita en la interfaz web, pudiendo el usuario hacer click en cualquiera de los nodos, viendo las distintas versiones del mismo kilink. Al mostrar las distintas versiones como nodos de un árbol se evita confundir al usuario con cosas como versiones "hermanas", "padres" o "hijas". El usuario ve la versión que tiene elegida, y si la edita aparecerá un nuevo nodo hijo del que estaba viendo.

También, se podrá elegir dos versiones, y pedir un "diff" entre las mismas.


Coloreado del texto y tipo del mismo

¿Qué es la autodetección? En lugar del funcionamiento "pastebin clásico" (de pegar un texto y elegir qué tipo de texto es), cuando el usuario pegue el texto se debe autodetectar qué tipo de texto y colorearlo en el momento según el tipo detectado. Obviamente, va a haber un combobox con todos los tipos, que cambia automáticamente al tipo autodetectado, pero que el usuario puede modificar para rectificar una autodetección erronea (obviamente, si el usuario cambia a mano el tipo de texto, el coloreado cambiará correspondientemente).

La "edición coloreada" es la habilidad de poder editar el kilink y que se vaya coloreando mientras se edita (recordemos que vamos a mostrar un sólo texto y el usuario podrá editar directamente allí).

Ambos comportamientos no son fáciles de lograr, pero facilitaría mucho la interacción del usuario, y quizás con herramientas como google-code-prettify no sea tan complicado.


Caducidad de los kilinks

Los kilinks serán permanentes, nunca vencen y siempre estarán online, a menos que el autor del mismo los borre explícitamente. Esta no-caducidad hay que comunicarla explícitamente, pero aclarando que no nos hacemos cargo si un kilink desaparece por problemas ajenos o propios, o por la baja del servicio.

Con respecto a que los usuarios puedan borrar kilinks, sólo será posible si el usuario es el autor del mismo.

Como esta es una acción poco probable (nadie borra un paste, a menos que se de cuenta que metió info muy sensible o demasiado privada), la idea es que sólo se pueda hacer desde la página de perfil del usuario, para no ensuciar la interfaz de uso "normal".


Herramientas

Hay que tener una colección de herramientas, entre ellas:

  • plugin para editores (seleccioná el texto → kilink, salta a la pag web con el kilink ya creado)
  • plugin para navegador (seleccioná el texto → kilink, idem)
  • linea de comando ("grep ERROR *.log | kilink" y este escupe la url de un kilink nuevo)
  • applet que permita meter una "ventanita para rápidamente crear kilinks" en cualquier lado
  • applet que permita meter un "visualizador de un kilink particular" en cualquier lado
  • applet que permita meter "mis últimos kilinks" en cualquier lado


Tags

Los kilinks tendrán tags asociados, los cuales se crearán de forma semimanual, y servirán como filtros.

Habrá un área cerca del texto donde haya una colección de tags. Al crear un kilink, al momento de pegar el texto, en esa zona aparecerán N tags sugeridos por el sistema (luego de analizar el texto), el usuario puede borrar alguno de esos tags, o agregar más.

Mecanismos para autosugerir tags:

  • lenguaje de programación usado (if any)
  • bibliotecas específicas usadas en el código


API

Se debe implementar una API HTTP sobre la cual se podrá hacer todo lo que se pueda hacer, al punto que la interfaz web usará esa misma API para trabajar contra el backend.

La API tendrá dos modos: autenticado y público. Para el modo público no se necesita nada en particular, pero no se puede hacer todo desde ahí (por ejemplo, borrar kilinks).

Idea: Debemos revisar las APIs de pastebin, snip y tinypaste, que son las más piolas que vimos, para diseñar de entrada algo que tenga sentido. También hay que ver cómo autenticar.

Idea: Ofrecer en el sitio bindings para distintos lenguajes de programación.


1 2 3 4 5  Siguiente»

Powered by LifeType