Montar un servidor http local para pruebas
La necesidad
A vueltas con la nueva solución para mi blog estático, me encuentro que no es tan estático como debería ser. No sólo por haberle puesto algún script para gestionar los comentarios.
El problema que me he encontrado es que los paths que utiliza
org-page para los enlaces a cosas internas, como las imágenes o los
ficheros de otros artículos, comienzan todos por «/» y son, por tanto,
absolutos dentro del servidor. No sé si eso se podría configurar, no
encuentro ninguna opción que me lo permita. Con el sistema anterior,
aún no teniendo un servidor en marcha, era capaz de navegar el
blog. Con este sistema, una vez generados los ficheros del blog, no se
pueden navegar, no funcionan los enlaces.
Al principio, utilizaba el mismo sistema de emacs: lanzaba desde el
mismo emacs con M-x op/do-publication-and-preview-site el servidor
interno y lo detenía con M-x httpd-stop. org-page generaba
directamente una estructura de ficheros y cada artículo lo guarda en
un fichero index.html dentro de un chorizo de directorios del
estilo:
/tema/año/mes/día/título-del-artículo/
El sistema anterior generaba sólo un fichero con un nombre del estilo
título-del-artículo.html y los guardaba todos en el mismo
directorio. El problema que me encontré es que para org-page el
directorio ./ para generar los enlaces de las imágenes, por ejemplo,
es /tema/año/mes/día/. Sin embargo, para el resto de los servidores
ese directorio es el mismo donde se encuentra el fichero index.html.
En resumen, si pongo la imagen donde se ve con el servidor de emacs no se verá en el servidor remoto cuando suba el blog. Si lo pongo donde se ve en el servidor remoto, en local no veo correctamente la página para hacerme una idea de cómo quedará, por si hubiera que hacer algún cambio antes de subirlo.
¿Cómo solucionar esto? Pues montando un servidor de pruebas.
Montando un servidor
Montar un servidor como Apache o cualquier otro me parecía una salvajada. En recursos y en quebraderos de cabeza. Así que me puse a recordar que había otros sistemas locales montados sobre algunos módulos o paquetes como Python o PHP, dos lenguajes que se utilizan para el desarrollo web. Supongo que habrá otros sistemas, pero me centraré en los que conozco y que he empezado a utilizar.
La opción de Python
Python es uno de mis lenguajes favoritos y el que más utilizo normalmente para mis cosas. Aunque en la actualidad estoy sufriendo una invasión en todos los ámbitos de emacs y éste trae de fábrica el Lisp. Supongo que si sigue con el rumbo actual, terminaré moviéndome más hacia elisp o incluso me estoy mirando seriamente guile como alternativa a mis scripts.
Pero vamos al tema: necesito un servidor de pruebas y me acordé del que viene instalado con el propio Python. Bueno, de los que vienen con dicho lenguaje según tengamos instalado una versión de Python u otra.
¿No sabes que versión tienes instalada? Pues teclea lo siguiente:
python -V
Y mira qué responde. Si la respuesta es del tipo 2.x o del tipo 3.x es importante pues el comando variará de una a otra versión:
python -m SimpleHTTPServer [puerto] # Para Python 2.x python -m http.server [puerto] # Para Python 3.x
Hacerlo funcionar es muy sencillo: ir al directorio donde se ha hecho el deploy del blog y lanza el sistema con el comando correspondiente.
La opción PHP
En realidad, mi primera opción fue Python, pero también he probado con PHP, más con la esperanza de que el plugin de los comentarios, ya que utiliza este lenguaje para trabajar, funcionase. Si hubiera sido así, seguramente seguiría utilizándolo. El comando que se utiliza es:
php -S host:puerto
Y se emplea de forma similar a los de Python.
Conclusión
Mi forma de trabajar ha variado un poco para afinar todos esos
detalles. Por ejemplo, antes guardaba todas las imágenes en un
directorio images y tenía que arreglar problemas de colisión de
nombres de basura que quedaba si eliminaba un artículo y no me
preocupaba de qué ficheros enlazaba. Con el sistema actual, guardo en
el mismo directorio el artículo y sus enlazados, como imágenes y otros
ficheros adjuntos. Si borro un artículo, desaparecerá todo y no tendré
que estar buscando en un directorio enorme una o dos imágenes. Además,
si me apeteciera (que no es lo habitual), llamar a las imágenes
imagen01.png, imagen02.png, estaré seguro de que no habrá ningún
conflicto de nombres porque estos sólo tendrán sentido dentro de cada
artículo.
También ha cambiado, en que lanzo el servidor desde una consola externa y la mantengo abierta:
notxor:~> cd ~/public_html notxor:~/public_html> python http.server 8080 Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080) ...
Cuando hago cambios los subo al directorio public_html con el
comando op/do-publication, abro el navegador, o si lo tengo abierto,
refresco el contenido y así trabajo.
Comentarios