Blogueando con Nikola

No soy una persona dada a bloguear. Me gustan más los wikis. y los he usado para varios proyectos: comunitarios [1], educativos [2], personales [3].

Debido a que inicié publicando en línea con tecnologías wiki enfocadas a colectivos, me interesaron más que sólo las de publicación individual, como los blogs, pues el esfuerzo por aprenderlas y configurarlas era casi el mismo, pero la ganancia era plural. Hice transiciones de lo úno a lo otro a través de "blikis", que intentaban dar soporte a la escritura de blogs, mediante plantillas, formularios, plugins y otros hacks en los wikis. De hecho, montar un wiki es de las primeras sugerencias para un colectivo que quiere tener presencia en línea y se pueden crear reglas y normas y adaptaciones para soportar las páginas personales en éste. Es una estrategía para pasar de lo colectivo a lo individual con una sóla tecnología, la de los wikis, que, en mi experiencia, es más fácil que intentar ir en el sentido contrario y procurar, a partir de una tecnología de blog construir una forma de presencia colectiva en la que no sólo múltiples autores publiquen cada uno su página y se referencien entre sí, (como en los planetas de blogs) sino escriban a varias manos un texto colectivo.

Encontrar tecnologías apropiadas a ambos lados del espectro, el de lo individual y el de lo colectivo y facilitar los tránsitos de lo uno a lo otro es importante. En la medida en que las tecnologías evolucionan y las conozco más, diría, sin embargo, que la principal diferencia entre los wikis y los blogs no es tanto la tecnología subyacente, sino su caracter. Mientras que los primeros tienen un tono colectivo, los segundos tienen un tono personal que en ocasiones, como en este escrito, es necesario.

Después de probar con varias tecnologías, me he venido decantándome por aquellas que son sencillas, fáciles de entender y extender, portables y amigables respecto a los sistemas de control de versiones de código y por tanto son mucho menos dependientes de un lugar centralizado y no tienen una curva de aprendizaje muy inclinada. Para el caso de los wikis estoy usando dokuwiki, web2py como webframework, fossil como sistema de control de versiones y recientemente encontré Nikola como motor de blogs. En este post hablaré de mis experiencias e inquietudes alrededor de Nikola.

Bloguear con Nikola ha sido muy agradable. Me gusta el sorpote para diferentes lenguajes de etiquetamiento ligeros y aunque Markdown no funcionó para mi, por un problema que aún no sé cuál es exactamente, no tengo problema con escribir en reStructuredText, además que me veo haciéndolo dentro de poco con libretas de IPython, que son soportados también. Creo que su autor, Roberto Alsina, está haciendo muchas cosas bien, en particular escuchando a la comunidad de usuarios e incorporando las mejores de los desarrolladores y con cosas como Ghost, definitivamente uno ve que el tiempo de plataformas de blogging sencillas, con escritura orientada a lenguajes de etiquetamineot ligero está llegando.

Estas son algunas de las inquietudes que me generó el uso de Nikola:

• La primera cosa que noté es que la directiva ".. TEASER_END" no está funcionando por alguna razón y los blog post se muestran completos en la página de inicio, pero luego me di cuenta que había sido un problema en cómo tenía el archivo de configuración, pues está habilitado por omisión sólo para los RSS, mientras que no lo está para la página web. Aquí el error fue de capa ocho, es decir en la persona (yo) que no leyó bien el archivo de configuración :-P.

• Las imagenes de la galería de imagenes por omisión deberían soportar distintas extensiones, quizás todas las que soporta el navegador web. Estuve peleando bastante tiempo con una imagen que no aparecía en la galería imagenes, sólo para descubrir que sólo bastaba renombrar la terminación "jpeg" por "jpg", sin la "e" y listo. Algo que no hubiera supuesto de modo natural.

• Cuando escribo utilizando lenguajes de etiquetamiento ligero me gusta intercalar las notas al pie de página inmediatamente después del párrafo que las invoca. De este modo, si quiero cambiar algo en las revisiones posteriores del artículo, puedo llegar más rápidamente al contexto (el párrafo) desde el cual se invocó la nota el pie. Sin embargo, si escribo de esta manera en Nikola, veré mis notas al pie intercambiadas con los párrafos siguientes y no realmente al final de toda la página, quisiera que hubiese una manera para indicarle a Nikola que, a pesar de que las notas al pie están intercaladas con los párrafos, cuando produzca la salida html, efectivamente las queremos al final de toda la página.

• Estaba teniendo problemas con las citas a pie de página. La invocación de las mismas en los párrafos no se convertía en una referencia como tal, sino que aparecía algo como "[#mi-referencia]" en el lugar donde debería aparecer un pequeño numerito. A veces funcionaba y otras veces no. Se debía a que estaba cometiendo un error en la escritura, pero no había podido detectar cuál es y era que las referencias debían estar rodeadas de espacios en blanco, en "reStructured Text", que al ser derivado de python, le da importancia al espacio en blanco, pero en ocasiones es difícil de detectar (como en el caso de las referencias!). Esto, por supuesto no es un error de Nikola, sino una característica de diseño del lenguaje reStructured Text. La posibilidad de elegir distintos lenguajes permite no lidiar con ella y seguramente tan pronto los notebooks (libretas) de IPython soporten notas a pie de página, estaré usándolos en lugar de reStructured Text para escribir mi blog (aunque no sé como se combinarán con las directivas personalizadas)

• Quizás la mayoría de las personas, al igual que yo, le demos una que otra repasada al blog después de publicarlo por primera vez, agregando enlaces, corrigiendo la redacción o la ortografía. Nikola indica cuándo se creo el archivo por primera vez con el campo "date", pero creo que falta el campo "update" que indique cuando se creo por última vez. Afortunadamente Nikola soporta la definición de campos personalizados, como descubrí al reportar este asunto en el gestór de código, inquietud que, como otras que escribía acá y reporté en el gestor de código, fue resuelta en menos de 3 minutos! lo cual habla de la proactividad de la comunidad!.

• Los índices no se están regenerando de modo adecuado. Coloqué un post con la etiqueta "draft" y otro como "retired", luego los quité, pero, a pesar de que ellos aparecen en la portada, no lo hacen en el listado del enlace "Archives".

• Sobre las posibilidades futuras de Nikola:

  • Me gustaría usarlo para la generación de libros escritos en IPython. Creo que Nikola e IPython pueden ser complementos muy buenos en este escenario, como ya lo ha mostrado el trabajo de Damian Ávila [4] [5] [6]. Me imagino teniendo un archivo de configuración (ojala en yaml) donde se colocan unidades temáticas organizadas jerárquicamente. Algo como:

    unidad 1:
      - titulo: Presentación
      - archivo: post/presentacion.ipynb
    unidad 2:
      - titulo: Instalando web2py
      - archivo: post/instalacion.ipynb
      unidad 2.1:
        - titulo: Windows
        - archivo: post/instalacion-windows.ipynb
      unidad 2.2:
        - titulo: Gnu/Linux
        - archivo: post/instalacion-gnu-linux.ipynb
    

    Esto haría que los mismos contenidos se puedan reorganizar de diferentes maneras, dándoles flexibilidad y modularidad. Para la navegación lateral de tabla de contenido se podría usar los índices que brinda el tema de bootstrap, pero si se van a colocar contenidos anidados, me parece que es mucho mejor usar el estilo que emplea el sphinixsidebar en la documentación de Kivy. que provee tanto soporte para una barra flotante como para subsecciones anidadadas.

  • Roberto Alsina está pensando en Alva, la contraparte de servidor de Nikola y estaría usando para su implementación Django. Yo en este momento estoy usando Nikola en la parte estática de mi sitio hecho web2py. Quizás, en la medida en que los talleres de programación web de y para novatos avancen, implementemos la solución de blogging integrando Nikola a web2py, básicamente colocando un par de formularios que permitan escribir el blog post directamente en la web y quizás algún tipo de ayuda con las etiquetas para la escritura, vía markItUp <http://markitup.jaysalvat.com/home/>. web2py se encargaría del soporte multiusuario, la acreditación y esconder el control de versiones y lo que ocurre tras bambalinas en la consola, al mismo tiempo que se tiene una solución que, a diferencia de lo que se haría con Django, puede ser prácticamente ejecutada por completo desde una memoria USB. Otra de las cosas que se podría delegar en web2py es el control de comentarios y el ingresar (vía Janrain) desde diferentes redes sociales para hacerlos y no es que crea que acá Disqus no está haciendo un excelente trabajo, sino que, progresivamente web2py asumiría la parte dinámica del sitio, incluyendo los comentarios, lo cual haría que todo el lugar sea más autónomo y portable, muy en la línea del indieweb. Ya veremos qué ocurre.

En resumen, Nikola constituye una solución que viene a satisfacer necesidades sentidas de un nicho de bloggers que se interesan por la implementación técnica de la solución y quieren un balance entre flexibilidad y simpleza al tiempo que no temen la consola de comandos. Creo que tiene un prometedor futuro, no sólo por sus características tecnológicas, sino por su preocupación por las inquietudes de los usuarios y por una comunidad proactiva que ayuda con la implementación de las mismas. Veremos qué dicen una vez me haga a mi mismo parte de la conversación sobre esta interesante tecnología.