joe di castro

Vim as Python code editor

2013-08-20T16:53:00+02:00

This article is a translation from the original one in Spanish, Vim como editor de codigo Python, published in April 2013.

This is an article that I've always wanted to write: "Vim as Python IDE". Two years ago I had a Vim configuration that I thought that was just right for this, even a half-written article. But while I was polishing the config and finishing the article, a bunch of similar articles appeared in the internet and after reading them I realized something: many of them were already obsolete at the time they were published. And I say this because many of them employed plugins that were outdated by the emerge of other fresh and more powerful. In fact in the last two years, the Vim environment has evolved too much that from all the plugins that I used in those days (and the ones pending to test), currently I'm using only 10% of them, the rest are new ones. And this "race" to provide new and more powerful features for Vim continues nowadays, with some great tools.

On the other hand, as one is adding plugins and "tuning" his config, there comes a time when you don't know where and what is already mapped, even no remember at all the plugins at features available for you, and which you implemented with so much effort and time.

My configuration

Given these two premises I had the idea of kill two birds with one stone: Document my Vim setup. What I'm trying with this is that should work for me as sort of cheat-sheet to remember all that I had available in my config, and at the same time to have a coherent mapping and avoid duplicates (at least is the idea). By the other hand, it works also to demonstrate all the Vim's potential to edit Python code and compete with almost any IDE, but with all the advantages of the unique Vim's way.

The idea is to have a continuously updated document with respect to my current setup, What better article than this, an always updated one?

This is the link to this doc, README.md, included in my dotfiles repository:

Doc at GitHub

English is not my mother tongue, so maybe the article (and the doc) can be full of grammatical mistakes due to my poor English. Sorry for that, I did my best.

Vim como editor de codigo Python

2013-04-08T10:29:00+02:00

Este es un articulo que siempre he deseado escribir: Vim como IDE para Python. Hace dos años tenia una configuración de Vim que creía ideal para esto e incluso el articulo a medio escribir. Pero a medida que iba puliendo la configuración y completando el articulo, empezaron a surgir varios similares en la red (sobre todo en inglés) y caí en la cuenta de algo: muchos ya estaban obsoletos al publicarse. Y cuando digo esto lo digo porque muchos de estos artículos empleaban plugins que se habían quedado desfasados por la aparición de otros mas recientes y potentes. De hecho en los dos últimos años ha cambiado tanto el panorama en el ecosistema en torno a Vim, que de la lista de plugins que empleaba por aquel entonces (y los que tenía pendientes de probar) solo empleo actualmente el 10%, el resto son nuevos. Y esta "carrera" por nutrir a Vim de características nuevas y cada vez más potentes continua hoy en día, con algunas herramientas excelentes.

Por otro lado, a medida que uno va añadiendo plugins y "tuneando" su configuración llega un momento que ya no sabes ni donde tienes "mapeados" los atajos, ni recuerdas todas las características que tienes a tu disposición y tanto tiempo empleaste en implantar.

Mi configuración

Partiendo de estas dos premisas se me ocurrió una idea de atajar los dos problemas de un golpe: Documentar mi configuración. Lo que trato por un lado es que me sirva personalmente tanto para recordar todo lo que tengo disponible en el editor, como para poder organizar coherentemente todos los atajos y evitar duplicados. Por el otro lado, también me sirve para la idea de demostrar el potencial que tiene Vim a la hora de ser un editor de código que puede estar a la altura de cualquier IDE, pero con todas las ventajas inherentes a la filosofía única de Vim.

La idea es que el documento esté permanentemente actualizado a la par que mi configuración real, ¿que mejor articulo que este, que siempre estará actualizado?

La configuración está documentada en un README.md dentro de la carpeta de Vim del repositorio de mis dotfiles. Aquí se puede acceder directamente a mi configuración y ver el documento. Actualmente el articulo está en Inglés, aquí se pude acceder a la última revisión en español.

Documento en GitHub

Productividad & Linux: Ranger

2012-10-18T21:50:00+02:00

Algunos pensarán, de acuerdo, podemos entender que prefieras un gestor de ventanas de mosaico, o que emplees aplicaciones como Pentadactyl, Newsbeuter, Zathura o Turses, pero Ranger... ya es demasiado. ¿A quien en su sano juicio se le ocurriría utilizar semejante engendro? A mí, y no solo lo utilizo a diario, si no que además opino que es quizás la mejor aplicación que he descubierto en el último año y medio. Y esto último es mucho decir para alguien, que como yo, está continuamente buscando formas de mejorar su modo de trabajo.

Ranger es un administrador de archivos en modo texto. Pero no es un administrador de archivos en modo texto clásico a dos columnas, como el norton commander y similares. No, Ranger es una pequeña joya con un planteamiento distinto y tan potente, que puede conseguir que olvides que no podías vivir sin un gestor de archivos gráfico como Nautilus, Konqueror, Dolphin o Thunar.

Ranger

Tengo que estar enormemente agradecido a su autor, Roman Zimbelmann no solo por su trabajo, si no por mostrarme que incluso en modo texto, se puede revolucionar el mundo de la usabilidad. Evidentemente, en una aplicación que basa su control en el teclado (tiene un soporte muy básico del ratón), es requisito imprescindible invertir algún tiempo en aprender a utilizarlo, ya que no es tan intuitivo como una aplicación gráfica. A menos que seas un usuario típico de Vim, entonces te encontrarás como en casa. Una vez que dominas esta aplicación, el moverse entre los directorios y el realizar operaciones se hace a velocidad de vértigo y con control absoluto (siempre que no seas un manazas con el teclado).

Ranger está desarrollado en Python y emplea una interfaz ncurses igual que Turses. Al contrario de lo que algunos puedan pensar, el estar desarrollado en Python no lo convierte ni en pesado ni en lento, si no que se mueve a velocidad endiablada y consume una cantidad de memoria ridícula comparada con cualquier gestor de archivos gráfico.

Aquí puede verse una imagen típica de ranger, visualizando el contenido de un directorio y previsualizando el contenido de un fichero, en este caso un fichero de código python.

Características

¿Qué se puede hacer con ranger?, bueno, quizás es mejor preguntarse que no se puede hacer con Ranger. Prácticamente todas las funciones a las que estés acostumbrado en un administrador de archivos gráfico se pueden realizar con Ranger. Vamos primero a ver un resumen de sus características:

Soporte de UTF-8 por defecto
Visualización en múltiples columnas
Previsualización del directorio o fichero seleccionado
Operaciones comunes sobre los ficheros. Crear, copiar, borrar, cambiar atributos (chmod), etc...
Combinaciones de teclado y consola inspiradas en Vim
Autodetección de tipos de fichero y apertura de los mismos con el programa adecuado
Permite establecer etiquetas y marcadores sobre archivos y directorios
Empleo de pestañas. Nos permite navegar por varios directorios simultáneamente sin necesidad de abrir otra instancia del programa. Además se pueden realizar operaciones entre ellas
Muestra una barra de progreso para las operaciones que lo necesitan

Conviene dejar claro que no es un programa para impacientes, hacerse con él y sus innumerables opciones requiere tiempo. Hay que leerse la ayuda del programa y practicar con él. A su vez, si queremos personalizar las opciones o ampliarlo, debemos comprender como funcionan sus archivos de configuración, mejor aún si tenemos conocimientos de Python. La documentación de su web, así como la de sus páginas man está un poco desactualizada, por lo que sacarle todo su jugo requiere algo de paciencia.

Ejemplos

Voy a intentar dar algo de visibilidad a algunas de las capacidades que nos ofrece ranger empleando una par de ejemplos que lo ilustren.

En el siguiente ejemplo vemos la previsualización que hace ranger en función del tipo de fichero que se trate.

Previsualización de archivos en ranger con varios tipos de archivo. Recomiendo ver en alta resolución y a pantalla completa.

La previsualización de imágenes en ASCII puede parecer una tontería, pero resulta muy útil a la hora de diferenciar entre distintas imágenes con nombre muy parecido. El fichero en HTML está renderizado en vez de mostrarnos el texto plano, algo más amigable. También se agradece mucho el que los ficheros de código se vean con resaltado de sintaxis.

Conviene aclarar que para realizar esta previsualización es necesario tener instalado una serie de pequeñas aplicaciones que se detallan en el sitio de ranger como dependencias.

Aquí vemos como se abren automáticamente los programas adecuados en función del tipo de archivo (se puede configurar que aplicaciones emplear y cuales usar en cada momento)

Ejecución automática de aplicaciones en función del tipo de archivo. Recomiendo ver en alta resolución y a pantalla completa.

En el caso del fichero Torrent, al que no tengo asociada ninguna aplicación en ranger, me abre un comando en el que puedo especificar directamente la aplicación que deseo emplear para gestionarlo. En este caso, ninguna. En el archivo comprimido solo me muestra el contenido del mismo, podría asociarle alguna aplicación, pero ya tengo comandos para manejarlos dentro del propio ranger, algo que veremos a continuación.

Mi configuración

No he personalizado mucho mi configuración de momento, pero quien quiera echarle un vistazo puede hacerlo en mi repositorio dotfiles en GitHub

Archivos de configuración

Para configurar ranger necesitamos editar ciertos archivos, que crearemos por primera vez con el siguiente comando:

$ ranger --copy-config=all

qué nos creara los siguientes archivos por defecto en la carpeta ~/.config/ranger/:

commands.py (python), en este archivo se configuran los comandos a emplear en la línea de comandos de ranger
options.py (python), el fichero de opciones principal de ranger
rc.conf (texto), aquí configuramos los atajos de teclado de ranger
rifle.conf (texto), para establecer los programas que ejecutaran o abrirán un tipo de archivo en orden de preferencia
scope.sh (bash), los programas empleados para previsualizar un determinado tipo de archivo

Adicionalmente, con el uso se añadirán tres ficheros más: bookmarks, history y tagged que guardarán los marcadores, la historia de comandos y las etiquetas respectivamente.

Gestionar la papelera

Por defecto ranger no contempla la gestión de la papelera de Linux que implementan escritorios como Gnome. Aunque no empleo ningún entorno de escritorio ni gestores de archivos gráficos, si me interesa gestionar la papelera, pues cada vez más aplicaciones la emplean para eliminar los archivos. De hecho en bash y zsh tengo un alias para rm que mueve los archivos a la papelera en vez de eliminarlos.

alias rm='mv --target-directory ~/.local/share/Trash/files'

Para gestionar la papelera desde ranger, añado dos atajos de teclado y un comando editando varios archivos de configuración de la siguiente manera:

Mandar archivos a la papelera

Para mandar a la papelera lo que tengamos seleccionado actualmente, en lugar de eliminarlo directamente, añadimos esta línea al fichero rc.conf

# move to trash
map DD shell mv -t ~/.local/share/Trash/files %s

de este modo, cada vez que pulsemos DD el contenido seleccionado es movido al directorio donde tenemos nuestra papelera.

Movernos a la papelera

Del mismo modo que ranger provee por defecto de atajos de teclado para movernos al directorio home, al directorio raiz, etc, he añadido un atajo de teclado siguiendo el mismo criterio para acceder a nuestra papelera. Añadimos lo siguiente al fichero rc.conf

# go to trash
map gp cd ~/.local/share/Trash/files

así, pulsando gp vamos directamente a la papelera, estemos donde estemos.

Vaciar la papelera

Para vaciar la papelera opto por emplear un comando, para ello tenemos que editar otro fichero, commands.py, y añadir lo siguiente

class empty(Command):
    """
    :empty

    Empties the trash directory ~/.local/share/Trash/files

    """

    def execute(self):
        self.fm.run("rm -rf ~/.local/share/Trash/files/{*,.[^.]*}")

por lo que vaciar la papelera se convierte en algo tan simple como teclear :empty o para los más cómodos :em↹

Desmontar una unidad con udiskie

Dada mi "particular" configuración, ya que no empleo ningún escritorio, empleo la herramienta udiskie para automontar unidades de almacenamiento externas, como unidades USB o tarjetas de memoria. El montado se hace de forma automática y solo el desmontado ha de hacerse de forma manual. Ya que no quiero teclear el comando cada vez que desee desmontar una unidad, lo que hago es hacerlo desde ranger. En el fichero rc.conf mapeamos este atajo

# umount a drive with udiskie
map un shell -d udiskie-umount %d/%f

así para desmontar una unidad inicio ranger (en mi caso Win + F1), me dirijo a las unidades externas montadas, gm, selecciono la unidad deseada y la desmonto, un. Un proceso que me lleva apenas dos segundos, sin abandonar las manos del teclado, compárese con hacerlo con un ratón y un entorno gráfico.

Expulsar un CD/DVD

Del mismo modo, en lugar de abrir un terminal y escribir el comando eject, en determinadas circunstancias, por ejemplo al acabar de examinar el contenido de un disco, prefiero hacerlo directamente desde ranger. Para ello en el fichero rc.conf creamos este atajo de teclado

# eject a CD-ROM/DVD
map ej shell -d eject

Trabajar con archivos comprimidos

Estos comandos los he sacado de el Wiki de Arch Linux y los he adaptado a la versión de ranger que estoy empleando en este momento, la 1.5.5

Extraer los ficheros de un archivo comprimido

Con el comando :extracthere extraemos el contenido de un archivo/s comprimido que previamente habremos seleccionado para copia (es decir empleando el atajo yy). El contenido se extrae en el directorio en el que nos encontremos actualmente. Es muy comodo para extraer múltiples archivos comprimidos a la vez, si quisieramos descomprimir solo un archivo y en el mismo directorio en el que este se encuentra, podríamos emplear el atajo 1l

Para añadir el comando a ranger, tenemos que insertar esta clase en el fichero commands.py

class extracthere(Command):
    def execute(self):
        """ Extract copied files to current directory """
        copied_files = tuple(self.fm.env.copy)

        if not copied_files:
            return

        def refresh(_):
            cwd = self.fm.env.get_directory(original_path)
            cwd.load_content()

        one_file = copied_files[0]
        cwd = self.fm.thisdir
        original_path = cwd.path
        au_flags = ['-X', cwd.path]
        au_flags += self.line.split()[1:]
        au_flags += ['-e']
        self.fm.env.copy.clear()
        self.fm.env.cut = False
        if len(copied_files) == 1:
            descr = "extracting: " + os.path.basename(one_file.path)
        else:
            descr = "extracting files from: " + os.path.basename(one_file.dirname)
        obj = CommandLoader(args=['aunpack'] + au_flags \
                + [f.path for f in copied_files], descr=descr)
        obj.signal_bind('after', refresh)
        self.fm.loader.add(obj)

Crear un archivo comprimido

Este comando te permite seleccionar uno o varios ficheros y crear un archivo comprimido al llamar al comando :compress. Este comando te permite (a través del autocompletado) darle un nombre automático a partir del directorio o uno personalizado. Te permite además seleccionar el tipo de compresión en función de la extension empleada.

En el fichero commands.py añadimos el siguiente código.

class compress(Command):
    def execute(self):
        """ Compress marked files to current directory """
        cwd = self.fm.thisdir
        marked_files = cwd.get_selection()

        if not marked_files:
            return

        def refresh(_):
            cwd = self.fm.env.get_directory(original_path)
            cwd.load_content()

        original_path = cwd.path
        parts = self.line.split()
        au_flags = parts[1:]
        descr = "compressing files in: " + os.path.basename(parts[1])
        obj = CommandLoader(args=['apack'] + au_flags + \
                [os.path.relpath(f.path, cwd.path) for f in marked_files], descr=descr)
        obj.signal_bind('after', refresh)
        self.fm.loader.add(obj)

    def tab(self):
        """ Complete with current folder name """
        extension = ['.zip', '.tar.gz', '.rar', '.7z']
        return ['compress ' + os.path.basename(self.fm.thisdir.path) + ext for ext in extension]

Productividad & Linux: Turses

2012-06-21T22:50:00+02:00

Que medio mundo parece estar conectado a Twitter no es ninguna novedad. Y que si sigues a un buen número de personas, el intentar estar al tanto de todo lo que ocurre es una temeridad, tampoco debería sorprender a nadie. De hecho, dado su éxito y el enorme flujo de información que circula por él, se han desarrollado cientos de herramientas para gestionarlo.

Desde que cree mi cuenta en twitter, he probado unas cuantas, unas veinte (y solo en Linux, en el resto uso la web). La primera, y la elección más obvia ya que por aquel entonces usaba Ubuntu, fue Gwibber . Luego cansado de sus muchos problemas, probé un sinnúmero de aplicaciones, solo merece la pena reseñar una: Hotot. Es la mejor aplicación gráfica para twitter en Linux que conozco.

Pero guiado por el mismo objetivo de mejorar la productividad en mis herramientas habituales de trabajo, me lancé a la búsqueda de un cliente de twitter que encajara en la misma filosofía. No hay muchas alternativas, la mayoría, hay que reconocerlo, son demasiado "crudas" incluso para mí, que soy un amante de la consola. Pero entonces dí con una pequeña joya, Tyrs, desarrollada por Nicolas Paris. Era una herramienta sencilla, pero que cumplía muy bien con todo lo que buscaba de ella. Pero un buen día, Nicolas, en su afán por mejorarla, empezó a reescribir la herramienta empleando una nueva librería para gestionar el interfaz. Las primeras versiones tenían varios fallos y Nicolas pronto se vio desbordado por una tarea que no le apetecía continuar y a la que no podía dedicar más tiempo. Y decidió abandonar el proyecto, con la esperanza de que alguien se atreviera a retomarlo. Cuando leí la entrada de su blog no perdí la esperanza del todo, al fin y al cabo, estaba desarrollado en Python, un lenguaje con el que me desenvuelvo. Mientras esperaba que hacer, seguí usando la última versión estable a diario. Pero entonces, apareció el milagro, Turses

Turses

Alejandro Gómez, un usuario de Tyrs se lanzó a crear su propia aplicación basándose en él. Y no solo garantizaba la continuidad del buen trabajo empezado por Nicolas, si no que llegaba lleno de ideas frescas y muchas ganas de hacerlo bien. El propio Nicolas le felicitó por el trabajo y la iniciativa. A día de hoy, el proyecto se sigue desarrollando, y aunque aún tiene algunas metas marcadas por delante, la aplicación es perfectamente usable en el día a día, de hecho es mi cliente habitual.

Como ya se habrá podido deducir, Turses es un cliente de twitter para la consola con interfaz ncurses. Está desarrollado en Python y emplea la librería Urwid para crear la interfaz en curses. Lo mejor de esta aplicación es que emplea atajos de teclado inspirados en Vim y es totalmente controlable desde el teclado. Esto unido a que emplea una interfaz basada en texto, la convierten en la aplicación más ágil de todas las que haya probado. Hotot también tiene algunas combinaciones de teclas muy útiles, pero ni se acercan a lo que Turses te permite.

Aquí se puede ver el aspecto por defecto de Turses

Pero no se acaban ahí las bondades de Turses, tiene algunas características geniales como la gestión dinámica de bufferes (líneas temporales) y de columnas. Demos un repaso a lo que nos permite la aplicación:

Múltiples líneas temporales (bufferes). Es decir, nos permite consultar los tweets de la gente a la que seguimos, los nuestros, menciones, etc. Es decir, los bufferes habituales, incluidos conversaciones, búsquedas y hashtags. Y podemos tenerlas simultáneamente abiertas y navegar entre ellas muy fácilmente.
Múltiples columnas. En cada columna se sitúa un buffer, y podemos añadir o quitar columnas a voluntad de forma muy sencilla. Es decir, que podemos visualizar un solo buffer de forma predefinida, o podemos ver varios a la vez distribuidos en múltiples columnas.
Tweet, Reply, Retweet, Borrar. Vamos, que permite las operaciones habituales con los tweets. Además se puede hacer un Retweet editando el texto, algo que parece obvio, pero que en algunas aplicaciones no es tan sencillo.
Seguir/dejar de seguir a un usuario. Podemos hacerlo bien a través de un tweet o bien introduciendo el nombre del usuario.
Des/Marcar como favorito.
Enviar mensajes directos.
Abrir URLs en un navegador. Nos permite abrir las direcciones que aparecen en un tweet, así como abrir el propio tweet.
Visualizar conversaciones. Podemos abrir un nuevo buffer con la conversación relacionada con un tweet.
Contador de los no leídos funciona para todos los bufferes y nos permite ponerlo a cero manualmente cuando queremos ignorar algunos no leídos.
Búsqueda. Se puede buscar tanto por usuario como por termino.
Ver los tweets de cualquier usuario .
Visualizar el perfil de un usuario.
Totalmente personalizable y la configuración se guarda en un fichero de texto plano.
Múltiples cuentas, eso sí, una por ejecución.
Ayuda en línea con todas las combinaciones de teclas posibles. Accesible a través de la tecla ?

Interfaz de Turses mostrando múltiples columnas

Y entre las metas que tiene marcadas su autor, nos encontramos con el soporte para listas, streaming, notificaciones emergentes y múltiples sesiones. Estoy seguro de que las acabará incorporando, le sobra capacidad. Aunque he de reseñar que actualmente he contribuido con una porción de código minúscula al proyecto y que tengo la intención de seguir colaborando en todo lo que pueda. Si eres programador Python y te apetece echar una mano, anímate, Alejandro es muy receptivo y un tío muy majo que estará encantado con toda la ayuda que le podamos dar.

Mi configuración

Si a alguien le puede servir como inspiración mi configuración, esta disponible en GitHub

Turses mostrando la información del perfil del autor de un tweet

Alternativas

Solo conozco dos alternativas en la misma línea que merezca la pena reseñar, las demás que he probado no estaban a la altura:

TwitVim, es un plugin para Vim. Funciona fantásticamente bien, eso sí, solo apropiado para usuarios de Vim. La probé un tiempo y me gusto, pero personalmente no me gusta emplear Vim para esta tarea y Turses es bastante más manejable.
TTYtter, está escrito en Perl y no tiene interfaz. Trabaja en la línea de comandos a modo de interprete. Funciona muy bien y también lo usé un tiempo, pero su propio funcionamiento le reste eficiencia comparado con Turses.

Productividad & Linux: Newsbeuter

2012-06-18T23:26:00+02:00

Uno de los pilares de la productividad es, como no, la gestión del tiempo. Otro de los pilares fundamentales es, inexorablemente, el conocimiento. Si pierdes el tiempo en tareas irrelevantes (o directamente procrastinando), tu productividad se resiente irremediablemente. Si no tiene los conocimientos adecuados y suficientes, consumes el tiempo aprendiendo a hacerlo o directamente lo pierdes haciéndolo mal. Hoy en día, rara es la actividad donde la formación continua no sea un requisito indispensable, no ya para mejorar o mantener tu rendimiento, si no simplemente para poder seguir ejerciéndola.

Por lo tanto nos vemos condenados a intentar mantenernos al día (y ampliar conocimientos), mientras que procuramos dedicarle el menor tiempo posible para no menoscabar nuestro rendimiento. Tal delicado equilibrio no es poca hazaña en nuestros días. Nos vemos inundados de tal cantidad de información, que el filtrado es la única manera de intentar sobrevivir a esa enorme vorágine de datos a la que nos enfrentamos. Afortunadamente tenemos herramientas. Desde hace muchos años he confiado esta tarea a emplear fuentes RSS de calidad y una buena herramienta para gestionarlas.

Mi búsqueda del cliente RSS ideal

He empleado muchas herramientas distintas para esta tarea, siempre intentando tener la más idónea para filtrar muchas fuentes RSS en el menor tiempo posible, sin pasar por alto lo que me interesa conocer. Algunas muy buenas, que usaba cuando aún empleaba Windows como SO principal, ya no existen. En Linux he pasado por las más conocidas (en orden cronológico):

Liferea, era muy buena cuando la deje, lo de mostrar los comentarios en las entradas es algo que no he vuelto a ver en ninguna otra herramienta. Pero después de varios años de uso, la abandoné cuando se había convertido en insufriblemente lenta.
Akregator, no era para mí, nunca acabe encontrándome a gusto con ella. Lo hacía todo medianamente bien, pero no destacaba en nada, pronto la abandoné.
Blogbride, su planteamiento es diferente al resto. Es una buena aplicación y estuve con ella muchos meses. Pero siempre seguí buscando algo más eficiente.
RSSOwl, la mejor aplicación para leer RSS para escritorio que he conocido. La he usado durante años. Está construida sobre Eclipse. Ofrece muchas posibilidades de personalización y filtrado. Es muy rápida, pero debido a que depende de Eclipse y java, si manejas un número considerable de fuentes (+1000 en aquella época), se puede volver un poco pesada. Además, si como yo, dejabas muchos artículos para leer en otro momento, la base de datos crecía de tal manera, que podía llegar a ser muy lenta. La abandoné buscando algo aún más ágil y productivo.
Google Reader, decidí darle una oportunidad. Por aquella época había empezado a usar Read it Later (hoy Pocket) para guardar aquello que quería leer en otro momento o con más calma. La integración con RIL me obligaba a abandonar el teclado y usar el ratón. Además el rediseño que hizo Google no me convencía. Decidí buscar algo aún más rápido y eficiente.

Durante todo ese tiempo probé muchísimas otras alternativas (incluidos complementos para navegadores web) y no encontraba nada que me valiese. Es muy difícil encontrar una aplicación de este tipo que te permita manejar un gran número de fuentes RSS de forma realmente eficiente. Al final ya estaba decidido a regresar a RSSOwl. Pero acostumbrado a Pentadactyl y Vim y las aplicaciones ncurses, decidí buscar algo en esa línea, y lo encontré.

Newsbeuter

Newsbeuter es un juego de palabras con la palabra alemana "Wildbeuter" que significa cazador-recolector, por lo que Newsbeuter vendría a ser algo así como Cazador/Recolector de Noticias. Newsbeuter es una aplicación para leer fuentes RSS y Atom que utiliza una interfaz tipo ncurses para consola. Quién esté familiarizado con el cliente de correo Mutt se sentirá cómodo enseguida, ya que se inspira en este. Está programado en C++ y dado que funciona en modo texto, una de sus ventajas es la enorme agilidad que proporciona para moverse entre fuentes y noticias.

Un resumen de sus características:

Permite suscribirnos a fuentes RSS y Atom
Soporta OPML tanto para importar como para exportar las subscripciones
Descarga de podcasts
Se pueden configurar todos los atajos de teclado libremente
Podemos realizar búsquedas entre todos los artículos descargados. Similar a Vim
Es posible crear etiquetas para dividir nuestras subscripciones en categorías y realizar filtrados y búsquedas en función a ellas
Se pueden sincronizar las fuentes con Google Reader y Tiny Tiny RSS
Podemos configurar el color y las cadenas de texto para personalizar su aspecto
Se pueden eliminar de forma automática artículos que no deseemos a través de un "killfile"
Es posible integrar cualquier fuente de datos a través de un flexible sistema de filtros y plugins: Fichero con urls, fichero OPML, fichero OPML online, Google Reader, varios ficheros...
Se pueden crear "meta fuentes" empleando un potente lenguaje de consultas
Permite crear marcadores a partir de cualquier enlace del articulo empleando una aplicación externa o un script
Permite guardar artículos en texto plano
Podemos otorgar etiquetas de un solo carácter que el autor denomina "flags" por articulo y varias por articulo. Útiles para emplearlas conjuntamente con los filtros
Se pueden definir macros
Linea de comandos para poder ejecutar comandos y cambiar opciones sobre la marcha
Funciona en Linux, Mac OS y FreeBSD
Programado en C++ y guarda los artículos en una BDD SQLite
Documentación bastante completa

Pantalla con la configuración por defecto de Newsbeuter

Lo que lo distingue

Muchas de estas características las comparte con otras aplicaciones de las mencionadas antes, pero lo que realmente distingue a Newsbeuter de todas ellas es lo siguiente:

Totalmente controlable desde el teclado, lo que unido a su velocidad, le proporciona una agilidad inigualable.
Basado en texto, lo que nos evita distraernos de lo importante, el contenido.
Consumo ridículo de memoria y recursos comparado con cualquiera aplicación mencionada antes. En el peor de los casos, me ha consumido unos 30 MiB de RAM (para la versión de 64 bits)
Se puede configurar el números de hilos de proceso para descargar noticias. En mi caso, con 8 hilos, tarda unos 40s en leer unos 250 canales RSS. Solo Google Reader por su funcionamiento, puede mejorar esto.
Configurable con un fichero de texto plano

Como dijo Zed Shaw y refrenda el autor de la aplicación, Andreas Krennmair,

"Newsbeuter es el Mutt de los lectores de noticias RSS"

Desde mi propia experiencia puedo decir que este programa ha cambiado mi forma de leer las noticias del día. Antes, para mi, era muy importante que el lector de noticias que empleara, utilizara un estilo homogéneo entre todas las fuentes y artículos, con el fin de centrarme en el contenido y no perder el tiempo con nimiedades. Es algo más importante de lo que pueda parecer a simple vista, cuando quieres emplear el menor tiempo posible en adquirir la información y al mismo tiempo quieres asimilar lo que lees. Si cuando vas a leer las noticias tienes 45 minutos y 300 artículos sin leer, el cambiar de un articulo con fondo negro y letra Sans Serif mediana a uno con fondo blanco y letra Serif enorme, te supone una distracción y una adaptación de la vista innecesarias e incomodas.

Vista de un articulo con mi configuración

Pero al comenzar a emplear Newsbeuter me di enseguida cuenta de algo, el carecer por completo de imágenes y compartir cabecera entre todos los artículos, me ha servido para pasar por alto o leer en diagonal aquello que menos me interesa. No solo filtro más rápido, si no que lo hago más eficientemente. Evidentemente hay artículos en los que las imágenes complementan necesariamente al articulo. En estos casos o bien la abro directamente en el navegador (tan sencillo como pulsar o ) o bien puedo abrir las imágenes de forma independiente en el mismo si me interesa por ejemplo ver solo una. En este sentido, Newsbeuter proporciona una lista de todas las Urls presentes en el articulo en forma de lista al final del mismo, pudiendo abrir cualquiera de ellas introduciendo el indice de la misma. De hecho, empleando el comando u podemos acceder a la lista completa de las mimas en una nueva ventana.

Mi configuración

Mi configuración no tiene demasiado de especial, quizás que emplea una combinación de colores distinta a la habitual y que empleo un par de scripts para las notificaciones y para crear marcadores. Esta se puede encontrar en mi repositorio de mis dotfiles en GitHub

Notificaciones

Para las notificaciones que emite Newsbeuter después de refrescar las noticias empleo el script notify.py que comentaba en este articulo ligeramente modificado para trabajar con Newsbeuter. En la imagen se puede ver una notificación del programa.

try:
    import os
    import sys
    import gtk
    import pynotify
    import textwrap
    NOT_NOTIFY = False
except ImportError:
    NOT_NOTIFY = True

def notify(title, msg, icon=None, wrap=None):
    """Send notification icon messages through libnotify.

    Parameters:

    (str) title -- The notification title
    (str) msg -- The message to display into notification
    (str / uri) icon -- Type of icon (ok|info|error|warm|ask|sync) or icon file

    """
    if NOT_NOTIFY:
        return
    if not pynotify.is_initted():
        pynotify.init(title)
    gtk_icon = {'ok': gtk.STOCK_YES,
                'info': gtk.STOCK_DIALOG_INFO,
                'error': gtk.STOCK_DIALOG_ERROR,
                'warm': gtk.STOCK_DIALOG_WARNING,
                'ask': gtk.STOCK_DIALOG_QUESTION,
                'sync': gtk.STOCK_JUMP_TO}
    if wrap:
        msg = os.linesep.join(textwrap.wrap(msg, wrap))
    try:
        note = pynotify.Notification(title, msg)
        helper = gtk.Button()
        gtk_icon = helper.render_icon(gtk_icon[icon], gtk.ICON_SIZE_BUTTON)
        note.set_icon_from_pixbuf(gtk_icon)
    except KeyError:
        note = pynotify.Notification(title, msg, icon)
    note.show()

def main():
    """Main section"""
    notify('Newsbeuter', sys.argv[1], '/home/joedicastro/.newsbeuter/icon.png')

if __name__ == "__main__":
    main()

Integración con Pocket

Utilizo Pocket como nexo de unión entre el navegador y el Newsbeuter para archivar todos aquello artículos que me interesa leer, pero que quiero dejar para otro momento más idóneo. Hubo un tiempo en que empleaba Delicious para esta tarea, pero me parece más adecuado Pocket.

Esto lo consigo empleando el comando para crear marcadores de Newsbeuter y un script en Python creado para ello. Esta es la parte del archivo de configuración que relaciona el comando con el script:

bookmark-cmd                            "~/.newsbeuter/send2ril.py"

El script hace uso de la API Python para Read it Later (como se llamaba anteriormente Pocket) para guardar la url del articulo en mi cuenta de Pocket. Así pulsando Ctrl + b se guarda el marcador en Pocket.

#!/usr/bin/env python
# -*- coding: utf8 -*-

"""
    send2ril.py: Send a new url to Read it Later
"""

__author__ = "joe di castro <joe@joedicastro.com>"
__license__ = "GNU General Public License version 3"
__date__ = "18/06/2012"
__version__ = "0.1"

import sys
import readitlater
import ril_config as config

def main():
    """Main section"""
    api = readitlater.API(config.RIL_APIKEY, config.RIL_USERNAME,
                          config.RIL_PASSWORD)

    new = [{"url":sys.argv[1], "title":sys.argv[2]}]
    api.send(new=new)

if __name__ == "__main__":
    main()

En el script se importa un modulo, ril_config, que es el que contiene las claves de mi cuenta de Pocket, este modulo sería algo similar a esto (evidentemente los valores son falsos):

# ril credentials
RIL_APIKEY = '987u1ksjsdfRk54kKLKL34jkjij9945k'
RIL_USERNAME = 'usuario'
RIL_PASSWORD = 'ADRKSD-Xk3kj5kjljFl'

Por lo tanto para hacerlo funcionar necesitamos crear un fichero ril_config.py con las credenciales de cada uno para Pocket. Los campos RIL_USERNAME y RIL_PASSWORD se corresponden evidentemente con el usuario y la contraseña que tengamos para el servicio. El otro campo, RIL_APIKEY es una clave que podemos obtener en esta página para registrar nuestra aplicación (en este caso nuestro script) y que pueda acceder de forma autorizada a la API de Pocket.

Copia de seguridad de las urls de Pocket

Del mismo modo, aprovechando la misma API que empleo en el anterior script, he creado otro script que ejecuto regularmente con cron, que me guarda una copia en mi disco duro con todas las urls que tengo guardadas en Pocket. Vamos, una copia de seguridad, uno nunca sabe cuando este tipo de servicios pueden dejar de funcionar. Estas direcciones las guardo en un fichero con formato Org-mode

#!/usr/bin/env python
# -*- coding: utf8 -*-

"""
    get.py: Get the urls stored in Read it Later & save them in a Org-mode file
"""

__author__ = "joe di castro <joe@joedicastro.com>"
__license__ = "GNU General Public License version 3"
__date__ = "18/06/2012"
__version__ = "0.1"

try:
    import sys
    import os
    import readitlater
    import ril_config as config
except ImportError:
    # Checks the installation of the necessary python modules
    print((os.linesep * 2).join(["An error found importing one module:",
    str(sys.exc_info()[1]), "You need to install it", "Stopping..."]))
    sys.exit(-2)
import os

def main():
    """Main section"""
    api = readitlater.API(config.RIL_APIKEY, config.RIL_USERNAME,
                          config.RIL_PASSWORD)

    items = api.get(state="unread")
    lista = items["list"]
    with open("ril_urls.org", "w") as output:
        output.write("* Read It Later URLs" + os.linesep)
        for i, k in lista.items():
            output.write("** {0}{1}".format(k['title'].encode("utf8"),
                        os.linesep))
            output.write("   [[{0}][Enlace]]{1}{1}".format(k['url'].
                        encode("utf8"), os.linesep))

if __name__ == "__main__":
    main()

Conclusión

Newsbeuter no es para todo el mundo, por supuesto, la gran mayoría considerarían decimonónico el emplear un interfaz de texto en vez de uno gráfico. Muchos incluso llamarían herejía a usar el teclado en vez de el ratón (aunque luego se vuelvan locos con las pantallas táctiles). Lo respeto y lo entiendo, pero para aquellos que aman su tiempo y no están dispuestos a desperdiciarlo, deberían darle una oportunidad a esta aplicación.

Mantener la temperatura adecuada en un portátil Dell con Linux

2012-06-12T10:44:00+02:00

Los que tengáis o hayáis tenido un portátil Dell, sabréis que es posible controlar la velocidad de funcionamiento de sus ventiladores de forma manual. Existen aplicaciones para Windows, pero también es posible hacerlo desde Linux con el paquete i8kutils creado por Massimo Dal Zotto. Este paquete incluye un modulo del kernel i8k que necesita ser cargado al inicio y una serie de utilidades para controlar el ventilador e informar de la temperatura y otros valores de la BIOS.

Este paquete fue creado originalmente para el portátil Dell Inspiron 8000, de ahí su nombre. Esta utilidad aprovecha el modo SMM de la BIOS que estaba presente en los modelos Inspiron para controlar la velocidad de los ventiladores (algo que también permiten otras marcas como Toshiba y Lenovo, para las que también hay algunas utilidades). Dell también ofrece el soporte de SMM BIOS en otras gamas y portátiles, como los de la serie Latitude o XPS. Aunque está utilidad no funciona en algunos modelos.

Esta utilidad funciona bajo la línea de comandos, pero al amparo del modulo del kernel surgieron varias aplicaciones, principalmente applets para el panel de Gnome 2, que permitían un control gráfico de los ventiladores y su temperatura. Este control podía ser automático o manual. Yo personalmente me decanté en su momento por emplear Conky para mostrar las velocidades y la temperatura y emplear un script, i8kapplet por Wheelspin, para controlar automáticamente la temperatura dentro de unos rangos.

i8kfans.py

Este era un script bash que lleva dándome servicio mucho años (el portátil ya tiene sus siete años) pero que por la forma que tiene de controlar cuando se debe subir/bajar la velocidad de los ventiladores, provocaba que se sucediesen de vez en cuando continuos acelerones y frenazos en los mismos. Esto al principio no me disgustaba, pero con los años los ventiladores hacen cada vez más ruido y si bien el sonido constante a alta velocidad es ligeramente molesto, esos cambios bruscos de velocidad se me han vuelto insoportables. Y dado que el portátil se acerca al final de su vida útil, sustituir los ventiladores, aunque es la solución adecuada, no lo veo económicamente rentable.

Yo sabía que el problema por el que esto sucedía es porque la BIOS por defecto regula las temperaturas de los ventiladores en unos rangos predefinidos y esto no se desactiva, de hecho trabaja conjuntamente con el script. Como los rangos de temperatura que yo predefino son inferiores a los de la BIOS, en algunas ocasiones los dos pelean por el control de los ventiladores y es lo que ocasiona el problema. Pero el calor es el peor enemigo de la electrónica, y en los portátiles esto es un factor critico. De hecho estoy seguro de que este equipo (muy bien amortizado) me ha durado tantos años gracias a que me he preocupado de este punto. Estoy cansado de ver morir a portátiles y discos duros en verano porque la gente no se preocupa de este tema. Por favor, limpiad el polvo de los ventiladores al llegar el verano, os ahorrareis muchos disgustos.

Así que descartado el reemplazar los ventiladores, me planteé el crear un script que intentara hacer lo mismo pero de forma más suave, intentado reducir el número de cambios bruscos de velocidad y fruto de ello es el siguiente script, que está disponible en GitHub:

#!/usr/bin/env python
# -*- coding: utf8 -*-

"""
    i8kfans.py: Adjust the fans speed in various Dell laptops (with a nvidia
    graphics card) to maintain the right temperatures. This affect both fans,
    the cpu and the gpu fan. Originally i8k was created to run in a Dell
    Inspiron 8000 laptop, but this Dell fan control via SMM BIOS is available
    in others laptops of various series (Inspiron, XPS, Latitude, etcetera),
    but not all of them are supported. Mine is an Inspiron 9400 but I tested
    this successfully in a XPS m1330 too.

    Based on a 2006 bash script by Wheelspin, `i8kapplet`. This old script
    served faithfully me for many years, but my ears couldn't stand much longer
    its random and common slow downs/speed ups. Over the years, fans have
    become more and more loud. This new script runs in a more smooth way, with
    less sudden changes.  It's cheaper than replace booth fans, don't you
    think?

    This script needs the `i8kutils` linux package installed and the `i8k`
    kernel module loaded to work.
"""

#==============================================================================
#    Copyright 2012 joe di castro <joe@joedicastro.com>
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
#==============================================================================

__author__ = "joe di castro <joe@joedicastro.com>"
__license__ = "GNU General Public License version 3"
__date__ = "12/06/2012"
__version__ = "0.3"

try:
    from os import linesep
    from subprocess import check_output, Popen, PIPE
    from sys import exit, exc_info
    from time import sleep
except ImportError:
    # Checks the installation of the necessary python modules
    print((linesep * 2).join(["An error found importing one module:",
    str(exc_info()[1]), "You need to install it", "Stopping..."]))
    exit(-2)

def check_execs(*progs):
    """Check if the programs are installed, if not exit and report."""
    for prog in progs:
        try:
            Popen([prog, '--help'], stdout=PIPE, stderr=PIPE)
        except OSError:
            msg = 'The {0} program is necessary to run this script'.format(prog)
            exit(msg)
    return

def get_right_fan_speed(current_temperature, current_fan_speed, temp_triggers):
    """Get the right fan speed to use with i8kfan command.

    :current_temperature: current temperature value for the fan implied
    :current_fan_speed: current fan speed
    :temp_triggers: the threshold temperatures to trigger the fan speed change
    :returns: right fan speed or "-" (means change nothing to i8kfan)

    """
    right_fan_speed = None  # the right fan speed for the current temp
    if current_temperature >= temp_triggers[0]:
        if current_temperature >= temp_triggers[1]:
            right_fan_speed = 2
        else:
            right_fan_speed = 1
    else:
        right_fan_speed = 0
    return right_fan_speed if right_fan_speed != current_fan_speed else "-"

def main():
    """Main section"""
    # time between temperature checks
    interval = 1
    # the temp thresholds to jump to a faster fan speed. Values greater than
    # [g|c]pu[0] set the fan speed to 1 and the ones greater than [g|c]pu[1]
    # set the speed to 2. Obviously, values minor than [g|c]pu[0] stop the fan
    gpu_temps = [45, 53]
    cpu_temps = [40, 50]

    # check if the i8k kernel module is already loaded
    if  "i8k" not in check_output("ls /proc/".split()):
        exit("The i8k kernel module is not loaded")

    while True:
        try:
            # get current values
            cpu_temp = int(check_output("i8kctl temp".split()))
            gpu_out = check_output("nvidia-smi -q -d TEMPERATURE".split())
            gpu_temp = int([s for s in gpu_out.split() if s.isdigit()][-1])
            cpu_fan, gpu_fan = [int(f) for f in check_output("i8kfan").split()]

            # get the right speed values for each fan
            cpu_rfs = get_right_fan_speed(cpu_temp, cpu_fan, cpu_temps)
            gpu_rfs = get_right_fan_speed(gpu_temp, gpu_fan, gpu_temps)

            # if any of the fans needs to change their speed, change it!
            if cpu_rfs != "-" or gpu_rfs != "-":
                Popen("i8kfan {0} {1}".format(cpu_rfs, gpu_rfs).split(),
                      stdout=PIPE)

            # wait a moment. We want a cooler laptop, aren't we?
            sleep(interval)
        except KeyboardInterrupt:
            exit()

if __name__ == "__main__":
    check_execs("i8kctl", "i8kfan", "nvidia-smi")
    main()

###############################################################################
#                                  Changelog                                  #
###############################################################################
#
# 0.3:
#
# * Better documentation
#
# 0.2:
#
# * Fix an error in a function docstring due to refactorization
# * Give appropriate credit to original idea' script
#
# 0.1:
#
# * First attempt
#

De momento, aunque aún sufre del mismo problema inevitable por el conflicto por el control entre el script y la BIOS, de momento he observado que se produce con menos frecuencia y durante menos tiempo. Aunque quizás realice algunos cambios para intentar reducir aún más esos conflictos.

Productividad en el escritorio Linux: Awesome

2012-06-07T00:00:00+02:00

Como había comentando en el anterior articulo sobre Xmonad, tenía la intención de probar un Gestor de ventanas de mosaico más, antes de tomar la decisión final de cual emplear a diario. Y si, y solo si, resultaba ser una mejor alternativa, abandonaría Xmonad. Este tiling window manager era Awesome y ha conseguido con creces que abandone a Xmonad.

Awesome carece de algunas funcionalidades que me ofrecía Xmonad, pero después de trabajar con él durante seis meses y conseguir tener una configuración a mi medida, solamente hecho en falta una característica que comentare después. Además Awesome me ofrece algunas características que no me ofrecía Xmonad y que valoro lo suficiente como para realizar el cambio sin mirar atrás.

Awesome vs Xmonad

En esta tabla podemos ver una comparativa rápida de algunas de las características de ambos gestores de ventanas.

Característica	Awesome	Xmonad
Lenguaje	C	Haskell
Extensible	Lua	Haskell
Gestión ventanas	Automático	Automático
Soporte ratón	Muy bueno	Básico
Bandeja sistema (systray)	Integrada	No
Paneles	Integrado	No
Reinicio en caliente	Si	Si
Librería	XCB	Xlib
Soporte varios monitores	Muy bueno	Bueno
Transparencias	Gestor externo	Gestor externo
Integración escritorios	Buena	Muy buena (Gnome, KDE)
Desarrollo	Muy activo	Muy activo
Estabilidad	Estable	Estable
Documentación	Buena	Buena

Ventajas

Una de las principales ventajas de Awesome sobre Xmonad es la velocidad de respuesta que ofrece el entorno, que en Awesome es bastante superior a la de Xmonad. Alguna que otra vez, al intentar realizar muchas operaciones consecutivas entre ventanas y escritorios en Xmonad, se me ha quedado colgado y he tenido que reiniciarlo (que se hace en caliente y en segundos, pero no deja de ser algo molesto). En este sentido Awesome solo se me ha colgado un par de veces.

Otra de las grandes ventajas es que al configurarse en Lua es bastante más sencillo hacerse con él, ya que es un lenguaje relativamente asequible y carece de la complejidad inicial de Haskell para aquellos que no conocen la programación funcional. Esto aumenta las posibilidades de personalizarlo para un usuario con conocimientos muy básicos de programación.

La configuración por defecto de Awesome también es más completa y amigable que la de Xmonad, partiendo de un esquema tradicional de ventanas flotantes y con menús que nos permiten dar los primeros pasos y poder abandonar la sesión sin llegar a conocer las combinaciones de teclado por defecto. Algo que agradecerán aquellos que se hayan tenido que enfrentar a una configuración por defecto de Xmonad por primera vez. Esto invita a conocer el sistema y no abandonarlo "asustado" por su complejidad. En la imagen se puede ver el aspecto que presenta una sesión de Awesome con la configuración por defecto.

Para acceder al menú podemos bien hacer click sobre el icono de Awesome en la parte superior izquierda o bien con el botón derecho en cualquier parte de la pantalla. También se puede acceder a él con la combinación de teclas Win + w

Finalmente, el que Awesome tenga integrados aspectos como los paneles, una bandeja del sistema (systray), lanzador de aplicaciones y un soporte muy bueno del ratón facilita el poder emplearlo en solitario, sin un sistema de escritorio tradicional detrás. Y a través de librerías es fácil implementar un sistema de notificaciones, un localizador de ventanas, temas, menús emergentes, ...

Desventajas

Quizás para mí la mayor desventaja frente a Xmonad y lo único que hecho realmente en falta, es la imposibilidad, a diferencia de Xmonad, de poder regular el tamaño vertical de las ventanas. Es particularmente útil en algunas situaciones y en Xmonad está integrado de manera natural. Pero después de varios meses he aprendido a vivir sin ello.

La otra gran desventaja es que el desarrollo aún no ha alcanzado el estadio de madurez de Xmonad, esta sujeto a demasiados cambios y no cuidan demasiado la retrocompatibilidad. Las nuevas versiones frecuentemente obligan a realizar cambios en la configuración para que todo vuelva a funcionar con normalidad.

Por otro lado, la instalación en algunas distribuciones puede no ser tan sencilla como la de Xmonad por la falta de soporte a la librería XCB o por necesitar versiones especificas de cairo.

Diferentes filosofías

Siendo como son ambos, gestores de ventanas de mosaico, difieren particularmente en la manera de entender principalmente dos conceptos:

Múltiples escritorios

Aquí Xmonad sigue el concepto tradicional de múltiples escritorios en Linux, soportando por defecto 9 por monitor y asignándoles un número del 1 al 0. Luego una aplicación puede estar, por ejemplo, en el escritorio 4 del monitor 2 y podemos movernos entre escritorios y monitores y mover a su vez las aplicaciones entre ellos.

En cambio, Awesome, aunque aparentemente sigue el mismo sistema, y para cualquiera que no quiera profundizar en ello no habrá diferencia alguna, se basa en un concepto diferente. En Awesome cada escritorio es en realidad una etiqueta y puede ser tanto un número como un texto. En principio también son 9 por monitor, aunque esto puede ampliarse o reducirse en la configuración. La diferencia principal es que una aplicación puede ser asignada a varias etiquetas simultáneamente y puede por lo tanto ser mostrada en varios escritorios a la vez. Esto permite asignar de forma muy sencilla etiquetas destinadas a una tarea y predefinir ciertas aplicaciones para que sean mostradas en una o más etiquetas. Por ejemplo podemos tener una etiqueta para redes sociales y mostrar allí un navegador, pero al mismo tiempo podemos tener una etiqueta desarrollo en la que también queremos que se muestre el navegador. Por otro lado, también es posible mostrar varias etiquetas al mismo tiempo, lo que nos permite trabajar en dos tareas distintas y bien definidas, cada una en su etiqueta, y en un momento dado, visualizarlas juntas sin perder la asignación de etiquetas original. En este sentido Awesome es mucho más flexible y potente que Xmonad.

Múltiples monitores

En este caso Xmonad comparte el mismo escritorio en distintos monitores. Por lo tanto si estamos en el escritorio 1 en el monitor 1 y nos movemos al escritorio 2, lo hará en todos los monitores a la vez, lo que también es el comportamiento clásico. Con lo que podemos decir que aunque tenemos 9 escritorios por monitor, se comporta como si tuviéramos 9 para todos los monitores.

Awesome, al contrario, emplea 9 etiquetas por monitor independientes entre si. Lo que significa que en este casi si tenemos 9 escritorios reales por cada monitor. Si nos encontramos en el monitor 1 y la etiqueta 1, al cambiar a la etiqueta 2, el resto de monitores permanecerán inalterados en la etiqueta en la que estuvieran previamente. En este sentido Awesome también sigue siendo bastante más flexible y potente que Xmonad. Este comportamiento puede ser alterado mediante la configuración. Hay quienes prefieren un método de trabajo y quienes prefieren el otro, yo soy de los que prefieren el comportamiento de Awesome.

Awesome con Gnome

Actualmente estoy empleando Awesome en solitario, si un escritorio detrás, lo que me obliga a configurar por mi cuenta todos los servicios que estos proporcionan, pero me compensa con la ligereza que me reporta el no emplear un pesado escritorio por debajo. Sin embargo, los primeros meses lo empleé conjuntamente con Gnome en Ubuntu, utilizando solo los componentes básicos del mismo. La forma de configurar una sesión de Awesome con Gnome en Ubuntu (11.10 y 12.04) y en Arch Linux, la distribución que estoy empleando ahora, es a través de los siguientes ficheros:

/usr/share/applications/awesome.desktop

[Desktop Entry]
Version=1.0
Type=Application
Name=Awesome
Comment=The awesome launcher!
TryExec=awesome
Exec=awesome

/usr/share/gnome-session/sessions/awesome.session

[GNOME Session]
Name=Awesome session
RequiredComponents=gnome-settings-daemon;
RequiredProviders=windowmanager;
DefaultProvider-windowmanager=awesome
DesktopName=GNOME

/usr/share/xsessions/awesome-gnome-session.desktop

[Desktop Entry]
Name=Awesome GNOME
Comment=Dynamic window manager
TryExec=/usr/bin/gnome-session
Exec=gnome-session --session=awesome
Type=XSession

Evidentemente para esto es necesario instalar los paquetes necesarios para ejecutar Awesome que en el caso de Ubuntu son awesome y awesome-extra:

$ sudo apt-get install awesome awesome-extra

En Arch, bastaría con instalar el paquete awesome:

$ sudo pacman -S awesome

Mi configuración

A diferencia de Xmonad, mi configuración de Awesome no está contenida en un solo fichero, ya que el tema y los diversos plugins están alojados dentro de sus propios directorios. Además el fichero de configuración rc.lua es demasiado extenso (cerca de 1200 lineas) para volcarlo aquí. Así que me limitare a mencionar los aspectos más destacados, la configuración completa queda disponible a través de mi repositorio en GitHub.

Destacar que al principio del fichero incluyo una Cheat Sheet ("chuleta") con todas las combinaciones de teclado y ratón que tengo habilitadas en mi configuración.

Panel y Widgets

Awesome permite la creación de varios paneles, generalmente se suelen crear en la parte superior y/o inferior de la pantalla. A mi me gusta disponer del máximo espacio posible para las aplicaciones, así que solo he creado uno superior que además puedo ocultar a conveniencia. De hecho, para determinadas tareas, lo mantengo oculto la mayor parte del tiempo y solo lo muestro cuando me interesa consultar la información que allí se muestra.

Aquí se puede ver la apariencia del panel superior y una ampliación del mismo:

En el que se pueden apreciar (de izquierda a derecha y de arriba a abajo) los siguientes widgets:

Icono de Awesome. Proporciona acceso al menú de Awesome
Etiquetas. Aquí se puede ver que hay dos activas y que nos encontramos en la segunda, β
Icono de esquema. Vemos que está seleccionado el esquema tile
Icono y titulo de la ventana activa. En este caso tenemos una ventana de Gvim y además el icono del final nos indica que es una ventana flotante
Pomodoro. Es un widget que me permite seguir el método Pomodoro y que indica que quedan 4 minutos y 14 segundos para tomarme un pequeño descanso.
MPD. Indica el estado del servidor de música mpd, y en este caso nos indica el autor y el titulo de la canción que se está reproduciendo
Velocidad de los ventiladores del sistema
Temperaturas de CPU y GPU
Uso de las CPUs del microprocesador
Porcentaje y cantidad de memoria RAM en uso
Velocidad (en Kbs) de bajada y subida de la red.
Porcentaje de ocupación en disco de / y /home
Estado de la batería y tiempo estimado de carga/descarga
Uptime. Indica el tiempo que lleva el equipo encendido desde el último reinicio
Versión del Kernel Linux en ejecución
Volumen del sonido del sistema
Fecha y hora

Muchos prefieren añadir iconos o encabezados a todos los widgets para facilitar su identificación, pero yo ya conozco para que es cada uno y prefiero un entorno minimalista que me distraiga lo menos posible. Muchos de estos widgets ejecutan una acción al ser pulsados con un botón del ratón o al pasar por encima de ellos. Por ejemplo al pasar el ratón por encima de la fecha y hora se muestra un calendario y al pulsar con el botón izquierdo sobre el uso de las CPUs, se lanza una ventana con el programa htop

Localizar aplicaciones

Una de las funcionalidades geniales que tenía implementada en Xmonad me permitía conocer todas las ventanas que estaban abiertas y elegir la deseada con una rápida combinación de teclas. Awesome no tiene esto implementado, pero gracias a una librería externa, Revelation, podemos emplear un método similar al famoso Exposé del Mac OS y también presente en Compiz. Lo que hace es mostrarnos en la etiqueta que estemos actualmente todas las ventanas abiertas en forma de mosaico y podemos elegir una de ellas para saltar automáticamente a ella (y la etiqueta en la que se encuentre). Aquí podemos ver un screencast de su funcionamiento:

Es también un método muy rápido y muy visual, al final he acabado prefiriendo este método al que empleaba en Xmonad, ya que en este último, el titulo de las ventanas podía ser muy ambiguo y no ser fácil dar con la ventana adecuada.

Gestión dinámica de etiquetas

Aunque por defecto Awesome define 10 etiquetas por monitor, podemos definir a nuestro antojo el número de ellas que queramos en el fichero de configuración. Podemos optar por un número clásico en los escritorios Linux, cuatro, o podemos crear una para cada tarea concreta más una libre. Por defecto tengo definidas diez, empleando para identificarlas los números en griego:

-- definición de las etiquetas en el fichero de configuración rc.lua
tags[s] = awful.tag({ "α", "β", "γ", "δ", "ε", "ς", "ζ", "η", "θ"}, s, layouts[1])

Sin embargo, en mi configuración empleo una librería externa, Eminent, que gestiona estas etiquetas de forma dinámica, creándolas y destruyéndolas según sea necesario. Así de entrada solo tenemos una etiqueta, α y solo se creara una segunda etiqueta, β si nos desplazamos a ella. Del mismo modo, cuando eliminamos la última ventana de una etiqueta y la abandonamos, se destruye. La ventaja de esto es que por un lado nos facilita localizar donde estamos más fácilmente y por otro, que en caso de ser necesario, si necesitamos más etiquetas (de las creadas por defecto), las creara de forma automática. De este modo cuando llegamos a la etiqueta θ, si necesitamos otra, creara la 10 y así en lo sucesivo.

Lanzar aplicaciones

Existen dos métodos para realizar esta tarea:

Empleando un prompt que emerge en el panel superior y nos permite escribir el comando que queremos ejecutar y que posee autocompletado. La combinación de teclas por defecto que activa esto es Win + r

Empleando menubar. Menubar es una librería externa, que será incluida en la próxima versión de Awesome por defecto, que al igual que muchos otros lanzadores de aplicaciones (Gnome Do, Kupfer, Synapse, etc) nos va mostrando las aplicaciones disponibles en función de lo que vayamos tecleando. Se lanza con la combinación de teclas Win + p y en mi caso, esta aparece inmediatamente debajo del panel superior. Aquí se puede ver la menubar en funcionamiento (la tecla Win también es llamada Super ):

Yo además empleo un tercer método que heredo de Xmonad, y es emplear dmenu para lanzar aplicaciones. dmenu es muy parecido al prompt de Awesome, pero busca para el autocompletado en todo el nombre del comando y no solo al principio. Además muestra todas las coincidencias disponibles y que se pueden seleccionar con las teclas de dirección.

Grabar vídeos y screencasts del escritorio

Adicionalmente, tengo definidas ciertas combinaciones de teclas para lanzar determinadas aplicaciones o procesos con las teclas de función. Dentro de estos atajos de teclado cabe destacar cinco que en lugar lanzar una aplicación, comienzan o terminan un determinado proceso. Estas combinaciones, que van de F8 a F12, las utilizo para grabar vídeos y screencasts con gifs animados y son las que he empleado para ilustrar este articulo.

-- Win  +  F8                       Start gif screencast recording LowRes
-- Win  +  F9                       Start gif screencast recording HighRes
-- Win  +  F10                      Stop gif screencast recording
-- Win  +  F11                      Start mkv screencast recording
-- Win  +  F12                      Stop mkv screencast recording

awful.key({ modkey }, "F8",
    function ()
        awful.util.spawn_with_shell("rm " .. home_dir .. "/screencast.gif")
        awful.util.spawn("ffmpeg -f x11grab -s " .. scr_res ..
                        " -r 2 -i :0.0 -b:v 500k -pix_fmt rgb24 -y" ..
                        " -loop 0 -s 640x400 " .. home_dir ..
                        "/animated.gif")
    end),

awful.key({ modkey }, "F9",
    function ()
        awful.util.spawn_with_shell("rm " .. home_dir .. "/screencast.gif")
        awful.util.spawn("ffmpeg -f x11grab -s " .. scr_res ..
                        " -r 2 -i :0.0 -b:v 500k -pix_fmt rgb24 -y" ..
                        " -loop 0 -s 1440x900 " .. home_dir ..
                        "/animated.gif")
    end),

awful.key({ modkey }, "F10",
    function ()
        awful.util.spawn("killall ffmpeg")
        awful.util.spawn("convert ephemeral:" .. home_dir ..
                         "/animated.gif -fuzz 7% -layers Optimize " ..
                         home_dir .. "/screencast.gif")
    end),

awful.key({ modkey }, "F11",
    function ()
        awful.util.spawn_with_shell("rm " .. home_dir .. "/screencast.mkv")
        awful.util.spawn("ffmpeg -f x11grab -s " .. scr_res ..
                        " -r 25 -i :0.0 -sameq " .. home_dir ..
                        "/screencast.mkv")
    end),

awful.key({ modkey }, "F12",
    function ()
        awful.util.spawn("killall ffmpeg")
    end)

Gestión tiempo con pomodoro

La técnica Pomodoro puede ser muy provechosa en ciertas tareas si se emplea con sentido común y se sigue más o menos a rajatabla. Yo la empleo muy a menudo cuando tengo una tarea concreta en la que quiero centrarme sin distracciones para sacarla adelante y no caer en el error de procrastinar demasiado. Es una combinación ideal entre concentración puntual y alternar distracciones, que impiden a uno "quemarse" por no saber echar el freno a tiempo. Es una técnica muy útil a la hora de programar o de crear un articulo como este, pero que es difícilmente aplicable en tareas que requieren cierta multitarea como son las de administración de sistemas.

Existen múltiples aplicaciones, applets, indicadores, etc para aplicar esta técnica, que se basaba originalmente en un simple reloj de cocina. Pero alguien, en su momento pensó, que no era mala idea crear un widget para Awesome que nos permitiera medir los tiempos para aplicarla y creo una librería externa para ello. Yo empleo esta librería ligeramente modificada para controlar el tiempo transcurrido.

El funcionamiento es muy básico, pulsamos sobre el icono y se activa la cuenta atrás de 25 minutos. Al acabar, una alarma sonora y una notificación emergente, nos avisan de que se ha terminado el tiempo de trabajo y nos merecemos un descanso. Volvemos a pulsar sobre el widget y comienza la cuenta atrás de cinco minutos y se repite el proceso. Si pulsamos con el botón derecho se reinicia el widget.

Debug con Xephyr

Esta es una de las posibilidades que nos permite Awesome, que más nos ayudará a la hora de "trastear" con él, sin temor a "romper" nada. Podemos depurar los errores y realizar pruebas con Awesome con una configuración distinta a la nuestra y en una sesión X distinta a la actual. Esto lo conseguimos ejecutando Awesome dentro de un servidor X, Xephyr, que aparecerá dentro de nuestra sesión como una ventana más.

Yo he integrado esta posibilidad dentro del menú de Awesome para que sea mucho más sencillo e inmediato el poder probar cambios en un entorno de pruebas.

En este vídeo se puede ver el funcionamiento básico de este sistema. Normalmente inicio el entorno de pruebas a pantalla completa, pero que se pueda apreciar mejor la diferencia, he grabado la mayoría del vídeo con una sesión de Xephyr a menor resolución. Lo que se puede ver es como primero inicio una sesión de Awesome dentro de Xephyr con la configuración por defecto. Después la cierro y compruebo la sintaxis Lua de la configuración de test. La notificación me alerta de que el fichero no existe, luego procedo a crearlo (es una copia de la configuración real actual) y vuelvo a comprobar la sintaxis. Una vez que veo que esta es correcta, lanzo Awesome con la configuración de test. Cierro la sesión y procedo a realizar cambios en la configuración de pruebas. Ahora lanzo de nuevo Awesome con esta configuración y compruebo que efectivamente se han realizado los cambios. Dentro de esta sesión vuelvo a editar la configuración de test para deshacer los cambios y después reinicio este Awesome de pruebas. Se puede ver como efectivamente todo vuelve a el estado anterior. Cierro la sesión y compruebo el log de la sesión para ver los mensajes de error. Finalmente abro varias sesiones de Awesome a la vez y una a pantalla completa.

Muestra de las posibilidades que ofrecen Xephyr y el script awdt.py para poder depurar la configuración de Awesome. Recomiendo ver en alta resolución y a pantalla completa.

Para realizar estas acciones programé un script en Python, awdt.py, que incluyo al final del articulo.

Una de las ventajas de Awesome con respecto a Xmonad, es que no necesitamos recompilar cada vez que realizamos un cambio en la configuración, basta con editar el fichero, salvar y reiniciarlo. Reiniciar Awesome es algo que lleva menos de un segundo.

Reinicio, apagado y suspensión

Dado que no empleo ningún escritorio, arrancando directamente la sesión en Awesome, debo gestionar directamente cierto tipo de situaciones que vienen resueltas de manera predefinida en estos. Uno de estos casos es la gestión de energía del equipo, esto es: apagarlo, reiniciarlo, suspenderlo e hibernarlo. Dado que nunca lo hiberno, he implementado únicamente las tres primeras acciones. Lo que hago es emplear directamente los comandos de consola, que ejecuto a través de un dialogo gráfico que me pide la contraseña para sudo con gksudo (podría haber empleado Zenity, Xdialog o cualquier otro similar) que es activado a través de una combinación de teclas. Por ejemplo, para suspender el equipo lo activo a través de la combinación Win + s :

awful.key({ modkey }, "s",
        function ()
            awful.util.spawn("gksudo pm-suspend -m " ..
                             "'Se va a suspender el equipo, ¿estás seguro?'")
        end),

con el siguiente resultado:

Sé que la mayoría no está acostumbrado a tener que introducir la contraseña para realizar cualquiera de estas acciones y posiblemente detestarían hacerlo, pero yo lo prefiero así.

Bloqueo de la pantalla

Empleo un método similar para bloquear la pantalla, ya que no empleo un salvapantallas (simplemente apago la pantalla pasado un cierto tiempo) empleo el programa slimlock para realizar esta tarea y lo activo de forma manual con otra combinación de teclas. El resultado es una pantalla como esta:

Documentación y enlaces de interés.

La documentación del código fuente y de la API de Awesome son bastante buenas, con lo que si tienes los conocimientos suficientes no te será muy dificil hacerte con él. Si necesitas algo más general, tanto el propio Wiki de Awesome como los recursos disponibles gracias a su comunidad (lista de correo e IRC) son bastante útiles para ayudarte a conseguir la configuración que más se ajuste a tus necesidades. Es una comunidad muy dinámica y bastante colaboradora. También en el Wiki de Arch Linux hay información interesante sobre Awesome.

awdt.py

Este es el contenido del script awdt.py que empleo para depurar la configuración de Awesome en un entorno de pruebas. Se encuentra dentro del mismo repositorio que el resto de la configuración.

#!/usr/bin/env python
# encoding: utf-8

"""
    awdt.py: a script to debug awesome wm configs in nested Xephyr sessions

    This script is a tool intended to help to debug Awesome wm configurations
    in a safe manner. To this purpose uses the Xephyr X server to nest a X
    session inside the current Awesome X session.

    The original idea come from the mikar's bash awmtt script (Thanks mikar):

    https://github.com/mikar/awmtt

    Needs logger.py and check_execs.py from my Python Recipes repository at

    https://github.com/joedicastro/python-recipes
"""

#==============================================================================
#    Copyright 2012 joe di castro <joe@joedicastro.com>
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
#==============================================================================

__author__ = "joe di castro <joe@joedicastro.com>"
__license__ = "GNU General Public License version 3"
__date__ = "05/06/2012"
__version__ = "0.5"

try:
    import os
    import sys
    from argparse import ArgumentParser, RawDescriptionHelpFormatter
    from re import findall
    from shutil import copy
    from subprocess import Popen, PIPE, STDOUT
    from tempfile import gettempdir
    from time import sleep
    from logger import Logger
    from check_execs import check_execs
except ImportError:
    # Checks the installation of the necessary python modules
    print((os.linesep * 2).join(["An error found importing one module:",
    str(sys.exc_info()[1]), "You need to install it", "Stopping..."]))
    sys.exit(-2)

def arguments():
    """Defines the command line arguments for the script."""
    main_desc = """Debug awesome wm configurations in Xephyr sessions.

    Use `new` to create a new test config file cloned from your rc.lua
    Use `check` to test the Lua syntax on this file
    Use `start` to start a new awesome debug session
    Use `restart` to restart all awesome debug sessions
    Use `stop` to stop all awesome debug sessions
                   """

    parser = ArgumentParser(description=main_desc,
                            formatter_class=RawDescriptionHelpFormatter)
    parser.add_argument("action", choices=["new", "check", "start", "restart",
                        "stop"], help="the action to perform")
    parser.add_argument("-t", dest="test", action="store_true", default=False,
                        help="use created test configuration file")
    parser.add_argument("-s", dest="screen", help="the screen resolution")
    parser.add_argument("-d", dest="display", help="the DISPLAY to use")
    parser.add_argument("-v", "--version", action="version",
                        version="%(prog)s {0}".format(__version__),
                        help="show program's version number and exit")
    return parser

def main():
    """The script core."""
    # the files needed
    cfg_dir = os.path.expanduser("~/.config/awesome")
    rc_real = os.path.join(cfg_dir, "rc.lua")
    rc_test = os.path.join(cfg_dir, "rc_test.lua")
    rc_original = os.path.join(cfg_dir, "rc_original.lua")
    xpids_tmp = os.path.join(gettempdir(), "xpids")
    apids_tmp = os.path.join(gettempdir(), "apids")
    log_file = os.path.join(cfg_dir, "awdt.log")

    args = arguments().parse_args()

    # get the current screen resolution
    xdpyinfo = Popen("xdpyinfo", stdout=PIPE).stdout.read()
    currres = findall("dimensions:\s*(\d+x\d+)\spixels", xdpyinfo)[0]

    # set defaults
    args.screen = args.screen if args.screen else currres
    args.test = rc_test if args.test else rc_original
    args.display = args.display if args.display else 1

    if args.action == "new":
        copy(rc_real, rc_test)

    if args.action == "check":
        check = Popen("awesome -c {0} -k".format(rc_test).split(), stdout=PIPE,
                      stderr=STDOUT)
        check_out = check.stdout.readlines()
        Popen(["notify-send", "Lua sintax chek:", os.linesep.join(check_out)])

    if args.action == "start":
        # clean log in each debug session
        if not os.path.exists(apids_tmp):
            if os.path.exists(log_file):
                os.remove(log_file)

        log = Logger()
        log.filename = log_file
        log.header("https://github.com/joedicastro/dotfiles",
                   "This is a log from an Awesome wm's debug session")
        log.time("Start time")

        x_cmd = "Xephyr -ac -br -noreset -screen {0} :{1}".format(args.screen,
                                                                  args.display)
        aw_cmd = "awesome -c {0}".format(args.test)

        xserver = Popen(x_cmd.split(), stdout=PIPE, stderr=STDOUT)
        sleep(1)
        os.putenv("DISPLAY", ":{0}.0".format(args.display))
        awesome = Popen(aw_cmd.split(), stdout=PIPE, stderr=STDOUT)

        # save the process PIDs for kill them properly later. This way, no
        # matter how many awesome sessions do you start, all of them will be
        # reported to the log file. Also, awesome PIDs are used to restart each
        # one when is required
        with open(xpids_tmp, 'a+') as xpids:
            xpids.write(str(xserver.pid) + os.linesep)
        with open(apids_tmp, 'a+') as apids:
            apids.write(str(awesome.pid) + os.linesep)

        log.list("Parameters", ["Screen resolution: {0}".format(args.screen),
                                "Display: {0}".format(args.display),
                                "Configuration file: {0}".format(args.test)])
        log.list("Xephyr output", xserver.stdout.readlines())
        log.list("Awesome output", awesome.stdout.readlines())
        log.time("End time")
        log.free(os.linesep * 4)
        log.write(True)

    if args.action == "restart":
        with open(apids_tmp, 'r') as apids:
            for pid in apids.readlines():
                os.kill(int(pid), 1)

    if args.action == "stop":
        with open(xpids_tmp, 'r') as xpids:
            for pid in xpids.readlines():
                os.kill(int(pid), 9)
        os.remove(xpids_tmp)
        os.remove(apids_tmp)

if __name__ == '__main__':
    check_execs("Xephyr", "awesome")
    main()

#==============================================================================
# Changelog:
#==============================================================================
#
# 0.5:
#
# * New log file per debug session
# * Improve argparse help
# * Better comments
#
# 0.4:
#
# * remove debug prints
# * clean code
#
# 0.3:
#
# * implement logging functions
# * check for executables
#
# 0.2:
#
# * argparse instead of sys.argv
# * create a new rc_test.lua file from original
# * restart the awesome session
#
# 0.1:
#
# * First attempt
#
#==============================================================================

Sincronizar Bitbucket y GitHub

2012-04-26T21:15:00+02:00

Para mis proyectos empleo generalmente mercurial (hg) como sistema de control de versiones, porque está hecho en Python y me parece más elegante y agradable de usar que git, aunque empleo git para algunas tareas, como gestionar los plugins de Vim. Del mismo modo, el emplear hg como DCVS me llevaba de forma natural a emplear Bitbucket como alojamiento para mis repositorios públicos.

Siempre me ha gustado Bitbucket, su estilo sencillo, pero muy potente y creo que tiene algunas características que son superiores a las de sus rivales (el diff side-by-side, por ejemplo¹). Pero también tengo claro que si hay algún alojamiento de código en la red que destaca sobre todos los demás es GitHub, "todo" el mundo está allí y de algún modo, estás "obligado" a estar. GitHub tiene algunas características muy potentes y en ciertos aspectos es muy superior a Bitbucket, aunque me sigue gustando más el feeling de este último.

Hg != Git

Me planteé entonces hace unos días que lo mejor era mantener una replica de mis repositorios alojados en Bitbucket en GitHub, como dice el refrán, Nunca tengas todos tus huevos en una misma cesta. El problema es que aunque Bitbucket soporta repositorios tanto en mercurial como en git (para competir con GitHub), GitHub solo soporta repositorios en Git. Y dado el éxito que tienen, dudo mucho que tengan intención alguna de soportar otro sistema de versiones distinto a Git.

Técnicamente es posible mantener un repositorio con los dos dcvs a la vez, pero maldita la gracia que me hacía, ademas de que no es nada aconsejable por el incremento de tamaño en disco que esto supondría. Entonces, ¿como hacer para poder alojar un repositorio mantenido con mercurial en un alojamiento que solo soporta Git? La solución, hg-git.

hg-git

hg-git es un plugin para mercurial que permite sincronizar el repositorio local en hg con un repositorio en git, admitiendo tanto push como pull y sin perdidas de información. Gracias a este plugin, podemos alojar el repositorio en los dos sitios a la vez, empleando solo mercurial para gestionarlo.

Instalarlo es muy fácil (desde easy_install o pip) y emplearlo también. Primero necesitas habilitarlo en el fichero ~/.hgrc, así como la extensión bookmarks que necesita para trabajar.

[extensions]
hgext.bookmarks =
hggit =

A continuación tienes que ir a tu repositorio y asignarle un bookmark a la rama que tengas por defecto (suele ser default) o a tip con el nombre de master (el nombre de las ramas por defecto en git), es decir:

$ hg bookmark -r default master -f

Y luego emplearlo es tan sencillo como si fuera un repositorio de mercurial, por ejemplo un push:

$ hg push git+ssh://git@github.com/joedicastro/joedicastro.com.git

Sincronizar el repositorio con Bitbucket y GitHub

Ahora, lo que tampoco me apetecía era tener que andar haciendo un push cada vez para cada alojamiento, lo ideal es que cada vez que hiciera un push a un sitio se sincronizara también el otro de forma automática. La solución pasa por emplear los paths para definir alias para los repositorios remotos y un hook para automatizar la sincronización.

Definir los alias con paths es realmente sencillo, nos vamos al fichero .hg/hgrc del repositorio local y añadimos esto (e.g. el repo de este blog):

[paths]
github = git+ssh://git@github.com:joedicastro/joedicastro.com.git
bitbucket = ssh://hg@bitbucket.org/joedicastro/joedicastro.com

De este modo, realizar un push es tan sencillo como:

$ hg push bitbucket

Ahora necesitamos crear el hook que nos sincronice los dos alojamientos. Hay en la red varias soluciones para esto, por ejemplo esta y esta, pero ninguna de las dos acababa de convencerme, la una por emplear un script bash que entraba muy fácilmente en un bucle infinito y la otra por necesitar otro modulo externo, que en mi caso no acababa de funcionar. Así que basándome en la idea del script bash del primero, decidí crearme uno en Python que funcionara correctamente y me solucionara el problema.

El código del hook es el siguiente:

#!/usr/bin/env python
# encoding: utf-8

"""
    bb_gh_sync.py: Mercurial hook to keep synced a repo to Bitbucket & GitHub.
"""

#==============================================================================
# This script maintain synced a repository to booth github and bitbucket sites,
# using only a local mercurial repository. To do this, makes use of hg-git, the
# paths defined in my local hg repo and the environment variable given by hg, to
# push to the site non described in the command line argument. This way, it's
# irrelevant which site I decided to push every time, booth are done by this
# hook.
#===============================================================================

#==============================================================================
#    Copyright 2012 joe di castro <joe@joedicastro.com>
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
#==============================================================================

__author__ = "joe di castro <joe@joedicastro.com>"
__license__ = "GNU General Public License version 3"
__date__ = "23/04/2012"
__version__ = "0.1"

import os
from tempfile import gettempdir
from subprocess import call

def main():
    """Main section"""

    tmp_dir = gettempdir()
    lock_file = os.path.join(tmp_dir, "bb_gh_sync.lock")

    # make sure that only runs once for each repository
    if not os.path.exists(lock_file):
        open(lock_file, "w").close()
        # if pushed to bitbucket, push to github too
        if os.environ['HG_ARGS'] == "push bitbucket":
            call(["/usr/bin/env", "hg", "push", "github"])
        # et viceversa...
        if os.environ['HG_ARGS'] == "push github":
            call(["/usr/bin/env", "hg", "push", "bitbucket"])
    else:
        os.remove(lock_file)

if __name__ == "__main__":
    main()

Ahora solo tenemos que editar nuestro fichero ~/.hgrc para habilitarlo y ya estaría listo para funcionar. Editamos el fichero y le añadimos estas lineas:

[hooks]
post-push = $HOME/dotfiles/hg/bb_gh_sync.py

Ahora, si hacemos un push a Bitbucket, el hace automáticamente un push también a GitHub al acabar el primero, y viceversa. De este modo, hacer un push a ambos alojamientos es tan sencillo como:

$ hg push bitbucket
pushing to ssh://hg@bitbucket.org/joedicastro/joedicastro.com
running ssh hg@bitbucket.org 'hg -R joedicastro/joedicastro.com serve --stdio'
searching for changes
no changes found
running hook post-push: $HOME/dotfiles/hg/bb_gh_sync.py
pushing to git+ssh://git@github.com:joedicastro/joedicastro.com.git
creating and sending data
["git-receive-pack 'joedicastro/joedicastro.com.git'"]
    github::refs/heads/master => GIT:198e8cc9
running hook post-push: $HOME/dotfiles/hg/bb_gh_sync.py
$

De este modo puedo mantener copias de los repositorios locales en ambos sitios de manera automática y sincronizada, sin preocuparme, ni hacer un trabajo extra. Eso si, conviene prescindir de los wikis y documentarlo todo a través de ficheros README.md en formato Markdown para facilitar la integración de los dos sitios. Lo que por otro lado también ayuda a mantenerlos actualizados de manera más sencilla.

Bueno, algunos rivales como Gitorius, también soportan esta característica ↩

Convertir ficheros djvu a pdf en Linux

2011-12-03T00:00:00+01:00

Tengo por costumbre almacenar mis documentos escaneados en el formato djvu, que fue expresamente creado para esa tarea y que otorga la mejor calidad posible en el menor espacio. Es el formato perfecto para documentos complejos sobre los que no se va a realizar un OCR (aunque también lo soporta). Además es un formato abierto, por lo que nos garantiza que podrá seguir empleándose en un futuro. Pero a veces necesito compartir estos ficheros con otros y para evitarme problemas suelo convertirlos a un formato más conocido y difundido como PDF.

Para realizar esta conversión empleo desde hace años (la primera versión es del 2009) un sencillo script en python. Ahora que he necesitado una conversión masiva de documentos de un formato al otro, he modificado el script para hacer esto más sencillo y he decidido compartirlo con cualquiera que pueda necesitarlo.

Los requisitos previos

Está diseñado para funcionar en Linux y necesita de la instalación de dos pequeños programas que son los que realmente realizan la conversión. Estos dos programas son ddjvu y tiff2pdf. Además de tener instalado Python en una versión 2.7 o superior. Estos dos programas vienen en los repositorios de prácticamente todas las distribuciones importantes dentro de los paquetes djvulibre y libtiff.

En el caso de no tenerlos instalados, la instalación de los mismos es muy sencilla, para distribuciones basadas en Debian/Ubuntu:

$ apt-get install djvulibre-bin libtiff-tools

ddjvu nos extrae las páginas que conforman el documento .djvu a un archivo intermedio en formato .tiff y tiff2pdf nos lo convierte en .pdf.

Modo de empleo

Emplearlo es muy sencillo, como se puede ver en la ayuda del mismo:

$ djvu2pdf -h
usage: djvu2pdf [-h] [-d | -z] [-v] file [file ...]

Converts a djvu file into a pdf file

positional arguments:
  file           The djvu file

optional arguments:
  -h, --help     show this help message and exit
  -d             no compression. Best quality but big files.
  -z             zip compression. More quality, more size.
  -v, --version  show program's version number and exit

Básicamente llamandalo desde python y poniendo a continuación el nombre del fichero/s es lo único que necesitamos para ejecutarlo, por ejemplo:

$ ls
documento.djvu  documento_2.djvu
$ python djvu2pdf.py documento.djvu documento_2.djvu
$ ls
documento.djvu  documento.pdf  documento_2.djvu  documento_2.pdf

Opcionalmente tenemos las opciones -d y -z, que nos sirven para especificar si queremos no emplear compresión en el .pdf (por defecto emplea compresión jpeg) o emplear compresión zip, respectivamente. Si no empleamos compresión, la calidad final será la mejor posible, pero los archivos serán muy grandes. En cambio, empleando zip, tenemos unos ficheros ligeramente mayores a cambio de una calidad muy buena. Aunque la compresión zip puede dar problemas con algunos visores y lectores de ebooks.

El script, djvu2pdf.py

El contenido del scipt es el que sigue. Este está disponible como el fichero djvu2pdf.py dentro del repositorio Python Recipes que está alojado en github y actualizado siempre a la última versión.

#!/usr/bin/env python
# -*- coding: utf8 -*-

"""
    djvu2pdf.py: Converts a .djvu file into a .pdf file
"""

#==============================================================================
# This Script does exactly as the description above says.
#==============================================================================

#==============================================================================
#    Copyright 2011 joe di castro <joe@joedicastro.com>
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
#==============================================================================

__author__ = "joe di castro <joe@joedicastro.com>"
__license__ = "GNU General Public License version 3"
__date__ = "03/12/2011"
__version__ = "0.3"

try:
    import sys
    import os
    from argparse import ArgumentParser
    from subprocess import Popen, PIPE
except ImportError:
    # Checks the installation of the necessary python modules
    print((os.linesep * 2).join(["An error found importing one module:",
    str(sys.exc_info()[1]), "You need to install it", "Stopping..."]))
    sys.exit(-2)

def check_execs(*progs):
    """Check if the programs are installed, if not exit and report."""
    for prog in progs:
        try:
            Popen([prog, '--help'], stdout=PIPE, stderr=PIPE)
        except OSError:
            msg = 'The {0} program is necessary to run the script'.format(prog)
            sys.exit(msg)
    return

def arguments():
    """Defines the command line arguments for the script."""
    main_desc = """Converts a djvu file into a pdf file"""

    parser = ArgumentParser(description=main_desc)
    parser.add_argument("file", nargs="+", help="The djvu file")
    group = parser.add_mutually_exclusive_group()
    group.add_argument("-d", dest="qlty", action="store_const", const="-d",
                        help="no compression. Best quality but big files.")
    group.add_argument("-z", dest="qlty", action="store_const", const="-z",
                        help="zip compression. More quality, more size.")
    parser.add_argument("-v", "--version", action="version",
                        version="%(prog)s {0}".format(__version__),
                        help="show program's version number and exit")
    return parser

def process(command, fname):
    """Process the external commands and report the errors."""
    errors = Popen(command, stderr=PIPE).stderr.readlines()
    for line in errors:
        print("{0}: {1}".format(fname.upper(), line.rstrip(os.linesep)))

def main():
    """Main section."""
    args = arguments().parse_args()
    djvu_files = args.file

    for djvu in djvu_files:
        if not os.path.exists(djvu):
            print("ERROR: cannot open '{0}' (No such file)".format(djvu))
        else:
            djvu_filename = djvu.split(".djvu")[0]
            tiff = '{0}.tif'.format(djvu_filename)
            pdf = '{0}.pdf'.format(djvu_filename)
            process(['ddjvu', '-format=tiff', djvu, tiff], tiff)
            if os.path.exists(tiff):
                quality = args.qlty if args.qlty else "-j"
                process(['tiff2pdf', quality, '-o', pdf, tiff], pdf)
                os.remove(tiff)

if __name__ == "__main__":
    check_execs('ddjvu', 'tiff2pdf')
    main()

Fabric & Rsync para realizar Backups

2011-07-13T20:21:00+02:00

En el anterior articulo empleaba fabric y rsync para sincronizar un directorio local y uno remoto en ambas direcciones. Además le añadía las funcionalidades de logger y notify para proporcionar información sobre el proceso durante y después de su ejecución. Y comenzaba el articulo recordando a lftp-mirror, el script que había creado para realizar la sincronización a través de FTP. Pero lftp-mirror realiza algo más que la sincronización, pues también permite realizar el archivado del directorio local en ficheros comprimidos y lanzar varias tareas en una sola ejecución.

Ahora he añadido esta funcionalidad al fichero fabric creado anteriormente. Así empleando este fichero podemos realizar el Backup periódico de varios servidores en una sola operación y de forma completamente automática (basta con programar su ejecución). Se sincronizan los dos directorios y se crea un archivo comprimido del directorio local por cada día de la semana. De este modo siempre tenemos una copia del estado del directorio remoto de los últimos siete días. Y al final del proceso en nuestro correo, un email con el informe del resultado por cada una de las tareas ejecutadas.

En este fichero, rsync_fabric.py, disponemos de tres posibles tareas:

$ fab -l

     A Fabric file for sync two directories (remote ⇄ local) with rsync.

Available commands:

    backup  Sync from remote to local & archive the local directory.
    down    Sync from remote to local.
    up      Sync from local to remote.

Con la primera realizamos el backup (sincronización + archivado) y con las siguientes solo la sincronización desde o hacia el servidor. Una de las ventajas de fabric es que nos permite concatenar tareas fácilmente desde la línea de comandos, así podemos lanzar varias sincronizaciones de forma simultanea. Para poder realizar esto, creo una configuración de sincronización por defecto y después creo una función para cada una las tareas adicionales que simplemente redefinen los valores de estas variables globales. Por ejemplo:

# Variables globales de sincronización predefenidas
env.host_string = "username@example.com"
env.remote = "/my_directory"
env.local = "/home/my_user/backups/my_directory"

# Redefinimos estas variables para otra configuración de sincronización. Por 
# supuesto, pueden tratarse de servidores distintos.
def _databases():
    global env
    env.host_string = "username@example.com"
    env.remote = "/databases"
    env.local = "/home/my_user/backups/databases"

Veamos ejemplos de como podemos utilizar estas tareas:

# "Si queremos sincronizar el contenido local hacia el remoto, por ejemplo 
# para subir los ficheros al servidor por primera vez. Empleando los valores 
# por defecto. El modificador -w lo empleo para que no se detenga en los 
# errores, que de ocurrir, los veremos luego en el informe final."
$ fab -w up
[localhost] local: rsync -pthrvz --delete /home/my_user/backups/my_directory/ 
 username@example.com:my_directory

Done.
# "Pero también podemos especificar una tarea distinta a la por defecto de 
# este modo. Sincronizando desde el servidor a nuestro directorio local las 
# bases de datos."
$ fab -w down:databases
[localhost] local: rsync -pthrvz --delete username@example.com:databases/ 
/home/my_user/backups/databases

Done.
# "Y por supuesto, podemos realizar varias tareas a la vez."
$  fab -w down backup:databases
[localhost] local: rsync -pthrvz --delete username@example.com:my_directory/ 
/home/my_user/backups/my_directory
[localhost] local: rsync -pthrvz --delete username@example.com:databases/ 
/home/my_user/backups/databases

Done.

No empleo contraseña alguna, ni en el fichero ni en la línea de comandos, podría hacerse perfectamente, pero prefiero emplear una clave RSA pública autorizada para las sesiones SSH en el servidor. Es bastante más seguro y cómodo. En los ejemplos no se ve la salida de rsync, pues es capturada (así como los erores) para ser mostrada a posteriori en los informes.

Un ejemplo de informe sería el siguiente:

START TIME =====================================================================
                                                    miércoles 13/07/11, 19:48:55
================================================================================

SCRIPT =========================================================================
fab (ver. Unknown)
Fabric Rsync
http://joedicastro.com

Syncing username@example.com:databases to /home/my_user/backups/databases
================================================================================

RSYNC OUTPUT ___________________________________________________________________

receiving file list ... done

sent 20 bytes  received 825 bytes  153.64 bytes/sec
total size is 827.76M  speedup is 979595.42

ROTATE COMPRESSED COPIES _______________________________________________________

Created file:

/home/my_user/backups/databases_13jul2011_19:49_mié.tar.gz

Deleted old file:

databases_13jul2011_19:37_mié.tar.gz

DISK SPACE USED ================================================================
                                                                        1.60 GiB
================================================================================

END TIME =======================================================================
                                                    miércoles 13/07/11, 19:50:02
================================================================================

Que como podemos ver, ha tardado poco más de un minuto en sincronizar 827.56 Megabytes y el total de espacio ocupado por el directorio y los siete archivos comprimidos es de 1.60 Gibibytes (1,72 Gigabytes).

Ventajas

Las ventajas de sincronizarlo con rsync + ssh vs ftp, como ya comenté en el anterior articulo son enormes. Se ahorra muchísimo tiempo y ancho de banda, lo que ayuda a no saturar la red y no tener que planificar con tanto cuidado las ventanas de backup. Por ejemplo he realizado unas pruebas y para las mismas condiciones: mismo servidor, mismo directorio, mismo horario y condiciones de red; la sincronización remoto → local a través de FTP emplea entre 35 y 45 minutos y cuando lo hacemos a través de rsync emplea entre 2 y 4 minutos. Ahí es nada, estamos hablando de un proceso ~13 veces más rápido.

Código

El código del fichero fabric es el siguiente:

#!/usr/bin/env python
# -*- coding: utf8 -*-

import os
import glob
import tarfile
import time
from get_size import get_size as _get_size
from get_size import best_unit_size as _best_unit_size
from logger import Logger as _logger
from notify import notify as _notify
from fabric.api import env, local

LOG = _logger()

#===============================================================================
# RSYNC HOSTS
#===============================================================================

# Your default host. No need any more if only wants a host.
env.host_string = "username@host"
env.remote = "/your/remote/path"
env.local = "/your/local/path"

# If wants to use various hosts, then define the previous variables like this, 
# one function per host. 
def _host_1():
    """Host variables for host_1."""
    global env
    env.host_string = "username@host_1"
    env.remote = "/your/remote/path/in/host_1"
    env.local = "/your/local/path/for/host_1"

def _host_2():
    """Host variables for host_2."""
    global env
    env.host_string = "username@host_2"
    env.remote = "/your/remote/path/in/host_2"
    env.local = "/your/local/path/for/host_2"

# ...
#
# def _host_n():
#     """Host variables for host_n."""
#     global env
#     env.host_string = "username@host_n"
#     env.remote = "/your/remote/path/in/host_n"
#     env.local = "/your/local/path/for/host_n"

#===============================================================================
# END RSYNC HOSTS
#===============================================================================

def _log_start():
    """Create the Start time info block for the log."""
    # Init the log for multiple hosts. Do not repeat the previous logs.
    if LOG.get():
        LOG.__init__()
    LOG.time("Start time")

def _log_end(task):
    """Create the End time info block and send & write the log."""
    _notify("Rsync", "Ended" , "ok")
    LOG.time("End time")
    LOG.free(os.linesep * 2)
    LOG.write(True)
    LOG.send("Fabric Rsync ({0})".format(task))

def _check_local():
    """Create local directory if no exists."""
    if not os.path.exists(env.local):
        os.mkdir(env.local)

def _rsync(source, target, delete):
    """Process the _rsync command."""
    _log_start()
    LOG.header("Fabric Rsync\nhttp://joedicastro.com",
               "Syncing {0} to {1}".format(source, target))
    _notify("Rsync", "Start syncing {0} to {1}".format(source, target), "info")
    out = local("rsync -pthrvz {2} {0}/ {1}".
                format(source, target, "--delete" if delete == "yes" else ""),
                capture=True)
    _notify("Rsync", "Finished synchronization", "ok")
    LOG.list("Rsync Output", out)
    if out.failed:
        LOG.list("Rsync Errors", out.stderr)

def _compress(path):
    """Compress a local directory into a gz file.

    Creates a file for each weekday, an removes the old files if exists"""
    os.chdir(os.path.join(path, os.pardir))
    dir2gz = os.path.basename(path)
    old_gzs = glob.glob('{0}*{1}.tar.gz'.format(dir2gz, time.strftime('%a')))
    gz_name = "{0}_{1}.tar.gz".format(dir2gz, time.strftime('%d%b%Y_%H:%M_%a'))
    gz_file = tarfile.open(gz_name, "w:gz")
    gz_file.add(path, arcname=dir2gz)
    gz_file.close()
    output = os.linesep.join(['Created file:', '', os.path.join(os.getcwd(),
                                                                gz_name)])
    for old_gz in old_gzs:
        os.remove(old_gz)
        output += os.linesep.join([os.linesep, 'Deleted old file:', '', old_gz])
    return output

def _archive():
    """Archive the local directory in a gz file for each weekday."""
    _notify('Rsync', 'Compressing folder...', 'info')
    LOG.list('Rotate compressed copies', _compress(env.local))
    _notify("Rsync", "Finished compression", "ok")

def _get_diskspace():
    """Get the disk space used by the local directory and archives."""
    gz_size = sum([_get_size(gz) for gz in glob.glob('{0}*.gz'.
                                                     format(env.local))])
    log_size = _get_size(LOG.filename) if os.path.exists(LOG.filename) else 0
    local_size = _get_size(env.local)
    size = _best_unit_size(local_size + gz_size + log_size)
    LOG.block('Disk space used', '{0:>76.2f} {1}'.format(size['s'], size['u']))

def up(server=None, dlt='yes'):
    """Sync from local to remote."""
    globals()["_" + server]() if server else None
    _rsync(env.local, ":".join([env.host_string, env.remote]), dlt)
    _log_end(server)

def down(server=None, dlt='yes', archive=False):
    """Sync from remote to local."""
    globals()["_" + server]() if server else None
    _check_local()
    _rsync(":".join([env.host_string, env.remote]), env.local, dlt)
    if not archive:
        _log_end(server)

def backup(server=None):
    """Sync from remote to local & archive the local directory."""
    down(server, archive=True)
    _archive()
    _get_diskspace()
    _log_end(server)

El fichero siempre actualizado puede ser encontrado en el repositorio Python Recipes que está alojado en github con el nombre rsync_fabfile.py

Sincronizar dos directorios con Fabric y Rsync

2011-07-06T22:02:00+02:00

Anteriormente habíamos visto como sincronizar un directorio remoto y uno local empleando solamente FTP. Ahora vamos a ver la forma de hacerlo empleando ssh y rsync. Para ello vamos a utilizar otra vez Python y una herramienta muy valiosa para cualquier sysadmin que se precie como es fabric (que descubrí gracias a Manuel Viera en esta pregunta en majibu). Evidentemente realizar la sincronización con rsync esta a años luz de hacerlo con FTP, la velocidad de sincronización, el tiempo empleado y la cantidad de datos a mover son mucho menores. FTP es algo que debería utilizarse únicamente cuando no disponemos de acceso via SSH.

La gran ventaja de fabric es que nos permite ahorrarnos el tener que implementar el acceso SSH con paramiko y la entrada de opciones y argumentos con argparse. Gracias a esto los scripts necesarios son mucho más cortos y limpios y su utilización es bastante más sencilla. Fabric ya incorpora una función para emplear rsync, rsync_project, dentro de su modulo de proyectos contribuidos fabric.contrib.project

Una forma de implementar esta sincronización en ambas direcciones empleando esta función predefinida sería esta:

from fabric.api import env, hosts, local
from fabric.contrib.project import rsync_project

env.host_string = "username@host"
REMOTE_PATH = "/your/remote/path"
LOCAL_PATH = "/your/local/path"

@hosts(env.host_string)
def rsync_up(dlt="yes"):
    rsync_project(REMOTE_PATH, LOCAL_PATH + "/", 
                  delete= True if dlt == "yes" else False)

def rsync_down(dlt="yes"):
    local("rsync -pthrvz {0}:{1}/ {2} {3}".
          format(env.host_string, REMOTE_PATH, LOCAL_PATH, 
          "--delete" if dlt == "yes" else ""))

Y luego solo tendríamos que llamar a la función deseada:

# "Para sincronizar de remoto a local"
$ fab rsync_down

Hay que tener en cuenta un detalle con fabric. Cuando se le pasa un parámetro, este es siempre convertido a una cadena. Luego al pasarle True o False no se convierte en un valor booleano, sino una cadena "True"o "False". De ahí que compruebe si el parámetro coincide con "yes" en vez de un valor booleano.

El problema con la función rsync predefinida de fabric es que esta pensada únicamente para subir archivos a un servidor remoto, es decir, es una sincronización en una sola dirección, por eso implemento la sincronización en sentido contrario sin emplearla y empleando local. La autentificación de la sesión SSH puede realizarse especificando la contraseña dentro del propio fichero, pero va en contra del sentido común emplear un método tan inseguro como este. Lo lógico es emplear autorizaciones de sesiones SSH sin contraseña por medio de una clave pública.

Podríamos prescindir de la librería incorporada dentro de fabric y tendríamos algo como esto:

from fabric.api import env, local

env.host_string = "username@host"
REMOTE_PATH = "/your/remote/path"
LOCAL_PATH = "/your/local/path"

def _rsync(source, target, delete):
    """Process the _rsync command."""
    output = local("rsync -pthrvz {0}/ {1} {2}".
                   format(source, target, "--delete" if delete == "yes" else ""))

def up(dlt='yes'):
    """Sync from local to remote."""
    _rsync(LOCAL_PATH, ":".join([env.host_string, REMOTE_PATH]), dlt)

def down(dlt='yes'):
    """Sync from remote to local."""
    _rsync(":".join([env.host_string, REMOTE_PATH]), LOCAL_PATH, dlt)

Pero... un momento, si estamos empleado un comando local, no empleamos rsync_project y empleamos una clave pública para el acceso SSH, entonces no estamos empleando paramiko, ¿de que nos sirve emplear fabric?. Bueno, en realidad rsync_project también emplea local, por lo que no emplea paramiko. Pero las ventajas vienen de que, por ejemplo, este mismo script se podría modificar fácilmente para ejecutar rsync en el servidor en vez de en nuestra maquina local, empleando run en vez de local. Además podemos emplear el mismo fichero para añadir varias tareas más a realizar en el servidor, aparte de la sincronización. Podríamos prescindir de fabric y hacer esto mismo con un script con un número similar de líneas, pero esto nos permite centralizar todas las tareas más comunes sobre ese servidor en un único fichero. Por ejemplo podríamos añadir una tarea para hacer un respaldo previo de una base de datos en el servidor, empleando un comando remoto en el servidor, luego hacer la sincronización separada de la BDD y el resto de ficheros y finalmente eliminar ese respaldo. Puede haber cientos de razones para preferir emplear fabric antes de un script independiente para la sincronización.

Ejecución desatendida de la sincronización

Si queremos programar esta tarea, no sería mala idea que nos avisara de cuando comienza a ejecutarse y del resultado de la misma. Para ello puedo emplear Logger y notify, para implementar esta funcionalidad.

from logger import Logger as _logger
from notify import notify as _notify
from fabric.api import env, local

env.host_string = "username@host"
REMOTE_PATH = "/your/remote/path"
LOCAL_PATH = "/your/local/path"

def _rsync(source, target, delete):
    """Process the _rsync command."""
    log = _logger()
    log.header("Fabric Rsync\nhttp://joedicastro.com",
               "Syncing {0} to {1}".format(source, target))
    log.time("Start time")
    _notify("Rsync", "Start syncing {0} to {1}".format(source, target), "info")
    output = local("rsync -pthrvz {0}/ {1} {2}".
                   format(source, target, "--delete" if delete == "yes" else ""),
                   capture=True)
    _notify("Rsync", "Finished", "ok")
    log.list("Output", output)
    if output.failed:
        log.list("Error", output.stderr)
    log.time("End time")
    log.send("Fabric Rsync")

def up(dlt='yes'):
    """Sync from local to remote."""
    _rsync(LOCAL_PATH, ":".join([env.host_string, REMOTE_PATH]), dlt)

def down(dlt='yes'):
    """Sync from remote to local."""
    _rsync(":".join([env.host_string, REMOTE_PATH]), LOCAL_PATH, dlt)

De esta forma, nos avisaría con una notificación en el escritorio de su inicio y fin, y al acabarse la sincronización, tendríamos un informe en nuestro correo parecido a este:

SCRIPT =========================================================================
fab (ver. Unknown)
Fabric Rsync

Syncing username@host:/your/remote/path to /your/local/path
================================================================================

START TIME =====================================================================
                                                   miércoles 06/07/11, 21:50:48
================================================================================

OUTPUT _________________________________________________________________________

receiving file list ... done
./
index.php

sent 48 bytes  received 200 bytes  45.09 bytes/sec
total size is 99  speedup is 0.40

END TIME =======================================================================
                                                   miércoles 06/07/11, 21:50:54
================================================================================

Este fichero está disponible en el repositorio Python Recipes alojado en github.

Pelican - Repositorio

2011-07-05T23:02:00+02:00

Como complemento a la serie de artículos que he publicado sobre Pelican, el software que genera este blog, añado el repositorio, como había prometido, del contenido del mismo. El repositorio empleaba el sistema de control de versiones Mercurial y estába alojado en Bitbucket.

Las ventajas de disponer del contenido del blog en un repositorio son las de poder enmendar un error con suma facilidad y en muy poco tiempo, además de la de poder trabajar con distintas versiones del mismo (pruebas y producción). Además el repositorio en Bitbucket me proporcionaba una copia de seguridad adicional del sitio sin esfuerzo alguno. Y si alguien está interesado en crear su propio blog con Pelican y quiere saber como he realizado el mio, ahí tiene las claves. Salvo el propio Pelican (que no tendría mucho sentido) todo el material empleado para generarlo está en el. Y disponiendo del fichero fabric, se pueden descargar Pelican e instalar el entorno virtual en un minuto.

Para automatizar todas las tareas, incluso las más comunes del repositorio, he añadido al fichero fabric fabfile.py dos tareas más:

def commit(message):
    """Make a commit to the local mercurial repository."""
    local("hg add")
    local("hg commit -m '{0}'".format(message))

def push():
    """Make a push to the remote mercurial repository."""
    local("hg push ssh://hg@bitbucket.org/joedicastro/joedicastro.com")

Con estas puedo hacer un commit y un push a Bitbucket en un solo paso, por ejemplo:

fab commit:"Añadido articulo: Pelican - Repositorio" push

También he cambiado la página que generaba los archivos del blog, ya que no me gustaba el formato anterior: una fecha, un articulo. He pasado de esto:

{% extends "base.html" %}
{% block content %}
<section id="content" class="body">
<h1>Archivos de {{ SITENAME }}</h1>

<dl>
{% for article in dates %}
    <dt>{{ article.locale_date }}</dt>
    <dd><a href='{{ article.url }}'>{{ article.title }}</a></dd>
{% endfor %}
</dl>
</section>
{% endblock %}

a esto:

{% extends "base.html" %}
{% block content %}
<section id="content" class="body">
<h1>Archivos de {{ SITENAME }}</h1>
{%- set years_month = {} -%}
{%- set months = {1:'Enero', 2:'Febrero', 3:'Marzo', 4:'Abril', 5:'Mayo', 
                  6:'Junio', 7:'Julio', 8:'Agosto', 9:'Septiembre', 
                  10:'Octubre', 11:'Noviembre', 12:'Diciembre'} -%} 
{%- for article in dates -%}
  {%- if article.date.year not in years_month -%}
    {%- do years_month.update({article.date.year:[article.date.month]}) -%}
  {%- else -%}
    {%- if article.date.month not in years_month[article.date.year] -%} 
      {%- do years_month[article.date.year].append(article.date.month) -%}
    {%- endif -%}
  {%- endif -%}
{%- endfor %}

{% for year in years_month|sort(reverse=True) -%}
  <h2 class="year">{{ year }}</h2><dl>  
  {% for month in years_month[year] -%}
    <dt class="month">{{ months[month] }}</dt>
    {% for article in dates -%}
      {% if article.date.year == year and article.date.month == month -%}
        <dd><span class="day">{{ article.locale_date.split()[1] }}</span>  <a href='{{ article.url }}'>{{ article.title }}</a></dd>
      {%- endif %}
    {%- endfor %}
  {% endfor %}</dl>
{% endfor %}
</section>
{% endblock %}

Donde los artículos están archivados por año, mes y día, con un formato que personalmente me agrada bastante más.

El repositorio de este blog se puede encontrar en github.