joe di castro

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.

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.

Markdown, la mejor opción para crear contenidos web

2011-04-02T20:29:00+02:00

Normalmente cuando se crea contenido en un blog o CMS, como Wordpress, Blogger, Drupal, Joomla, Plone, Typo, etc, se hace a través de un editor visual (WYSIWYG). Algunos editores de este tipo son TinyMCE, CKeditor, NicEdit, WYMEditor, markItUP!, openWYSIWYG, etc.

Yo mismo he empleado varios de ellos durante años, en varias plataformas como Blogger, Wordpress, Joomla, Drupal, etc. Y si, hay que reconocerlo, te hacen la vida muy fácil, sobre todo para aquellos que no quieran preocuparse más que de añadir contenido en su página. E incluso usuarios más avanzados como administradores o diseñadores web, lo suelen emplear por comodidad frente a un área de texto plano. Y si, es cómodo, muy cómodo, a corto plazo. A largo plazo... a largo plazo es cuando empiezas a verle los peros y los problemas, que los tienen, y bastantes. Veamos cuales son esos problemas y la alternativa, que para mi personalmente, es la solución.

Los problemas de los editores WYSIWYG

Los editores visuales están pensados para que de una forma muy fácil, se pueda editar el contenido de forma visualmente atractiva, sin tenerse que andar preocupando del HTML que se genera a partir de él, esto es, no es necesario conocer nada de HTML para usar un editor WYSIWYG. Puedes añadir negritas, cursivas, alinear el texto, cambiar el tamaño, el color, crear tablas, etc, sin conocimiento alguno de HTML o CSS. Se supone que el editor genera HTML valido correctamente por ti. Y aquí es donde empiezan los problemas:

Los editores visuales generalmente crean el formato con CSS embebido dentro del HTMl, es decir mezclando el contenido y el estilo de la página. Algunos incluso te permiten incluir tus propias hojas de estilo para que el contenido se ajuste al estilo actual de tu web.

¿Pero que ocurre cuando al cabo de un tiempo, con decenas o más de artículos generados quieres cambiar el estilo de tú página? Pues dependiendo de como haya realizado el trabajo tu editor WYSIWYG, te puedes encontrar con el desagradable problema de que todo queda desencajado o no se ajusta al estilo actual. Yo me he tenido que enfrentar con este problema en el pasado al actualizar una versión de Drupal y cambiar completamente el tema, y no fue nada cómodo de solucionar, o al importar contenido de un CMS a otro.
Los editores visuales se crearon inicialmente para impresión en papel, no para HTML. Y HTML se emplea en multitud de dispositivos (desde móviles hasta ereaders) y bien empleado proporciona una flexibilidad que se rompe al mezclar la estructura del documento (HTML) con el estilo del mismo (CSS) en el mismo archivo. Así que a la hora de crear versiones para dispositivos móviles, con todas esas etiquetas CSS embebidas, puede ser un verdadero quebradero de cabeza.
Se supone que tienen que generar HTML válido, pero durante mucho tiempo esto no ha sido siempre así, sobre todo si el editor no está bien configurado o tiene algún plug-in que no respeta este tema. Además, generan HTML valido ahora, ¿que pasa en el futuro? Es decir, si quieres pasar contenido antiguo para por ejemplo pasar de HTML 2.0 a HTML 4.0 o incluso 5 y eliminar etiquetas obsoletas y generar HTML que cumpla con el estándar, prepárate, porque te espera una ardua tarea. Por no decir que muchos de estos editores tienen errores en su propio código javascript, lo que lleva a frecuentes actualizaciones de los mismos.
Pueden generar cantidades absurdas de HTML, sobre todo si no están correctamente configurados. Algunos editores (a veces con la configuración por defecto hacen esto, y tienes que ser tú quien lo ajuste para que no ocurra) crean toneladas de <div>,<p> y <span> sin sentido y totalmente superfluos. Cuando no emplean tablas para formatear algunas presentaciones complejas. Y ni que decir tiene de aquellos editores visuales que te dejan pegar contenido desde un procesador de textos como Word, el HTML generado en estos casos, bueno, hay que verlo para creerlo, un absoluto despropósito.
Es incluso factible que un usuario inexperto pueda romper el diseño de una página a través de un editor WYSIWYG, creando párrafos o <div> de forma inadecuada. Incluso al reescribir un texto es posible que se mezclen estilos CSS embebidos antiguos con nuevos, generando unos embrollos inmensos a nivel de HTML. Y ya no digo nada de los que rompen el estilo visual de un tema abusando de colores en las fuentes, tamaños, etc
El contenido que se guarda en la base de datos esta mezclado con las etiquetas HTML y CSS, todo junto, vamos que no se parece en nada a lo que has introducido en tu editor. Todo esto en principio carece de importancia, pero puede suponer hasta el 20% del tamaño de las páginas de tu sitio, espacio absurdamente desperdiciado en tu BDD. De hecho el contenido XHTML se genera por lo normal cada vez que se visualiza la página de forma dinámica. Si te preocupa el rendimiento, tranquilo, los sistemas de cache están ahí para echarte una mano y que te dejes de preocupar por eso.
Distraen la atención, el problema de absolutamente todos los editores visuales, incluidos procesadores de texto, el centrarse en el formato y no en el contenido. Una gran mayoría de usuarios desperdicia un tiempo notable preocupándose por más el aspecto visual del documento, que por el contenido del mismo. Que si esto en negrita, que si mejor con esta fuente, que si mejor con la otra... Se desvía la atención de lo importante, el contenido. Mal amigo de la productividad, se tarda bastante más en general, por esta razón, en generar el mismo contenido en un editor WYSIWYG.
Son bastante poco flexibles, si quieres introducir tu propio HTMl en el contenido (e.g. para tener un control más fino sobre las tablas, yo lo hago en este articulo) puede que te encuentres que lo genera como lo tiene preestablecido, eliminado la estructura que tu quieras darle. Y embeber contenido multimedia o scripts también es frecuentemente un problema, siendo hasta habitual que existan plugins para estos editores para insertar contenidos de sitios como YouTube.
Todos los editores WYSIWYG aumentan el peso por página y disminuyen la velocidad de carga, al necesitar pesado código javascipt que necesita tanto ser descargado como ejecutado por tu navegador. Ya de por si los CMS suelen emplear bastante código javascript, como para encima añadirle un editor visual. Además realizan bastantes llamadas HTTP, ralentizando aún más la velocidad de carga. Ejemplo: tienes un articulo de 80 lineas de texto cuyo contenido XHTML puede pesar tranquilamente de 10 á 20 veces menos que el javascript del editor, ¿no es un poco ridículo?. Aunque muy pocos editores web se preocupan de esto, la verdad, es que hay que pensar que no todo el mundo disfruta de buenas conexiones a la red.
Por último y no menos importante, no cuidan la accesibilidad. El HTML valido que cumpla con los estándares, es esencial para crear páginas con una buena accesibilidad, pensando en aquellos que no lo tienen tan fácil para navegar por nuestros sitios web. Deberían tenerse al menos en cuenta un mínimo de puntos sobre este tema al crear contenidos en la web.

En conclusión, que los editores WYSIWYG pueden no dar problemas hasta que tus necesidades cambian, entonces pueden darte más de un quebradero de cabeza.

Texto plano y Markdown

¿Cual sería entonces la solución para esquivar estos problemas? Texto plano, nada más, que se transforme automáticamente en HTML valido respetando el formato que nosotros queramos darle. Esto existe, y es posible gracias a los lenguajes de marcado ligero, entre los que se encuentra Markdown. Nada mejor que empezar demostrándolo con un ejemplo:

Markdown

Resultado

Documento de ejemplo
====================
Lorem ipsum [dolor sit amet](#mark), consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum **semper adipiscing leo** et blandit.
Sed nibh quam, hendrerit _sit amet aliquam_ vel, pulvinar molestie augue.
> Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.
Lista numerada (ordenada)
1. Este es el primer elemento
2. Este es el segundo elemento
   * Una lista de puntos anidada
   * Se llama también desordenada
     * Tercer nivel de anidamiento
3. Este es el tercer elemento
![avatar](pictures/avatar.png)
### Cabecera ###
- - -
Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

|   | solo texto | HTML Limpio  |
| -------------- | -- | ------- |
| Markdown       | Si | Si      |
| Editor WYSISWG | X  | A veces |

    :::python
    import lifetime
    
    for each_day in lifetime.days():
        carpe_diem()
Suspendisse posuere velit et velit vehicula at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.
Esto es un texto con nota al pie [^prima] y esta es otra nota [^secunda]

 *[vehicula]: automobila
[^prima]: Esto es una nota al pie.
[^secunda]: Esto es la segunda nota.

Documento de ejemplo

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum semper adipiscing leo et blandit.

Sed nibh quam, hendrerit sit amet aliquam vel, pulvinar molestie augue.

Lista numerada (ordenada)

Este es el primer elemento
Este es el segundo elemento
- Una lista de puntos anidada
- Se llama también desordenada
  - Tercer nivel de anidamiento
Este es el tercer elemento

Cabecera

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

	solo texto	HTML Limpio
Markdown	Si	Si
Editor WYSISWG	X	A veces

import lifetime

for each_day in lifetime.days():
    carpe_diem()

Suspendisse posuere velit et velit vehicula at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

Esto es un texto con nota al pie ¹ y esta es otra nota ²

Esto es una nota al pie. ↩
Esto es la segunda nota. ↩

Es así de sencillo, el texto plano que se escribe en la columna de la izquierda genera el HTML que se puede ver representado en la derecha. Es además HTML valido, sin CSS embebido (exceptuando el código con resaltado de sintaxis, pero esto es necesario y tampoco es generado por Markdown si no por GeSHi anteriormente y ahora por Pygments) y empleando el mínimo necesario, siendo lo más limpio posible. Pero el contenido que se guarda en la base de datos y el que tú editas es el de la izquierda. Este contenido generará HTML valido hoy y mañana, es totalmente independiente del estilo que emplees en tu página y puedes migrarlo de un CMS a otro sin problema alguno. Todo son ventajas, el único inconveniente es que tienes que aprender a usar Markdown, algo que es sumamente sencillo, a la par que incrementa la legibilidad del texto plano.

La legibilidad del texto es uno de los pilares fundamentales de Markdown, tal y como el mismo autor, John Gruber, lo cuenta¹:

No voy ahora, en este articulo, a enseñarte a emplear Markdown, pero tienes una guía de prácticamente todas las posibilidades que te brinda en Markdown & Pygments Lexers Cheat Sheet. Además, si somos así de vagos, podemos emplear también algunos editores visuales que generan y emplean markdown, como markItUP! o el conocido WMD que empleamos en python majibu. Aunque ambos editores solo soportan Markdown estándar, cuando en este sitio también soporto las capacidades adicionales de Markdown Extra.

Todo el contenido de este sitio (exceptuando el automático, como las búsquedas, etiquetas, acerca de, ...) está generado empleando Markdown y todo está en HTML 5 valido. Un ejemplo del HTML que genera Markdown sería el siguiente:

Markdown	HTML
Documento de ejemplo ==================== Lorem ipsum [dolor sit amet](#mark), consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum semper adipiscing leo et blandit. Sed nibh quam, hendrerit _sit amet aliquam_ vel, pulvinar molestie augue.	<h1>Documento de ejemplo</h1> <p>Lorem ipsum <a href="#mark">dolor sit amet</a>, consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum <strong>semper adipiscing leo</strong> et blandit.</p> <p>Sed nibh quam, hendrerit <em>sit amet aliquam</em> vel, pulvinar molestie augue.</p>

Markdown

HTML

Documento de ejemplo
====================

Lorem ipsum [dolor sit amet](#mark), consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum **semper adipiscing leo** et blandit.

Sed nibh quam, hendrerit _sit amet aliquam_ vel, pulvinar molestie augue.

<h1>Documento de ejemplo</h1>

<p>Lorem ipsum <a href="#mark">dolor sit amet</a>, consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum <strong>semper adipiscing leo</strong> et blandit.</p>

<p>Sed nibh quam, hendrerit <em>sit amet aliquam</em> vel, pulvinar molestie augue.</p>

Como se puede ver es el HTMl justo, limpio y cumpliendo estándares, ni más ni menos. Este es un ejemplo muy sencillo, y posiblemente cualquier editor WYSIWYG sea capaz de dar el mismo resultado, el problema aparece con documentos más complejos, con sucesivas re-ediciones del texto y con editores mal configurados. Eso si, lo que se almacena en la BDD con Markdown es texto plano, con los otros editores, el texto, las etiquetas HTML y CSS embebido.

¿Porque Markdown y no otros?

Evidentemente Markdown no es el único lenguaje de marcado ligero, existen otros también conocidos y extendidos como Textile, BBCode, reStructuredText, Texy!, Txt2tags o los empleados en los Wikis como Creole o el de MediaWiki.

En primer lugar Markdown es uno de los que más características soporta, uno de los que más salidas puede generar (no solo HTML, también LaTeX, RTF, PDF, EPUB, ...) y además es probablemente el más extendido y soportado de todos (exceptuando BBCode y los de los Wikis, empleados en sus nichos particulares). Pero también es uno de los más fáciles de emplear (saliendo del formato básico como negritas, etc) y que produce un texto plano más vistoso y legible.

Comparativa

Como no, lo mejor, es ver una comparativa con un ejemplo del mismo documento y el texto empleado por cada uno de los lenguajes para generarlo. Para ello he creado un articulo aparte para mostrarla.

Comparativa

¿Quién emplea Markdown?

Una de las razones para emplear Markdown es porque es uno de los más extendidos, sobre todo en el mundo de la programación. Por ejemplo, Stack Overflow y todos los sitios de Stack Exchange emplean una variante de Markdown para la entrada de texto. Repositorios de código como GitHub y Bitbucket también lo emplean para ciertas funciones. También lo emplea el sistema de seguimiento de incidencias LightHouse.

Fuera del ámbito de la programación, sitios tan conocidos como Reddit lo emplean. Plataformas para la educación online como Moodle o Podmedics también hacen uso de él. Un Wiki como Instiki permite emplear Markdown. Plataformas de blogs y contenidos como Posterous, Tumblr y Squarespace lo ofrecen como opción. Y seguro que me estoy dejando en el tintero muchos más lugares donde es empleado habitualmente.

Hay que tener en cuenta de que aquí no he hablado de software CMS que lo soporta, eso lo contemplo en el próximo punto, si no más bien de organizaciones/compañías.

Excusas para no emplearlo

La primera que dice todo el mundo, es un incordio usarlo y aprenderlo, la pregunta es: ¿Has intentado emplearlo? Créeme se aprende en nada, sobre la marcha, y una vez que te acostumbras a él, lo elegirás frente a los editores WYSIWYG, casi con toda seguridad. Una vez aprendido no tienes que separar los dedos de tu teclado, no necesitas para nada el ratón para crear tu contenido. Ganarás mucho tiempo para ti mismo y lo agredeceras, créeme.

La segunda, no puedo usarlo en mi CMS o blog. ¿Seguro? A continuación te detallo las opciones que conozco para publicar contenidos empleando Markdown.

CMS y Blogs:

Por defecto, como opción o nativamente:
- Nesta
- Kohanut
- MovableType
- Typo
Con añadidos:
- Drupal A través de un modulo, Markdown Filter
- Wordpress Hay varios plugins disponibles para emplearlo.
- Django Hay varias formas de soportarlo.
- Plone Se puede habilitar a través de un modulo.
- Blogger A través de algunos proyectos externos, Blogger-markdown-editor
- ExpressionEngine A través de un plugin.
- Joomla A través de una extensión, jMarkdown

Generadores de sitios con contenido estático (HTML):

Plataforma de Blogs con contenido estático (HTML):

Calepin.co es un Pelican hospedado, que lee ficheros markdown desde DropBox

Wiki:

Por defecto, como opción o nativamente:
- Instiki
- ikiwiki
- sputnik
- nanoki
- gitit
Con añadidos:
- MoinMoin con una extensión
- MediaWiki con una extensión
- DokuWiki
- Oddmuse
- PmWiki

Foros:

phpBB A través de un MOD

Conversor Markdown desde/a otros formatos:

Pandoc

Editores de Texto que lo soportan (marcado de sintaxis):

Vim con Vim-Markdown
Emacs con markdown-mode
Gedit con gedit-markdown
Eclipse con el experimental markdown editor
TextMate
SubEthaEdit
Ecto
MarsEdit

Editor Markdown:

Editor Offline para blogs:

Editores Online para probar Markdown:

Dingus por John Gruber
Dingus PHP por Michel Fortin
Markdown Extra + GeShi por Anthony Bush
Dillinger es una aplicación en HTML 5 por Joe McCann
Babelmark para comparar las distintas implementaciones de Markdown
Markdown Editor por John Combe
Showdown
Markdownr

Y si eres desarrollador, tienes disponibles distintas implementaciones de Markdown:

Lenguaje	Implementaciones
Python	Python-markdown
PHP	PHP Markdown y PHP Markdown Extra
Perl	Original y MultiMarkdown
Ruby	BlueCloth, Maruku y Kramdown
C#	Markdown.NET
C	Discount y Peg-Markdown
C++	Cpp-markdown
Java	MarkdownJ
Javascript	Showdown
Lua	markdown.lua
Haskell	Pandoc
Common Lisp	CL-Markdown
Scala	Knockoff y Actuarius

Entonces, habiendo tantas opciones, ¿por qué no lo pruebas?

Y si hay más excusas, pues la verdad, no las conozco, dímelas tú.

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email. fuente ↩

Comparativa de Lenguajes de marcado ligero

2011-04-02T20:29:00+02:00

Esta es una comparativa de los lenguajes de marcado ligero más empleados de los disponibles actualmente. Dicha comparativa surge a partir de este articulo, Markdown, la mejor opción para crear contenidos web, donde defiendo la idoneidad de markdown para crear contenidos web.

En esta comparativa se verá como emplear cada uno de los lenguajes de marcado disponibles para crear un contenido web similar. Tomo como referencia a markdown, aunque no todos los lenguajes soportan todas o las mismas características que este.

Documento de ejemplo realizado con Markdown

Markdown

Resultado

Documento de ejemplo
====================
Lorem ipsum [dolor sit amet](#mark), consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum **semper adipiscing leo** et blandit.
Sed nibh quam, hendrerit _sit amet aliquam_ vel, pulvinar molestie augue.
> Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.
Lenguajes de marcado ligero
 * **Markdown**
 * Textile
 * reStructuredText
 * Texy!
 * Txt2tags
 * Marcado Wiki
   1. Creole
   2. MediaWiki
![avatar](pictures/no_wysiwyg.png)
### Cabecera H3 ###
- - -
Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.
|   | solo texto | HTML Limpio  |
| -------------- | -- | ------- |
| Markdown       | Si | Si      |
| Editor WYSISWG | X  | A veces |
_Ejemplo de código_
    import lifetime
     
    for each_day in lifetime.days():
        carpe_diem()
Suspendisse posuere velit et velit vehicula at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.
Esto es un texto con nota al pie [^ejemplo] y esta es otra nota [^segunda]

 *[vehicula]: automobila
[^ejemplo]: Esto es una nota al pie.
[^segunda]: Esto es la segunda nota.

Documento de ejemplo

Sed nibh quam, hendrerit sit amet aliquam vel, pulvinar molestie augue.

Lenguajes de marcado ligero

Markdown
Textile
reStructuredText
Texy!
Txt2tags
Marcado Wiki
1. Creole
2. MediaWiki

Cabecera H3

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

	solo texto	HTML Limpio
Markdown	Si	Si
Editor WYSISWG	X	A veces

Ejemplo de código

import lifetime
 
for each_day in lifetime.days():
    carpe_diem()

Suspendisse posuere velit et velit vehicula at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

Esto es un texto con nota al pie ¹ y esta es otra nota ²

Esto es una nota al pie. ↩
Esto es la segunda nota. ↩

Textile

Es una buena alternativa a Markdown y bastante extendido, aunque quizás menos que Markdown. Tiene algunas posibilidades que no tiene Markdown como emplear colores, poder alinear el texto o emplear superindice y subindice. También tiene carencias como el no poder dibujar líneas horizontales o el poder emplear acronimos solo con mayusculas y tener que declararlos en cada una de las partes del texto que aparezcan. Pero quiźas para mi la mayor desventaja es la menor legibilidad del texto, es menos evidente a un vistazo que markdown.

Textile

Resultado

h1. Documento de ejemplo

Lorem ipsum "dolor sit amet":#mark, consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum **semper adipiscing leo** et blandit.

Sed nibh quam, hendrerit _sit amet aliquam_ vel, pulvinar molestie augue.

bq. Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.

Lenguajes de marcado ligero

* **Markdown**
* Textile
* reStructuredText
* Texy!
* Txt2tags
* Marcado Wiki
## Creole
## MediaWiki

!pictures/no_wysiwyg.png (avatar)!

h3. Cabecera H3

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

|_. @@|_. solo texto|_. HTML Limpio|
|Markdown|Si|Si|
|Editor WYSISWG|X|A veces|

_Ejemplo de código_

bc.. import lifetime

for each_day in lifetime.days():
    carpe_diem()

p. Suspendisse posuere velit et velit VEHICULA(automobila) at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

Esto es un texto con nota al pie[1] y esta es otra nota[2]

fn1. Esto es una nota al pie.

fn2. Esto es la segunda nota.

Documento de ejemplo

Sed nibh quam, hendrerit sit amet aliquam vel, pulvinar molestie augue.

Lenguajes de marcado ligero

Markdown
Textile
reStructuredText
Texy!
Txt2tags
Marcado Wiki
1. Creole
2. MediaWiki

Cabecera H3

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

	solo texto	HTML Limpio
Markdown	Si	Si
Editor WYSISWG	X	A veces

Ejemplo de código

import lifetime

for each_day in lifetime.days():
    carpe_diem()

Suspendisse posuere velit et velit VEHICULA at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

Esto es un texto con nota al pie¹ y esta es otra nota²

¹ Esto es una nota al pie.

² Esto es la segunda nota.

BBCode

Es uno de los más extendido porque es ampliamente usado en foros por toda la red. Nació para ser empleado en foros y es prácticamente el único ámbito en el que se emplea. Es también muy limitado porque no soporta muchas de las características de los otros lenguajes y además hay múltiples variantes que no ayudan a crear un estándar. Por ejemplo las listas y las tablas no son contempladas en algunas de esas variantes.

BBCode	Resultado
Documento de ejemplo Lorem ipsum [url=http://joedicastro.com]dolor sit amet[/url], consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum [b]semper adipiscing leo[/b] et blandit. Sed nibh quam, hendrerit [i]sit amet aliquam[/i] vel, pulvinar molestie augue. [quote]Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.[/quote] [img]http://joedicastro/files/ imagenes/no_wysiwyg.png[/img] Cabecera H3 Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet. [i]Ejemplo de codigo[/i] [code] import lifetime for each_day in lifetime.days(): carpe_diem() [/code]	Documento de ejemplo Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum semper adipiscing leo et blandit. Sed nibh quam, hendrerit sit amet aliquam vel, pulvinar molestie augue. Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc. Cabecera H3 Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet. Ejemplo de codigo import lifetime for each_day in lifetime.days(): carpe_diem()

BBCode

Resultado

Documento de ejemplo

Lorem ipsum [url=http://joedicastro.com]dolor sit amet[/url], consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum [b]semper adipiscing leo[/b] et blandit.

Sed nibh quam, hendrerit [i]sit amet aliquam[/i] vel, pulvinar molestie augue.

[quote]Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.[/quote]

[img]http://joedicastro/files/
imagenes/no_wysiwyg.png[/img]

Cabecera H3

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

[i]Ejemplo de codigo[/i]

[code]
import lifetime

for each_day in lifetime.days():
    carpe_diem()
[/code]

Documento de ejemplo

Sed nibh quam, hendrerit sit amet aliquam vel, pulvinar molestie augue.

Cabecera H3

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

Ejemplo de codigo

import lifetime

for each_day in lifetime.days():
carpe_diem()

reStructuredText

Fue creado para crear documentación, en concreto documentación para lenguajes de programación como Python. Tiene algunas carencias al no estar orientado a HTML, pero también tiene posibilidades de las que carece Markdown. Es muy potente, bastante legible, pero un poco incomodo para según que cosas, a mi modo de ver.

reStructuredText

Resultado

Documento de ejemplo
====================

Lorem ipsum `dolor sit amet <#mark>`_, consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum **semper adipiscing leo** et blandit.

Sed nibh quam, hendrerit *sit amet aliquam* vel, pulvinar molestie augue.

Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.

Lenguajes de marcado ligero

 * **Markdown**
 * Textile
 * reStructuredText
 * Texy!
 * Txt2tags
 * Marcado Wiki

   1. Creole
   2. MediaWiki

.. image:: pictures/no_wysiwyg.png
   :alt: avatar

---------------

Cabecera H3
^^^^^^^^^^^

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

============== ========== ===========
\              solo texto HTML Limpio
============== ========== ===========
Markdown           Si         Si      
Editor WYSISWG     X        A veces 
============== ========== ===========

*Ejemplo de código*::

    import lifetime

    for each_day in lifetime.days():
        carpe_diem()

Suspendisse posuere velit et velit vehicula at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

Esto es un texto con nota al pie [1]_ y esta es otra nota [2]_

.. [1] Esto es una nota al pie.
.. [2] Esto es la segunda nota.

Documento de ejemplo

Sed nibh quam, hendrerit sit amet aliquam vel, pulvinar molestie augue.

Lenguajes de marcado ligero

Markdown
Textile
reStructuredText
Texy!
Txt2tags
Marcado Wiki
1. Creole
2. MediaWiki

Cabecera H3

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

	solo texto	HTML Limpio
Markdown	Si	Si
Editor WYSISWG	X	A veces

Ejemplo de código:

import lifetime

for each_day in lifetime.days():
    carpe_diem()

Suspendisse posuere velit et velit vehicula at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

Esto es un texto con nota al pie ¹ y esta es otra nota ²

Esto es una nota al pie. ↩
Esto es la segunda nota. ↩

Texy!

Fue específicamente diseñado para crear documentos XHTML, por ello es bastante completo, pero no está muy extendido. Es legible, pero también tiene carece de soporte para ciertos tags de HTML.

Texy!

Resultado

Documento de ejemplo
====================

Lorem ipsum [dolor sit amet | http://joedicastro.com], consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum **semper adipiscing leo** et blandit.

Sed nibh quam, hendrerit *sit amet aliquam* vel, pulvinar molestie augue.

> Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.

Lenguajes de marcado ligero

- **Markdown**
- Textile
- reStructuredText
- Texy!
- Txt2tags
- Marcado Wiki
 1) Creole
 2) MediaWiki

[* pictures/no_wysiwyg.png .(alt text)[avatar] *]

### Cabecera H3 ###

-----

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

|------------------------------
|   | solo texto | HTML Limpio  
|------------------------------
| Markdown       | Si | Si      
| Editor WYSISWG | X  | A veces

*Ejemplo de código*

/---code
  import lifetime

  for each_day in lifetime.days():
      carpe_diem()
\---

Suspendisse posuere velit et velit "vehicula"((automobila)) at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

Documento de ejemplo

Sed nibh quam, hendrerit sit amet aliquam vel, pulvinar molestie augue.

Lenguajes de marcado ligero

Markdown
Textile
reStructuredText
Texy!
Txt2tags
Marcado Wiki
1. Creole
2. MediaWiki

Cabecera H3

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

	solo texto	HTML Limpio
Markdown	Si	Si
Editor WYSISWG	X	A veces

Ejemplo de código

import lifetime

for each_day in lifetime.days():
    carpe_diem()

Suspendisse posuere velit et velit vehicula at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

txt2tags

Está escrito en Python y es muy potente, al igual que RestructuredText, permitiendo macros. Permite la salida en muchos formatos, incluido el XHTML. Es muy legible y muy fácil de emplear, es una pena que no esté más extendido y soportado. Aunque aún tiene algunas carencias como las notas al pie o las abreviaturas, que pueden ser soportadas con macros, también tiene un desarrollo muy activo. En la futura versión 3.0 serán soportados directamente las notas al pie. Es una alternativa con muy buen futuro.

txt2tags

Resultado

=Documento de ejemplo=

Lorem ipsum [dolor sit amet #mark], consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum **semper adipiscing leo** et blandit.

Sed nibh quam, hendrerit //sit amet aliquam// vel, pulvinar molestie augue.

Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.

Lenguajes de marcado ligero

- **Markdown**
 - Textile
 - reStructuredText
 - Texy!
 - Txt2tags
 - Marcado Wiki
  + Creole
  + MediaWiki

[pictures/no_wysiwyg.png]

===Cabecera H3===

--------------------

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

||   | solo texto | HTML Limpio
| Markdown       |  Si  |  Si  |
| Editor WYSISWG |  X  |  A veces  |

//Ejemplo de codigo//

```
import lifetime

for each_day in lifetime.days():
    carpe_diem()
```

Documento de ejemplo

Sed nibh quam, hendrerit sit amet aliquam vel, pulvinar molestie augue.

Lenguajes de marcado ligero

Markdown
Textile
reStructuredText
Texy!
Txt2tags
Marcado Wiki
1. Creole
2. MediaWiki

Cabecera H3

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

	solo texto	HTML Limpio
Markdown	Si	Si
Editor WYSISWG	X	A veces

Ejemplo de codigo

import lifetime

for each_day in lifetime.days():
    carpe_diem()

Creole

Creado a partir de los lenguajes más empleados en los Wikis y usado fundamentalmente en Wikis, por lo que también tiene ciertas carencias.

Creole

Resultado

== Documento de ejemplo ==

Lorem ipsum [[#mark|dolor sit amet]], consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum **semper adipiscing leo** et blandit.

Sed nibh quam, hendrerit //sit amet aliquam// vel, pulvinar molestie augue.

> Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.

Lenguajes de marcado ligero

* **Markdown**
 * Textile
 * reStructuredText
 * Texy!
 * Txt2tags
 * Marcado Wiki
 ## Creole
 ## MediaWiki

{{pictures/no_wysiwyg.png|avatar}}

==== Cabecera H3 ====

-----

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

|= |= solo texto |= HTML Limpio |
| Markdown       | Si | Si      |
| Editor WYSISWG | X  | A veces |

//Ejemplo de código//
{{{
import lifetime

for each_day in lifetime.days():
    carpe_diem()
}}}

Documento de ejemplo

Sed nibh quam, hendrerit sit amet aliquam vel, pulvinar molestie augue.

Lenguajes de marcado ligero

Markdown
Textile
reStructuredText
Texy!
Txt2tags
Marcado Wiki
1. Creole
2. MediaWiki

Cabecera H3

-----

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

	solo texto	HTML Limpio
Markdown	Si	Si
Editor WYSISWG	X	A veces

Ejemplo de código

import lifetime

for each_day in lifetime.days():
    carpe_diem()

MediaWiki

Quizás el más extendido, no en vano MediaWiki es el Wiki empleado por la Wikipedia. Igual que Creole, tiene ciertas limitaciones que suple con plugins y etiquetas HTML. No me acaba de gustar. La manera que tiene de crear tablas - por ejemplo - aunque potente, no me parece nada legible en texto plano.

MediaWiki

Resultado

==Documento de ejemplo==

Lorem ipsum [http://joedicastro.com dolor sit amet], consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum '''semper adipiscing leo''' et blandit.

Sed nibh quam, hendrerit ''sit amet aliquam'' vel, pulvinar molestie augue.

Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.

Lenguajes de marcado ligero

* '''Markdown'''
* Textile
* reStructuredText
* Texy!
* Txt2tags
* Marcado Wiki
*# Creole
*# MediaWiki

[[File:pictures/no_wysiwyg.png|caption]]

=== Cabecera H3 ===

----

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

{| 
! 
! solo texto
! HTML Limpio
|-
|Markdown
|Si
|Si
|-
|Editor WYSISWG
|X
|A veces
|}

''Ejemplo de código''

  import lifetime
   
  for each_day in lifetime.days():
      carpe_diem()

Suspendisse posuere velit et velit vehicula at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

Esto es un texto con nota al pie Esto es una nota al pie. y esta es otra nota  Esto es la segunda nota.

{{reflist}}

Documento de ejemplo

Sed nibh quam, hendrerit sit amet aliquam vel, pulvinar molestie augue.

Lenguajes de marcado ligero

Markdown
Textile
reStructuredText
Texy!
Txt2tags
Marcado Wiki
1. Creole
2. MediaWiki

Cabecera H3

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

	solo texto	HTML Limpio
Markdown	Si	Si
Editor WYSISWG	X	A veces

Ejemplo de código

import lifetime

for each_day in lifetime.days():
    carpe_diem()

Suspendisse posuere velit et velit vehicula at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

Esto es un texto con nota al pie ^[1] y esta es otra nota ^[2]

^ Esto es una nota al pie.
^ Esto es la segunda nota.