joe di castro

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.

Pelican - Configuración y personalización

2011-06-30T01:21:00+02:00

Con este articulo cierro la serie que le he dedicado a Pelican como herramienta idónea para crear blogs estáticos con mantenimiento cero. Aquí voy a tratar de la parte más compleja de Pelican, la que nos permite personalizarlo y adaptarlo a nuestros gustos y necesidades. El primer nivel de personalización se obtiene a través del fichero de configuración (aunque no es necesario, es recomendable emplearlo). El segundo nivel vendría mediante la personalización del tema empleado, bien creando uno nuevo o bien modificando el que viene por defecto. El último nivel vendría de modificar el propio Pelican. Todos son posibles y están a nuestro alcance, gracias a que es Software Libre.

Si bien yo he personalizado mi sitio con respecto al sitio por defecto, y aún quedan ciertas cosas que aún quiero cambiar, no he necesitado de momento más que modificar el fichero de configuración y el tema que viene por defecto. En Pelican no he tocado nada exceptuando el activar por defecto Markdown Extra, algo que Alexis tuvo como gentileza aceptar como modificación a Pelican. Es posible que en el futuro algunas de las cosas que tengo en mente me lleven a modificarlo, y espero poder así contribuir en alguna medida a su desarrollo.

Configuración

La configuración se hace a través de un fichero python, que en el ejemplo por defecto se llama pelican.conf.py y en nuestro ejemplo estaría en myblog.com/site/pelican.conf.py. Para llamar al fichero de configuración se utiliza la opción -s y en nuestro ejemplo sería:

$ pelican -s ./site/pelican.conf.py

Este es un tema que está muy bien resuelto en la documentación. De todos modos voy a hablar de unos cuantos campos interesantes y alguno no incluido dentro de la documentación. Entre paréntesis indico los valores por defecto.

OUTPUT_PATH ('output/') y PATH (None)

Empleando estos dos valores, conseguimos que solo tengamos que especificar el fichero de configuración en la linea de comandos empleada para llamar a Pelican. El primero define el directorio de salida donde queremos que se genere nuestro sitio y el segundo el directorio origen de nuestro contenido.
SITESUBTITLE (u'')

Un subtitulo que se puede poner al blog, e.g. un lema. No aparece documentado.
JINJA_EXTENSIONS ([])

Puede ser necesario habilitar ciertas extensiones de Jinja2 para personalizar el tema que vamos a emplear. Por ejemplo, para mostrar la nube de etiquetas con las etiquetas ordenadas alfabéticamente, he habilitado una extensión que necesitaba para el proceso de esta manera:
```
JINJA_EXTENSIONS = ['jinja2.ext.do']
```
STATIC_PATHS (['images',])

Te permite especificar los contenidos estáticos que quieres añadir a tu blog y que acabaran colgando de la carpeta static. Yo por ejemplo lo empleo para alojar las imágenes en static/pictures y el mapa flash que utilizo en el articulo Combatir el spam en Drupal en static/ammap así:
```
STATIC_PATHS = ["pictures", "ammap", ]
```
TAG_FEED (None) y TAG_FEED_RSS (None)

Te permiten establecer fuentes Atom y RSS por etiqueta, que es una opción muy interesante para quienes solo les interesa un tema de los que trates o para formar parte de un Planet sin mezclar temas. Eso si, lo lógico es modificar luego el tema para que aparezcan disponibles.
DIRECT_TEMPLATES (('index', 'tags', 'categories', 'archives'))

Estas son las plantillas del tema que generan una página por si mismas. No viene documentada, pero yo he cambiado los valores por defecto para añadir una página personalizada a la que redirijo los errores 404 (Página no encontrada) de esta manera:
```
DIRECT_TEMPLATES = ('index', 'tags', 'categories', 'archives', 'notfound')
```
PIWIK_URL y PIWIK_SITE_ID

Te permiten configurar tu sitio para emplear el magnifico sistema de analíticas web Piwik. Yo hace unos dos años que lo empleo en mis sitios, porque tiene la ventaja de que no dependes de un script de un dominio externo. Esto te ahorra consultas DNS y que la página se quede esperando a cargar completamente cuando estos fallan. De esta manera tienes el control total sobre las estadísticas de tu web sin tener que renunciar a la calidad de otros servicios externos.
FILES_TO_COPY (())

Básica si queremos emplear ficheros como .htaccess o robots.txt. No está documentada tampoco. El uso de la misma consiste en una tupla de tuplas con los valores de las rutas del fichero origen y su destino. En este sitio por ejemplo:
```
FILES_TO_COPY = (('extra/robots.txt', 'robots.txt'),
                 ('extra/favicon.ico', 'favicon.ico'),
                 ('extra/.htaccess', '.htaccess'),)
```

Personalización

Pero si realmente queremos personalizar el sitio, tanto en funcionalidad básica como en su aspecto, nos toca modificar el tema por defecto. Aquí podemos optar por tres vías: Crear el nuestro propio, empezar un tema casi desde cero, eligiendo el tema por defecto simple (solo texto) o partir de la base del tema por defecto notmyidea. Este último es el que hemos estado empleado en nuestro ejemplo y el que yo modifiqué hasta llegar donde lo tengo ahora.

Para comprender de que consta un tema y como podemos personalizarlo, lo mejor es analizar el tema notmyidea.

notmyidea/
├── static
│   ├── css
│   │   ├── main.css
│   │   ├── pygment.css
│   │   ├── reset.css
│   │   └── wide.css
│   └── images
│       └── icons
│           ├── delicious.png
│           ├── lastfm.png
│           ├── linkedin.png
│           ├── rss.png
│           └── twitter.png
└── templates
    ├── analytics.html
    ├── archives.html
    ├── article.html
    ├── article_infos.html
    ├── base.html
    ├── categories.html
    ├── category.html
    ├── comments.html
    ├── disqus_script.html
    ├── github.html
    ├── index.html
    ├── page.html
    ├── pagination.html
    ├── piwik.html
    ├── skribit_tab_script.html
    ├── skribit_widget_script.html
    ├── tag.html
    ├── taglist.html
    ├── tags.html
    ├── translations.html
    └── twitter.html

static/css

Aquí es donde se guardan las Hojas de estilo en cascada (CSS) que emplea el tema. Aunque la el fichero wide.css no es empleado por el tema, solo para la versión wide del mismo. Yo la eliminé como primera medida. Luego tenemos main.css que es la hoja de estilo principal, pygment.css que es la que emplea Pygments para el resaltado de sintaxis y reset.css para resetear los navegadores a unos valores comunes por defecto.

Si lo que queremos es tener un sitio con un buen rendimiento, deberíamos dar como mínimo dos pasos, consolidar todas la hojas de estilo en una sola y minimizar el tamaño de esta. Consolidarla en este caso es realmente sencillo, simplemente debemos insertar el contenido de reset.css al principio del fichero main.css y pygment.css al final del mismo. Depués hay que eliminar los imports de estas hojas en main.css*. Luego para minimizar su tamaño eliminar comentarios y lineas en blanco y poner una regla por línea.

Otro paso que dí para mejorar el rendimiento es no usar las web fonts externas (ni internas), que aunque le dan un aspecto inmejorable, hay que reconocerlo, requieren cargar otro recurso externo, desde mi punto de vista innecesario.

Lo mejor en estos casos es seguir siempre las recomendaciones de estas dos magnificas herramientas: YSlow de Yahoo y Page Speed de Google. Afortunadamente hay sitios web como GTmetrix o WebPagetest que nos permiten ver los resultados de ambas herramientas en nuestro sitio web sin necesidad de instalarlas (aunque para el desarrollo es más que recomendable). Si por ejemplo emplearamos GTmetrix los valores que arroja un sitio con el tema por defecto son:

Page Speed (tema por defecto) YSlow (tema por defecto)

B (80%) B (85%)

Valores bastante mejorables. Los valores actuales para este sitio, una vez personalizado el tema y configurado correctamente el .htaccess son:

Page Speed (tema personalizado) YSlow (tema personalizado)

A (91%) A (95%)

Y si nos fijamos en los resultados, las penalizaciones de rendimiento vienen de los scrips externos de Piwik y Disqus, principalmente de este último. Sin emplear estos scripts los valores suben a:

Page Speed (sin scripts) YSlow (sin scripts)

A (100%) A (98%)

En resumen, una optimización más que correcta, solo hay que ver los valores de las páginas del Top 1000 que ofrecen en GTmetrix. Obtener una optimización como esta con un CMS no es imposible (había conseguido unos valores solo un poquito peores con Drupal) pero si bastante más complicado. La experiencia del usuario depende mucho de estos valores, hay que contar con que no todo el mundo dispone de buenos accesos a Internet.

Evidentemente, después cada uno retocara el fichero CSS resultante a su gusto para personalizar el aspecto del sitio. En este caso estoy empleando CSS 3 y valida correctamente.

Page Speed (tema por defecto)	YSlow (tema por defecto)
B (80%)	B (85%)

Page Speed (tema personalizado)	YSlow (tema personalizado)
A (91%)	A (95%)

Page Speed (sin scripts)	YSlow (sin scripts)
A (100%)	A (98%)

static/images/icons

Son los iconos empleados por la hoja de estilo para los enlaces sociales de la parte inferior de la página. Yo no los empleo. ¿Entonces como se ven? Bueno lo primero que hice fue crear un sprite para cargar una sola imagen en lugar de 6, es decir menos solicitudes al servidor. Después incorporé esta imagen dentro del propio fichero CSS con un Data URL, y gracias a haberla optimizado hasta ocupar solamente ~3k, me compensaba hacerlo. Una consulta menos al servidor. Lo mismo hice después con el logotipo (1K) y al final no se carga ninguna imagen por defecto en el blog, 0 consultas. Los navegadores modernos soportan esto sin problemas, los que no lo hacen, no muestran la imagen, solo el enlace, que tampoco es un ningún problema.

Así es como queda en main.css la imagen que da vida a los iconos de los enlaces a la redes sociales:

#extras div[class='social'] a{background-repeat:no-repeat;background-image:url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAACSCAMAAAB7VbqAAAAAwFBMVEWQBQCWFxU5VpedVy+tUE5LZaBPZZZDabDdYSpke75vfZBkfbJZgc+heztshKvldjBgld91j9+Uj4p5ksZ/lLzthzLqhz+MmrAcvuaDofihpYRzq/D4mDeUp9KetkSirsnQpKWpvV/qqHvHsJjnqY/3qWK1ubbIun2jwLHEu7xm1O+6xoOtv++7wte0yNzxwH563e/3xJjK06ya5vXY3p7U2+3e3tbm6IT63cLn7czr7fbZ9Prz7+r8+O/3+fb9//z6WVfkAAADNElEQVRIx9WV4XqiPBCFoyu4aVjQBrW2ImBX3aJYdQERIbn/u9qTRKzd7/n+b88jxHlnMswEY4hIGYUcLZYKklLbtixqNBymhNl2yG/2lBFqu1LKKjD2dEioxfIKKOfaVgA+HkoptsoGoDxPA8orKZTtEIdyNWE4zXEbUgVokAq4p1JuqQHIX8G9lYK2EdOpkNuhlJxec+TTrcxpJVENAOK3iK9oLkOLEmbqGQZ4dMAtRlJj617QZErQvqpHiVLVvvhL/y6oFx40HhktaqJt9X2mtSDwHg7L1p6NAJZY9eZwB8aHsgF61zaAnr8spXxX9piMR8umxAQQZBp5ZDTSOZYgzXjkKTCbvTeKNPLgKaCTK/dCNldQlu9wL0aNHH9XADnK2UGWXil/GoDJyFx6P69gNlPPWy698cIDWOj68DzvO+Qt0D7MsXcV2v86by55+qSEPP3+pKf/ARfxF5Dy8gH2+/0N7Pc3oCUMSJIWyESBRANxgX4nyQ1cEiMDEkR8BheT4jYl2bdJW5DsdczlA9z09N/2v86bw1Vs4vl8c6xbcI7ncQxkCBFFPM8a0QAfDTjOM70453lc630bx2ezXJt5oUARx40BmQF3EfFroXJs5gaU30inF+G3vombBnuu7JFer9OJ1JQMZcQ/SK8WEekRVRYqjb+RSMq60yHF8VzXRVHAWUsV0TZVIEekctzafEPKTnS/o+qog7z361FHkfhK/5ZV0MrnPAgqEvBWYZoGPCSt6aujLGScuC5j+LAdNkAVALCrUuVndwARvhoJs3C3WSXUFB8HjtW1LFxCvz3WtQC03Bw5fOsDdEPl794BPMW9Ap3DAMuyCc5nJQ2sO2AB+BgYCU1dCkwwhjjnfNUO8ycTl/lf6pxTtzzfQXl1BduXAQ5/7jiDl50CgcMnq6Ku69WEOQHAgD8+Pq5WbysMLle78tdq8jDR4oMc4HzKsuPuBRoMLKHB6+spG2hgrwCydQZpQH0NTmsgB/4BTVe1AphyNCBXoMk2p9MvB7bT1xEitB+eFXCch3WhSl/Z/T6dcMddr581KAD6fdd9fnyoTbdvrN93+v2uXbTt17sQyvV6/AE7UZJYs2UOngAAAABJRU5ErkJggg==");padding-left:25px;}
.social a[href*='atom.xml']{background-position:3px 6px;}
.social a[href*='rss.xml']{background-position:3px -20px;}
.social a[href*='twitter.com']{background-position:3px -46px;}
.social a[href*='identi.ca']{background-position:3px -72px;}
.social a[href*='facebook.com']{background-position:3px -98px;}
.social a[href*='bitbucket.org']{background-position:3px -124px;}

static/templates

Estas son las plantillas que dan vida al tema y emplean Jinja2. Los nombres son bastante descriptivos de la función que realiza cada una de ellas. En mi caso hay una serie de ellas que no empleo, como son: analytics.html, article_infos.html, github.html, skribit_tab_script.html, skribit_widget_script.html, translations.html y twitter.html. He realizado bastantes modificaciones en las plantillas y me extendería demasiado explicándolo, además sigo realizando cambios. Aún no lo tengo todo como yo lo quiero, y aún voy a personalizar y optimizar más cosas. Cuando lo tenga todo listo, pienso publicar un repositorio con el contenido que genera este blog, tanto a efectos de copia de seguridad, como de que le pueda servir a alguien como guía para montar el suyo propio.

De todos modos si puedo decir que he añadido una que no existía, notfound.html para los errores 404 y pienso crear una nueva para los errores 403. Además he creado los enlaces para los feeds RSS y Atom de las etiquetas y eliminado el bloque de información que aparecía en cada articulo. Además en la plantilla tags.html que por defecto viene vacía, he creado lo necesario para generar la nube de etiquetas. tags.html queda entonces así:
```
{% extends "base.html" %}
{% block content %}
<section id="content" class="body">
<h1>etiquetas</h1>
  <ul id="cloud">
    {%- set all_tags = {} -%}
    {% for ctag in tag_cloud -%}
      {% do all_tags.update({ctag.0:ctag.1}) %}
    {%- endfor %}
    {% for tag in all_tags|sort %}
      <li class="tag-{{ all_tags[tag] }}"><a href="tag/{{ tag|replace(" ", "%20") }}.html">{{ tag }}</a></li>
    {% endfor %}
  </ul>
</section>
{% endblock %}
```
También he realizado las modificaciones pertinentes para que el contenido validara perfectamente en HTML 5.

Pero como ya he dicho es un proceso que aún no he finalizado. Cuando lo termine y publique el repositorio, actualizaré también este articulo.

Pelican - Publicación y automatización

2011-06-28T23:54:00+02:00

Una vez que sabemos como instalar Pelican y crear contenido con él, es hora de saber como convertir ese contenido en un blog real disponible en internet. Es decir, saber como publicar ese contenido. Como hemos visto hasta ahora, al constar básicamente de simples ficheros HTML, un servidor de archivos es más que suficiente para servir el blog. Esto nos abre un gran abanico de posibilidades, desde emplear un potente (y barato) servidor de ficheros en la nube como Amazon S3, pasando por las páginas web estáticas que nos permiten repositorios como Bitbucket o GitHub, por los tradiciones hostings compartidos (e.g. este blog), hasta un servidor casero sencillo montado sobre un NAS.

Aún cuando es posible emplear un simple servidor de archivos para alojar el blog, siempre es mejor contar con un servidor web detrás (Apache, nginx, lighttpd, ...) que nos permita hacer redirecciones para nuestras antiguas páginas si ya disponíamos de un blog anterior o manejar los errores HTTP 404 o 403 de forma personalizada.

Publicar el contenido

Publicar el contenido de una web es tan sencillo como volcar el contenido del directorio que nos genera Pelican (en nuestro ejemplo sería myblog.com/site/output/*) en el directorio destino de nuestro servidor web. Dependiendo del método que hayamos elegido para alojar nuestro blog, puede ser tan sencillo como una copia de archivos o emplear FTP (SFTP) ó SSH (SCP, Unison ó rsync). Aquí el tema radica no en la primera vez que vayamos a subir el contenido al servidor, si no en las sucesivas, a medida que vayamos creando contenido nuevo. No tendría ningún sentido volver a subir todo el contenido cada vez, si no solamente el nuevo o el que haya cambiado. Para eso necesitamos sincronizar los dos directorios.

Si solamente disponemos de acceso FTP (o SFTP) a nuestro servidor, entonces tendremos que emplear una herramienta que nos permita la sincronización sobre FTP, como puede ser lftp. Y el proceso se puede automatizar con un script como el que describo en Sincronizar una carpeta local y una remota a través de FTP: lftp-mirror. Si disponemos de acceso a través de SSH, entonces la elección es clarisima, rsync. Más adelante explico una manera de emplearlo de forma automática.

Cualquiera de ambas soluciones nos permite subir el contenido en apenas segundos, (sobre todo en el caso de rsync) cuando se trata de añadir un articulo nuevo, por ejemplo. Y lo mismo a la hora de hacer una rectificación, es tan inmediato como lo pueden ser plataformas como Wordpress, Drupal y similares. Además, con las potentes herramientas que existen para hacer cambios múltiples en varios ficheros de texto a la vez, se pueden realizar tareas casi imposibles con una plataforma de blogs tradicional sin recurrir a consultas SQL en la BDD o a plugins externos. Una de estas herramientas, sin recurrir a find, grep, awk y sed, puede ser regexxer.

Generar el contenido en el propio servidor

Si el alojamiento que hemos escogido nos permite instalar programas python, entonces tenemos la posibilidad de instalar Pelican en el servidor remoto. De esta formar podríamos subir únicamente los archivos markdown o reStructuredText al servidor y generar allí mismo el contenido web. De este modo la cantidad de datos a subir sería ridícula y un simple comando FTP nos serviría. Luego bien podríamos lanzar Pelican a través de una consola SSH o bien dependiendo del servidor, tener un demonio corriendo que cuando detectara un cambio en el sistema de ficheros lanzará un script que generara el contenido con Pelican.

Otra posibilidad que me convence más, es de la poder instalar un repositorio en el servidor con un software de control de versiones, como Git o Mercurial. La idea sería tener un repositorio local, y al hacer un push hacia el repositorio remoto, a través de un hook activar la generación de la página con Pelican. Esto nos permitiría además poder tener varias copias del repositorio (por ejemplo en GitHub o Bitbucket) y por lo tanto de la web, haciendo "innecesarias" las copias de seguridad.

Automatizar todos los procesos

Pero lo ideal es poder automatizar todas las tareas que hemos visto hasta ahora, empleando unos pocos comandos para realizarlas sin esfuerzo alguno (bueno, a menos que tengas tú ghostwriter particular, me temo que los artículos los seguirás teniendo que escribir tú). Para poder realizar esto disponemos de la fantástica y potente herramienta Fabric (el Capistrano para Python) que nos permite ejecutar comandos locales o remotos en múltiples servidores. Esto nos permite hacer despliegues de software sin apenas esfuerzo en distintas máquinas, copiar ficheros o ejecutar tareas repetitivas empleado una corta serie de comandos. Una grandísima herramienta para administradores de sistema y desarrolladores.

Lo único que necesitamos es instalar fabric y crear un fichero llamado fabfile.py donde especificaremos las tareas que queremos programar. Para instalar la última versión estable de fabric, lo mejor es emplear easy_install o pip

$ pip install fabric

Una vez creado el fichero fabfile.py, lo único que tendremos que hacer para ejecutar una tarea del mismo, sería escribir el comando fab seguido del nombre que le hayamos dado a la tarea (este sería el funcionamiento básico). Y la tarea se ejecutaría inmediatamente.

Para comprender mejor como funciona Fabric, muestro aquí el contenido actual de mi fichero fabfile.py

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

"""
    fabfile.py: A fabric script for generate my personal blog
"""

__author__ = "joe di castro <joe@joedicastro.com>"
__license__ = "GNU General Public License version 3"
__date__ = "28/06/2011"
__version__ = "0.2"

import os
from fabric.api import *
from fabric.contrib.project import rsync_project
from fabric.contrib.console import confirm

PELICAN_REPOSITORY = "git://github.com/ametaireau/pelican.git"
PROD = "joedicastro.com"
PROD_PATH = "/home/joedicastro/webapps/joedicastro"
LOCAL_WEB = os.path.join("~/www", PROD)
ROOT_PATH = os.path.abspath(os.path.dirname(__file__))
ENV_PATH = os.path.join(ROOT_PATH, "env")
PELICAN = os.path.join(ROOT_PATH, "pelican")
CONFIG_FILE = os.path.join(ROOT_PATH, "site/pelican.conf.py")
OUTPUT = os.path.join(ROOT_PATH, "site/output")

def _valid_HTML():
    """Remove the obsolete rel="" and rev="" links in footnotes."""
    for path, dirs, files in os.walk(OUTPUT):
        for fil in files:
            if fil[-5:] == ".html":
                local("sed -i {0} -r -e 's/re[l|v]=\"footnote\"//g' {0}".
                      format(os.path.join(path, fil.replace(" ", r"\ "))))

def _make_env():
    """Make a virtual enviroment"""
    local("virtualenv {0}".format(ENV_PATH))

def _del_env():
    """Delete a virtual enviroment."""
    local("rm -rf {0}".format(ENV_PATH))

def _clone_pelican():
    """Clone Pelican from repository."""
    local("git clone {0}".format(PELICAN_REPOSITORY))

def _install():
    """Install Pelican in the virtual enviroment."""
    with lcd(PELICAN):
        local("{0}/bin/python setup.py install".format(ENV_PATH))

def _browse():
    """Browse the local Apache site."""
    local("firefox -new-window http://localhost/joedicastro.com 2>/dev/null &")

def _gen(autoreload=False):
    """Generate the site from source."""
    local("{0}/bin/pelican {2} -s {1}".format(ENV_PATH, CONFIG_FILE,
                                              "-r" if autoreload else ""))
def _clean():
    "Remove the output folder."
    local("rm -rf {0}".format(OUTPUT))

def _local_deploy():
    """Deploy to the local apache web server."""
    local("rm  -rf {0}".format(LOCAL_WEB))
    local("cp -r {0} {1}".format(OUTPUT, LOCAL_WEB))

def pull_pelican():
    """Update Pelican to last revision from repository."""
    with lcd(PELICAN):
        local("git pull")

def bootstrap():
    """Get Pelican and install it in a virtual enviroment."""
    with settings(warn_only=True):
        _del_env()
    _make_env()
    with settings(warn_only=True):
        _clone_pelican()
    _install()

def regen():
    """Regenerate the site from source."""
    _clean()
    _gen()
    _valid_HTML()
    _local_deploy()

@hosts("my_user@" + PROD)
def publish():
    """Publish into remote web server with rsync."""
    regen()
    _browse()
    if confirm("¿Estas seguro de querer publicarlo?"):
        rsync_project(PROD_PATH, OUTPUT + "/", delete=True)

def new(title):
    """Create a new blog article."""
    local("gedit --new-window {0}/site/source/blog/{1}.md 2>/dev/null &".
          format(ROOT_PATH, title.replace(" ", "\ ")))
    local("firefox --new-window {0}/index.html &".format(OUTPUT))
    _gen(True)

def img4web(delete=True, source=""):
    """Optimize .jpg & .png images and copy them into source pictures dir."""
    local("./img4web.py -d {0} {1} {2}".
          format(os.path.join(ROOT_PATH, "site/source/pictures"),
                 "--delete" if delete else "",
                 "-s {0}".format(source) if source else ""))

Ahora, veremos el funcionamiento básico que nos permite este script. Primero vemos las tareas que tenemos disponibles:

$ fab -l
    fabfile.py: A fabric script for generate my personal blog

Available commands:

    bootstrap     Get Pelican and install it in a virtual enviroment.
    img4web       Optimize .jpg & .png images and copy them into source pict...
    new           Create a new blog article.
    publish       Publish into remote server with rsync.
    pull_pelican  Update Pelican to last revision from repository.
    regen         Regenerate the site from source.

Veamos que hacen cada una de ellas:

bootstrap Si observamos el código, veremos que lo hace es, en este orden: eliminar cualquier entorno virtual previo, crear un entorno virtual nuevo, descargar Pelican desde el repositorio (si no lo hemos hecho anteriormente) e instalar Pelican dentro de este entorno virtual. Y todo esto en un solo paso, casi todos los comandos que explicaba en Pelican - Introducción e Instalación con solo teclear fab bootstrap. Así de fácil. Con este comando podemos tanto crear una instalación de Pelican desde cero, como actualizar la instalación de Pelican después de actualizar este a la última versión con pull-pelican. Siguiendo con nuestro ejemplo, lo que haría este comando es crear los directorios env y pelican dentro de myblog.com con el entorno virtual creado y pelican instalado.
```
$ fab bootstrap
```
img4web Este comando hace uso del script que describía en Optimizar imágenes para la web para hacer precisamente eso, reducir el peso de las imágenes que empleo en los artículos. Lo que hago es a medida que voy escribiendo el articulo es ir guardando las imágenes en el directorio raíz (en nuestro ejemplo, myblog.com/) y cuando lo termino, simplemente ejecuto el comando fab img4web y este me optimiza las imágenes, me guarda las optimizadas en el directorio de imágenes del contenido (myblog.com/site/source/pictures/) y me elimina las imágenes originales del directorio raíz. Cuando termina me muestra un resumen con la cantidad de imágenes procesadas y el ahorro en espacio conseguido. Espacio en disco ahorrado que se resume en menos ancho de banda consumido y en páginas web que se cargan más rápido.
```
$ fab img4web
```
new Con este creo o edito los artículos del blog. Realiza tres funciones: me abre una venta de Gedit con el articulo que le indico con la extensión .md, me abre una ventana de Firefox que me muestra el fichero index.html del directorio del sitio generado por Pelican (myblog.com/site/output/index.html) y finalmente me activa Pelican con la opción autoreload. Luego empleando el plugin Grid de Compiz, divido la pantalla en dos mitades y coloco a la izquierda Gedit y a la derecha Firefox. Esto me permite, como explicaba en De Drupal a Pelican editar el contenido y previsualizar el resultado casi en tiempo real, disponiendo al mismo tiempo de un buen corrector ortográfico.
```
$ fab new:"Articulo de prueba"
```
publish El más importante, el que sube los artículos al servidor web. Publicar el contenido de la web es tan sencillo como ejecutar este comando. Lo que hace es regenerar el contenido (por si hubiera algún cambio sin guardar) y luego mostrarme el resultado en firefox. Pero el resultado que me muestra no es el del directorio de salida de Pelican, si no de una copia que tengo en un servidor Apache local. Esto me permite ver los cambios de manera más fiel a la versión web, puesto que hace uso del fichero .htaccess y de las reglas que tengo establecidas en él. Finalmente me pregunta si realmente deseo publicar el contenido, por si se me hubiera escapado algo. Si le digo que no, aborta la publicación, pero si le digo que si, me sincroniza el contenido de la carpeta local con la remota empleando rsync. De esta manera solo se transmiten los ficheros nuevos, se borran los que se hayan eliminado en local y solo transmite la parte que haya cambiado de los archivos modificados. Gracias a esto, modificar o añadir contenido es cuestión de segundos. Y sencillisimo.
```
$ fab publish
```
pull_pelican Nos sirve para actualizar Pelican a la última revisión disponible en el repositorio oficial. Si después de ejecutarlo, queremos instalar la nueva versión en nuestro entorno virtual para poder emplearla, simplemente tenemos que volver a ejecutar fab bootstrap y todo se realizará de forma automática.
```
$ fab pull_pelican
```
regen El proceso principal, es el que le pide a Pelican que genere el sitio web a partir de nuestro directorio de origen. También realiza varios procesos: primero eliminar el directorio de salida actual (para tener una copia fresca), genera el nuevo contenido, luego procesa los archivos para que validen en HTML5 y finalmente hace una copia del directorio de salida a mi servidor local Apache. El procesar los archivos para validar en HTML5 se debe a que markdown crea unos enlaces rel = "footnote" y rev = "footnote" en las notas al pie que se han quedado obsoletos y no son necesarios. De momento es un post-procesado, pero puede que finalmente modifique Pelican para que se haga en tiempo de generación del sitio. Aunque creo que el rendimiento de esta manera sería menor que emplear el comando sed que ejecuta este proceso, será cuestión de probarlo. También se podría modificar markdown.

Con solo 6 comandos tengo automatizadas todas las tareas básicas para administrar y crear contenido en mi blog. Ni siquiera el potente y buenísimo drush de Drupal me permitía este nivel de automatización (aunque se acercaba bastante). De esta manera solo me tengo que preocupar de crear artículos y de las posibles personalizaciones que le quiera realizar al tema del sitio. Me olvido de todo lo demás, de todo lo que conlleva un CMS. Solo hay una manera de bloguear más cómoda para los que a estos les parezca algo complejo, servicios como Tumblr. Aunque si quieres tener el control sobre tu sitio, no conozco manera más cómoda y con más ventajas que esta.

Pelican - Creación de contenido

2011-06-27T18:27:00+02:00

Crear contenido con Pelican es lo más sencillo que uno pueda imaginarse. Por ejemplo, crear este articulo, se puede hacer del siguiente modo. Abrimos un editor de textos cualquiera (por ejemplo vi o gedit) y creamos un archivo nuevo llamado Pelican, con la extensión .md si queremos emplear Markdown o .rst si queremos emplear reStructuredText. Vemos como lo haría, para este blog en concreto. Este sería el texto para crearlo en formato reStructuredText:

Pelican - Creación de contenido
###############################

:tags: Pelican, python, markdown, reStructuredText, blog, HTML.

Crear contenido con **Pelican** es lo más sencillo que uno pueda imaginarse. Por 
ejemplo, crear este articulo, se puede hacer del siguiente modo. Abrimos un 
editor de textos cualquiera (por ejemplo vi o gedit) y creamos un archivo nuevo 
llamado Pelican, con la extensión *.md* si queremos emplear Markdown o *.rst* si 
queremos emplear reStructuredText.

Y este el que usaría para crearlo en markdown, que es el que yo empleo:

title: Pelican - Creación de contenido
tags: Pelican, python, markdown, reStructuredText, blog, HTML, Piwik, Disqus.

Crear contenido con **Pelican** es lo más sencillo que uno pueda imaginarse. Por 
ejemplo, crear este articulo, se puede hacer del siguiente modo. Abrimos un 
editor de textos cualquiera (por ejemplo vi o gedit) y creamos un archivo nuevo 
llamado Pelican, con la extensión *.md* si queremos emplear Markdown o *.rst* si 
queremos emplear reStructuredText. Vemos como lo haría, para este blog en 
concreto.

Ahora solo tendríamos que guardar este fichero en la carpeta raíz de nuestro contenido y ejecutar Pelican para generar la página web resultante. Así de sencillo. Por ejemplo, creamos una carpeta prueba dentro de la estructura de ficheros que habíamos creado en el articulo anterior (myblog.com/) y guardamos allí este fichero. Ahora ejecutamos pelican dentro del entorno virtual y nos creara una carpeta output donde como resultado tendremos un blog por defecto creado como por arte de magia. Es decir, hacemos esto:

$ mkdir prueba
$ vi prueba/pelican.md
$ source  env/bin/activate
$ pelican prueba/
$ ls
env  output  pelican  prueba  site  temp
$ firefox output/index.html

y obtenemos esto:

Estructura del articulo

En el ejemplo anterior lo único que varía entre ambos formatos (aparte de la sintaxis) es la cabecera del mismo. En la cabecera se incluye el titulo del mismo (no tiene porque coincidir con el nombre del fichero) y los metadatos. El titulo en reStructuredText va subrayado con símbolos # y en markdown es un metadato más. Excepto el título, todos los metadatos son opcionales. Los metadatos en .rst van precedidos de dos puntos :. Después de los metadatos es suficiente con dejar una linea en blanco para comenzar a redactar el contenido de nuestro articulo.

Los metadatos que se pueden incorporar son los siguientes:

title (solo como metadato en markdown): Es el titulo del artículo o página.
date: Es la fecha y hora de publicación. Si no se indica, tomara como tal los valores del propio fichero de texto. El formato es el siguiente: año-mes-dia hora:minutos, es decir, %Y-%m-%d %H:%M
category: La categoría en la que queremos englobar el articulo. Si no se especifica, puede coger la categoría por defecto que se haya especificado en el fichero de configuración si así se ha establecido (por defecto es misc). Otra forma aún más simple, es crear un directorio dentro de nuestro directorio de contenido y colgar los archivos dentro de él. Todos los que se encuentren dentro de ese directorio caerán en la categoría que coincida con el nombre del mismo. Así es como yo lo hago, con un directorio llamado blog, es idoneo para organizar el contenido.

En el tema por defecto, las categorías se añaden como una entrada al menú superior que al ser seleccionada, muestra todos los artículos englobados dentro de ella.
author / authors: El autor(es) del articulo. Si se omite, escoge por defecto el que se haya establecido en el fichero de configuración. Yo lo omito, pero puede ser muy útil para blogs escritos por varios autores.
tags: Las etiquetas con las que etiquetamos a nuestro articulo. El tema por defecto solo nos permite seleccionar una y ver todos los artículos etiquetados de igual modo, pero es bastante sencillo crear una nube de etiquetas como la que empleo en este blog.
summary: Es el resumen que queremos que se vea del articulo cuando se emplea la paginación. Por defecto, si no se especifica este campo, los artículos se resumen con las primeras 50 palabras del mismo.
slug: Esta es uno de los campos más curiosos, pero al mismo tiempo más geniales. Este campo es el nexo que nos permite enlazar varias versiones del mismo articulo en distintos idiomas. En el tema por defecto, nos muestra las distintas traducciones de un articulo, si es que existen.
status: Esta es un campo especial que solo admite dos valores, draft (borrador) y published (publicado). Cualquier otro valor es ignorado. Si el valor es draft, el articulo o pagina no aparece publicado ni referenciado de algún modo al generar el contenido, y solo está disponible si accedemos a él a través del directorio drafts/. Esto es una ayuda para evitar que por un descuido subamos a la web un articulo sin terminar. Yo no lo empleo, ya veremos cuando hable de le automatización, como he resuelto este posible problema de otro modo. Si lo empleamos, deberíamos añadir el directorio drafts/ a nuestro fichero robots.txt como Disallow para que no fuera indexado por los buscadores (de poco importaría ocultar el el borrador si lo haces accesible a través del buscador).

Para comprender el resto de opciones disponibles para crear el contenido, voy a centrarme en el sitio de ejemplo que viene por defecto con Pelican. Empezaremos eliminando las pruebas que acabamos de realizar.

$ rm -r output/
$ rm -r prueba/
$ ls
env  pelican  site

Estructura del contenido del ejemplo

Ahora, en el directorio de contenido del sitio de ejemplo, tenemos la siguiente estructura de ficheros:

$ cd site/
$ tree source/
source/
├── another_super_article-fr.rst
├── another_super_article.rst
├── cat1
│   ├── article1.rst
│   ├── article2.rst
│   ├── article3.rst
│   └── markdown-article.md
├── draft_article.rst
├── extra
│   └── robots.txt
├── pages
│   └── test_page.rst
├── pictures
│   ├── Fat_Cat.jpg
│   ├── Sushi.jpg
│   └── Sushi_Macro.jpg
├── super_article.rst
├── unbelievable.rst
└── unwanted_file

Donde:

another_super_article-fr.rst y another_super_article.rst son dos versiones del mismo articulo en inglés y francés. Aunque cuelgan del directorio raíz, ambos están englobados dentro del sitio en la categoría bar a través del metadato category y enlazados traducciones mediante el metadato slug :slug: oh-yeah
draft_article.rst es un articulo que no aparece publicado en el sitio de ejemplo al estar marcado como borrador con el metadato status, pero al que podemos acceder igualmente a través de myblog.com/site/source/drafts/a-draft-article.html
super_article.rst y unbelievable.rst son ejemplos de uso de metadados. El primero es un articulo que cuelga de la categoría yeah y que sirve como ejemplo del empleo de summary y del uso de imágenes y código. El segundo es un ejemplo de articulo sin más metadatos que la fecha del mismo y de como cae en la categoría misc por defecto.
unwanted_file es un articulo que no se procesa de ningún modo por carecer de extensión que lo identifique como markdown o reStructuredText. Como consecuencia este fichero ni siquiera se copia al sitio web generado. Puede ser un truco útil para emplearlo como fichero de notas personales de cualquier tipo, por ejemplo un recordatorio de como hemos definido la estructura de archivos, una chuleta como usar marcado o reStructuredText, artículos pendientes, ...
cat1 Este directorio es un ejemplo de como todos los artículos que cuelgan de él son englobados dentro de la categoría cat1 de forma automática. Esto nos evita escribir el metadato category en cada uno de ellos y nos ayuda a clasificarlos en el directorio. Y nos muestra como se pueden mezclar archivos markdown y reStructuredText sin ningún tipo de problemas.
extra En esta carpeta (puede ser otra, es configurable) englobamos archivos que queremos incluir en el sitio, pero que no han de ser procesados. Como por ejemplo: .htaccess, .robots.txt, .humans.txt, ... Esto puede cambiarse en el fichero de configuración, especificando el origen dentro del directorio de nuestro contenido y la ruta en la que queremos que esté en el sitio web. En este caso, sería así en el fichero de configuración pelican.conf.py
```
FILES_TO_COPY = (('extra/robots.txt', 'robots.txt'),)
```
pages Serían las páginas estáticas del sitio, lo que no son artículos. Este nombre de directorio está reservado para esta función por defecto. Por ejemplo la página markdown que empleo en este blog, sería una de estas páginas estáticas. En estas páginas no están disponibles los comentarios. Si se especifica en el fichero de configuración, estas páginas aparecerán como entradas en el menú principal del tema por defecto.
pictures Este es uno de los directorios que se pueden emplear para albergar contenido estático como son las imágenes. Esto es configurable en el fichero de configuración. En este caso lo que se guardan en el son las imágenes empleadas en los artículos. Estas acabaran dentro del directorio static/pictures/ de nuestro sitio.

Y ya está, es una estructura muy sencilla y que genera un resultado bastante decente, comparado con los cientos de archivos que emplea (a parte de la BDD) cualquier CMS como Wordpress o Drupal.

Si partiéramos de un blog ya creado, Pelican proporciona una herramienta, que en nuestro caso estaría en /myblog.com/pelican/tools/importer.py y que nos permite importar artículos desde Wordpress o desde un fichero RSS y que nos genera los contenidos en reStructuredText. Si quisiéramos emplear markdown, existe una herramienta externa, html2markdown que nos permite obtener un texto en markdown desde una página web. Otra herramienta similar a esta última sería html2text.

No tiene más secreto que este, crear ficheros de texto plano en formato .md o .rst, guardarlos en el directorio que empleamos para albergar el contenido y generar el blog.

Pelican - Introducción e Instalación

2011-06-27T10:21:00+02:00

Pelican es un generador de sitios web con contenido estático. Está orientado originalmente a la creación de blogs. Pelican (Pelicano) es una anagrama de la palabra francesa Calepin que significa en español "cuaderno de notas" (blog). Su creador y desarrollador principal es el programador francés Alexis Métaireau. Y es la aplicación que genera el contenido para este blog. Personalmente le veo muchas ventajas frente a una plataforma de blogs convencional como Wordpress o Drupal, como ya comentaba en mi anterior articulo.

Pelican genera este contenido estático (páginas HTML) a partir de ficheros de texto plano formateados en un lenguaje de marcado ligero como Markdown o reStructuredText. También crea fuentes RSS y Atom de los artículos. Y dependiendo del tema empleado se pueden tener un archivo de los artículos publicados, clasificación por categorías, nube de etiquetas, un blogroll, enlaces a redes sociales, botón para tweeter, paginación, traducciones, etc. Aunque viene un tema completo por defecto y están disponibles algunos más, se puede crear uno completamente personalizado desde cero. La creación de estos temas se basa en el sistema de plantillas jinja2, lo que nos permite una gran flexibilidad. También disponemos de varios scripts que nos proporcionan soporte para comentarios con Disqus y de analíticas con Google Analytics ó Piwik. También nos permite generar ficheros PDFs de los artículos automáticamente y mostrar los enlaces a ellos, siempre que los artículos se hayan creado con reStructuredText.

Es un software muy joven, el primer commit en GitHub data del 13 de Agosto de 2010, pero que ha evolucionado bastante rápido y que aún sigue desarrollándose a un buen ritmo. Es posible que por esto aún tenga alguna carencia o algún que otro fallo, pero su autor es muy receptivo y acepta de buena gana las sugerencias, informes de errores y colaboraciones de desarrollo. Cuenta con una documentación bastante decente y actualizada. Alguno que otra cosa no está documentada, pero lo veo normal dado el ritmo de desarrollo y de a quien va orientado un software como este. Es muy sencilla su instalación y su utilización cuando se ha leído esta, pero será mejor que lo explique con un ejemplo sobre la marcha.

Instalación (para Linux)

La instalación del mismo es relativamente sencilla si no queremos complicarnos la vida, siempre tenemos la última versión disponible en el PyPi. Así que instalarlo podría ser tan sencillo como esto:

$ easy_install pelican

Aunque recomiendo emplear pip en lugar de easy_install, de este modo:

$ pip install pelican

De todos modos desaconsejo emplear este método, me parece mejor solución, dada la velocidad de desarrollo del software, emplear un entorno virtual para su instalación. Un entorno virtual nos permite tener una versión de Python independiente de la del resto del sistema, con sus propias librerías y con el software instalado que nosotros deseemos. Todo esto solo estará disponible cuando nos encontremos dentro de este entorno virtual, sin afectar al resto del sistema. Y podemos eliminarlo o des/activarlo cuando deseemos. Es bastante más sencillo de utilizar de lo que parece y es realmente potente.

Veamos, paso a paso, la forma en que yo lo instalaría.

Creamos una carpeta que contendrá Pelican, el entorno virtual y el sitio que crearemos. Yo le daría el nombre de la URL del blog, por ejemplo, myblog.com

$ mdkir myblog.com
$ cd myblog.com

Descargamos la revisión actual del repositorio de Pelican en GitHub. Esto nos creara una carpeta llamada pelican que contendrá una copia del repositorio en local (lo cual nos será muy útil en el futuro para actualizarlo).

$ git clone git://github.com/ametaireau/pelican.git
Cloning into pelican...
remote: Counting objects: 2603, done.
remote: Compressing objects: 100% (1143/1143), done.
remote: Total 2603 (delta 1541), reused 2420 (delta 1374)
Receiving objects: 100% (2603/2603), 687.30 KiB | 397 KiB/s, done.
Resolving deltas: 100% (1541/1541), done.

Ahora vamos a crear nuestro entorno virtual. En caso de no tener instalado pip o virtualenv, es rematadamente sencillo:

$ easy_install pip
$ pip install virtualenv

Voy a llamar env a nuestro entorno virtual. Lo creamos así.

$ virtualenv env
New python executable in env/bin/python
Installing distribute...........................................................
................................................................................
.......................................done.
$ ls
env  pelican

Ahora activaremos nuestro entorno virtual para "sumergirnos" dentro de él.

$ source env/bin/activate
(env)$

Vemos que aparece el nombre del entorno virtual entre paréntesis antes de la línea del prompt. Eso quiere decir que nos encontramos dentro de este entorno virtual. Ahora procederemos a instalar Pelican.

$ cd pelican/
$ python setup.py install

Ahora tenemos ya instalado Pelican, solo dentro de nuestro entorno virtual. Si probamos a llamar al programa fuera de él, veremos que no está disponible, luego necesitaremos activar este entorno cada vez que queramos emplearlo.

$ pelican
CRITICAL: you need to specify a path containing the content (see pelican --help for 
more information)

Nos da un error porque no le hemos pasado los parámetros necesarios. Ahora desactivamos el entorno y volvemos a llamar al programa y nos dice que no existe.

$ deactivate
$ pelican
pelican: orden no encontrada

Tenemos ahora dentro de myblog.com/ dos directorios, env y pelican. Podríamos borrar ahora el directorio pelican porque ya lo tenemos instalado dentro del entorno virtual, pero sería bueno conservarlo para poder actualizarlo en el futuro mediante git pull. Yo crearía una tercer directorio, site donde se alojaría nuestro sitio, organizado a su vez en tres subdirectorios:

source: sería la carpeta donde alojaríamos los archivos de texto de nuestro blog y todo aquello que quisiéramos que formara parte de nuestro sitio: imágenes, fichero .htacess, fichero robots.txt, páginas personalizadas...
output: El resultado del procesamiento de Pelican, es decir, nuestro blog.
theme : Sería el tema que usariamos para crear nuestro blog, en el estarían las plantillas jinja2, las hojas de estilo .css, el contenido estático (iconos, imágenes), ...

Luego, lo haríamos así:

$ cd ..
$ mkdir -p site/source
$ mkdir site/output
$ mkdir site/theme
$ ls site/
output  source  theme

Ya está, tenemos instalado Pelican y creada nuestra estructura para empezar a trabajar con él. Para eso nada mejor que crear un primer sitio de ejemplo. Entramos en el entorno virtual y creamos el sitio que viene de ejemplo con Pelican:

$ source env/bin/activate
$ pelican pelican/samples/content/ -o site/output -s pelican/samples/pelican.conf.py

Y ahora si abrimos el fichero myblog.com/site/output/index.html en un navegador, veremos algo como esto (en la imagen se ve la categoría cat1 seleccionada):

Es así de fácil de emplear Pelican, simplemente especificarle el directorio donde está el origen del contenido, el directorio destino y el fichero de configuración. Aunque con el fichero de configuración correctamente creado, solo será necesario indicarle la ubicación del mismo. Para comprender mejor la estructura y como funciona Pelican, sería buena idea copiar el tema, el fichero de configuración y el contenido que han generado este sitio de ejemplo a la carpeta site para no empezar nuestro blog desde cero.

$ cp -r pelican/samples/content/* site/source
$ cp -r pelican/pelican/themes/notmyidea/* site/theme/
$ cp pelican/samples/pelican.conf.py site/

En próximos artículos veremos como crear artículos, publicar el sitio, personalizar el tema y automatizar todos estos procesos para hacerlo todo mucho más sencillo.

De Drupal a Pelican

2011-06-22T02:10:00+02:00

Este blog no está realizado con ningún CMS, ni siquiera utiliza BDD alguna, es simplemente HTML + CSS y nada más. Es decir, es contenido estático, no dinámico. Hasta hace 3 días estaba funcionando con el mejor CMS PHP que conozco, Drupal. Pero persiguiendo el camino hacia el minimalismo y la productividad (fiel al espíritu KISS) que ya inicie cuando comencé a escribir todos mis artículos en Drupal con Markdown, el siguiente paso era evidente. La pregunta era muy sencilla, si un blog consta de contenidos que rara vez cambian (exceptuando los comentarios) ¿para que necesito un gestor de contenidos dinámicos?

La respuesta es fácil, para nada. Actualmente, gracias a servicios como los de Disqus, Livefyre, IntenseDebate ó Echo es posible externalizar el único contenido dinámico básico de un blog, los comentarios. Todo lo demás puede ser contenido puramente estático, solo HTML y CSS, sin renunciar a prácticamente nada de lo que nos ofrece un blog basado en un CMS como Wordpress o Drupal. Se pueden emplear scripts externos en javascript si se desea, o insertarlos dentro del HTML. Lo que nos permite implementar lo mismo que en un blog normal. Además se puede disponer también de feeds RSS y Atom.

Elegir un generador de contenido estático

Evidentemente la idea no es crear las paginas HTML a mano, ni de broma, lo lógico era seguir empleando la misma estrategia que ya había iniciado con Drupal, emplear solo ficheros de texto en formato Markdown que nos generarán el HTML necesario de forma automática. Entonces lo que tenía que encontrar era un software que me permitiera hacer lo mismo que Drupal, pero sin toda la parafernalia que rodea a un CMS. Un generador de sitios web estáticos (a partir de markdown) y que a ser posible estuviera escrito en Python, mi lenguaje favorito. Como ya adelante en el artículo sobre Markdown, existen varias opciones:

Pelican de Alexis Métaireau, que emplea en su propio blog
Blogofile de Ryan McGuire que también lo usa en su blog
Hyde de Lakshmi Vyas. Su blog con Hyde también.
rstblog de Armin Ronacher. Solo permite reStructuredText, con él crea su blog, un ejemplo de elegancia y calidad.

Bueno, tenía varias posibilidades, solo tenía que elegir una que se adaptara mejor a mis necesidades. De entrada descarté rstblog porque no permitía el empleo de markdown, cuando los otros permitían tanto .rst como .md como formatos de entrada. Solo me quedaban 3 candidatos. Así que lo primero que hice antes de nada, fue buscar blogs creados con cada uno de ellos, para ver que posibilidades reales ofrecían. Encontré ejemplos de blogs de mucha calidad de todos ellos. Aunque enseguida me di cuenta de una cosa, en dos de ellos los mejores blogs lo eran porque tenían una elevada personalización detrás (artículos de sus autores contándolo). Y curiosamente con el tercero, casi todos preferían quedarse con la configuración estándar, sin tocar prácticamente nada, y la verdad es que el resultado era bastante decente. Luego miré que cargaba cada uno de ellos en la página de entrada, y volvía a repetirse la misma tendencia. En los dos primeros vi demasiadas hojas de estilo, imágenes y demasiados scripts javascript, en el tercero, nuevamente se cargaban menos elementos. Finalmente comparé características, modo de funcionamiento y le eché un vistazo rápido al código. La impresión era otra vez la misma, dos de ellos, Hyde y Blogofile aunque aparentemente potentes, los veía innecesariamente complejos, en cambió Pelican era bastante más sencillo. Otra forma de determinar su repercusión era contar el número de descargas de cada una de las aplicaciones desde PyPi. Los números son los siguientes (a 27 de Junio de 2011), obtenidos con Vanity o pythonpackages.com:

Paquete	Descargas	Descargas (2-12-2011)	Descargas (7-4-2012)
Blogofile	2.419	3.854	5.276
Hyde	1.945	4.518	7.644
Pelican	3.919	6.138	10.126

La elección final era Pelican y no me arrepiento en absoluto, la prueba es que esté blog está funcionando gracias a él (Gracias Alexis!). Aunque las otras dos son también muy buenas opciones, y seguramente serían la primera opción para más de uno. Y siempre podría cambiar fácilmente, porque el contenido seguiría estando guardado en ficheros de texto con marcado markdown.

Actualización (2-12-2011):

La estructura de Pelican es tan sencilla y eficaz, que Jökull Sólberg ha creado a partir de una versión hospedada del mismo (y modificada) una de las plataformas de blogs más simples de utilizar que existen, calepin.co. Publicar articulos es tán fácil como crear un archivo markdown y guardarlo en tu cuenta de Dropbox. Así de sencillo.

No entraré en detalles ahora de como instalar y emplear Pelican, eso lo dejo para otro próximo articulo, Pelican. Pero si voy a hacer un repaso de los pros y los contras de emplear Pelican frente a un CMS como Drupal para crear un blog.

Ventajas de Pelican vs CMS

Solo ficheros de texto, No BDD

Simplemente te tienes que preocupar de eso, ficheros de texto, es donde guardas el contenido que creas. Todo lo demás lo genera Pelican por ti. Nada de crear y gestiónar bases de datos, ni copias de seguridad de la misma y un montón de espacio y recursos desaprovechado solamente para generar dinámicamente el mismo contenido que te genera Pelican.

Mejor rendimiento, carga de página más rápida

Generar contenido dinámico es más caro en recursos y es más lento (consultas a la BDD). Sobre todo a medida que llenas tu CMS de personalizaciones y plugins. ¿Que hacen prácticamente todos los sistemas de caché?, generar contenido estático para luego servirlo más rápidamente. ¿No es un poco estúpido crear contenido que apenas cambia en el tiempo, en un sistema dinámico que genera ese contenido cada vez y que para mejorar su rendimiento lo convierte en estático? Y ya no hablemos de las múltiples hojas CSS, scripts javascript y enlaces a contenido externo que cargan la mayoría de los CMS por defecto. Cada plugin que añadimos pone su granito de arena y optimizar todo esto requiere dedicación y esfuerzo (o seguir sumando aún más plugins en el mejor de los casos). Con Pelican ya tienes directamente el contenido estático y menos recursos que descargar. En este blog, sin contar con los ficheros javascript de Disqus y Piwik, lo único que se descarga es un fichero HTML, una hoja CSS y las imágenes que se incluyen en los artículos (cuando las hay). Es decir sirves el mismo contenido pero generando menos tráfico desde tu servidor.

Soporta mejor el tráfico

Cuando un sitio web soporta mucho tráfico, emplear un CMS requiere de mucha optimización y generalmente de mucha maquina o complejas instalaciones. Y la base principal siempre es un sistema de caché que sirva contenido lo más estático posible. Se cachea todo lo que se puede, y si es en memoria mejor. Las BDD son un problema aparte, desde soluciones NoSQL a clusters o BDD distribuidas. Con contenido estático no te tienes que preocupar de optimizar los accesos a la BDD, solo de tener un buen servidor web y si quieres, cachear en memoria o ampliar máquina. Pero poco más.

Seguridad

Olvídate de problemas de seguridad, los únicos agujeros de seguridad de un sitio con contenido estático están del lado del servidor web, de todo lo demás, te olvidas. Establece bien los permisos en el sistema de ficheros y punto. El único contenido dinámico del sitio (javascript) ni siquiera es algo que deba preocuparte, es algo externo que le concierne a Disqus o al sistema de analíticas web que elijas (Google Analytics o Piwik).

Olvidarse de gestionar un CMS. Mantenimiento mucho más sencillo (nulo)

Instalar el CMS, crear la BDD, encontrar, instalar y probar los plugins que necesitas, actualizaciones, actualizaciones de seguridad, personalizaciones, temas... Todo lo que rodea a cualquier CMS. Y ya no digamos si hablamos de un CMS potente y complejo como Drupal, con cientos de posibilidades. Y sin olvidar toda la basura que se va acumulando en las BDD tras varias actualizaciones y múltiples pruebas de plugins, con Pelican siempre tienes un sistema limpio. Todo eso lo olvidas con Pelican, lo instalas, personalizas y automatizas una sola vez, luego te olvidas de todo lo que no sea escribir (si quieres, nada te impide seguir cambiándolo y mejorándolo). Emplea tú tiempo en crear contenido.

Backups más sencillos

Con un CMS deberías hacer Backups del servidor web tanto del sistema de ficheros como de la BDD. Y sería aconsejable tener un servidor web local montado para probar los cambios que vayas a hacer en el CMS sin miedo a romper nada. Con Pelican ni siquiera necesitas hacer Backups del servidor ni del contenido web. Todo lo que necesitas para generarlo ya está en tu ordenador en esos ficheros de texto. Incluso si empleas un tema propio, también está en tu equipo. Así que las copias de seguridad de tu sitio web no son distintas a las que regularmente ya haces de tu ordenador personal.

Hosting en cualquier sitio

Solo tienes que alojar contenido estático, no necesitas BDD ni soporte para ningún lenguaje o librería en particular. Puedes hasta utilizar recursos gratuitos como las páginas de GitHub o BitBucket o un sistema de ficheros en la nube económico como Amazon S3 (o Amazon CloudFront). Solo necesitas eso, servir ficheros, nada más. Hasta el hosting más económico te sirve.

Emplear un CVS para gestionarlo

Poder emplear Git o Mercurial o cualquier otro CVS para gestionar los cambios del blog no tiene precio. Ningún sistema de revisiones de CMS es tan potente. Además tienes la posibilidad de crear un hook para que al enviar un commit después de crear un articulo (o realizar un cambio) se suba el contenido automáticamente al servidor. Con esto realizar cualquier cambio o revertir un error es algo trivial. Además te permite subir una copia a un sitio como GitHub o BitBucket y tenerlo siempre disponible en cualquier sitio con conexión a la red. Como maravillosa opción, esto permite que el contenido de un blog, incluso de un mismo articulo, sea editado por más de una persona de manera bastante más sencilla, potente y menos propensa a errores que con un CMS.

Crear los articulos off-line

Eso te permite ir creando los artículos al ritmo que te de la gana, cuando quieras y en cualquier sitio con un portátil. No necesitas estar conectado a la red. Esto también puede hacerse con un CMS, pero suele ser más complejo (exceptuando emplear cortar y pegar) e inseguro (si se habilita el envío remoto de artículos). Yo lo había logrado en Drupal empleando markdown, pero seguía necesitando un segundo paso on-line para personalizar las etiquetas.

Edición de artículos más cómoda

Puede parecer que un CMS con su editor WYSIWYG es más cómodo, pero todo lo contrario. Ya lo comentaba en el artículo sobre markdown. Pero es que además me proporciona una mejor experiencia de edición y más potente. Explico como redacto yo los artículos para que se entienda mejor. Divido la pantalla en dos mitades, a la izquierda el editor de textos y a la derecha el navegador. Como editor de textos empleo Gedit, que tiene resaltado de texto para markdown y un corrector ortográfico (por esto no uso vim para esto) bastante mejor que el de Firefox (que solo examina el texto hasta cierto número de casos dudosos). Además Pelican tiene una maravillosa opción, autoreload que lo hace correr en segundo plano y cuando detecta un cambio en uno de los ficheros, vuelve a generar el contenido. Entonces en gedit le digo que autoguarde el contenido cada 3 minutos (o a voluntad, manualmente) y cuando Pelican lo detecta, automáticamente regenera los ficheros HTML. Como navegador empleo Firefox y tengo, abierto en una pestaña, el fichero index.html que genera Pelican y empleando la extensión Auto Reload el contenido de la página (en local) se actualiza automáticamente al detectar un cambio en el fichero. Es decir, como en la primera página se puede ver el contenido completo del último articulo, lo que estoy viendo es una previsualización automática del contenido en la página cada 3 minutos. Y todo esto en off-line, sin estar conectado a internet. Esto si es un verdadero editor WYSIWYG, y no los otros. Además, que demonios, los navegadores no se diseñaron para crear texto, cualquier editor de texto es más potente.

Control del Spam

El Spam, esa lacra que azota toda la web. En Pelican, ese problema, lo tiene que gestionar Disqus, no tú. Tú solo tienes que gestionar el poco que se le escape. Pero el buscar un plugin, configurarlo y que funcione bien, es algo de lo que no tienes que preocuparte. En Drupal tenía este asunto solucionado, pero fue cosa de probar varios plugins, hasta que al final di con uno que me lo solucionaba de verdad.

Recursos de CPU y RAM

El contenido dinámico consume mucha más memoria RAM y CPU en el servidor que servir contenido estático. Al fin y al cabo, en el caso del contenido estático, es poco más complejo que servir ficheros. Si tienes que compartir el servidor con más proyectos, agradecerás no tener que emplear un CMS para servir el blog.

Resaltado de Sintaxis incorporada con Pygments

Mientras en la mayoría de CMS necesitas un plugin para habilitar el resaltado de sintaxis para código fuente, en Pelican esto viene por defecto empleando el excelente Pygments

Cumplimiento de Estándares Web

Con Pelican es relativamente sencillo configurar el tema para que cumpla los estándares web y genere contenido valido. Y una vez que lo haces, es para siempre, a no ser que modifiques algo en el tema, todo el contenido que generes cumplirá con los estándares (a no ser que incluyas HTML dentro que no lo sea). De este modo, este sitio valida HTML5, CSS3 y genera feeds RSS y Atom validos. Conseguir esto con un CMS y empleando editores WYSIWYG es bastante más complejo y doloroso. Aunque yo lo había conseguido con Drupal y markdown, tuve que modificar un tema casi por completo, casi como crearlo desde cero.

Inconvenientes de Pelican vs CMS

Comentarios sin resaltado de sintaxis

Algo que me permitía Drupal y no me permite Disqus (por ahora) era emplear markdown en los comentarios y resaltado de sintaxis para el código fuente. Es el mayor inconveniente que he encontrado hasta ahora. Pero bueno, tampoco es algo imprescindible y esperemos que Disqus lo soporte en un futuro.

Sitemap

Tampoco Pelican genera sitemaps en xml para los buscadores. Aunque tampoco es algo imprescindible y Drupal tampoco lo soporta por defecto, si no a través de un módulo. El autor lo tiene como tarea pendiente, y si tarda mucho, a lo mejor me animo y lo creo yo mismo.

Personalización más sencilla para non geeks

Esta es la parte que menos me afecta, pero es el gran inconveniente para la gran mayoría sin conocimientos avanzados. Aunque Pelican no es difícil de instalar y configurar, si queremos personalizarlo bastante, la cosa cambia. Los CMS son mucho más sencillos en ese sentido, pero el coste a pagar por otro lado no me compensa.

No tiene búsqueda incorporada

Es otro pequeño inconveniente que puede suplirse empleando la de Google AdSense en el sitio, por ejemplo. Personalmente no me importa demasiado, teniendo disponibles en el sitio recursos como el archivo de todos los artículos publicados o la nube de etiquetas.

No puedes personalizar el contenido dinámicamente

Con un CMS puedes hacer cosas como mostrar un contenido o un tema distinto según el perfil del usuario, o según la carga del servidor, etc. Con contenido estático lógicamente no puedes hacer esto. A mi me da igual, no lo necesito, es solo un blog.

Llevo varios años empleando Drupal en varios sitios y me sigue pareciendo un CMS excelente y una buenísima opción para generar contenido dinámico para no desarrollladores (de otro modo prefiero un framework como Django). Pero actualmente, para crear blogs, si se tienen conocimientos suficientes, emplear un CMS me parece una decisión poco acertada, es matar moscas a cañonazos. Hoy en día hay soluciones como Pelican y las mencionadas arriba (y otras alternativas en otros lenguajes) que te permiten crear blogs con facilidad, centrándote únicamente en crear los artículos y automatizar todo lo demás. ¿Acaso esa no es la razón principal del grandisimo éxito de twitter o tumblr? La inmediatez de los resultados y la delegación de la gestión a terceros, tú solo escribes. Pelican te permite lo mismo, solo requiere la personalización inicial y listo, con la ventaja añadida de que puedes personalizarlo a tu gusto y hasta donde te dé la gana o seas capaz.