Moving to prod!

19 files changed, 703 insertions, 0 deletions

diff --git a/blog/content/2012/01/backups-con-zfs.gmi b/blog/content/2012/01/backups-con-zfs.gmi
new file mode 100644
index 00000000..05c65989
--- /dev/null
+++ b/blog/content/2012/01/backups-con-zfs.gmi
@@ -0,0 +1,30 @@
+# Backups con ZFS
+2012-01-19
+
+Hasta ahora había estado usando el excelente rdiff-backup para hacer backups de mis datos (unos 700gb) a una unidad externa USB. Realmente funciona muy bien; el último backup está directamente disponible en el disco- sin necesitar usar rdiff-backup para leerlo y se guardan incrementos, con lo que es relativamente sencillo recuperar ficheros borrados (usando sus herramientas). Podemos eliminar incrementales fácilmente y en definitiva, es una solución sencilla y harto recomendable.
+
+Sin embargo, tiene en mi opinión un par de defectos. No es sencillo comprimir los backups convenientemente (se puede hacer usando un sistema de archivos que soporte compresión, pero no hay muchos) y si renombras o mueves archivos grandes, pagas su espacio doble (una vez en su estado anterior, otra vez en el nuevo). A parte, la gestión de incrementales es lenta y los backups también tienden a alargarse.
+
+Por ello se me ocurrió usar ZFS. ZFS es el sistema de archivos "futurista" de Sun Microsystems (ahora Oracle). Incluye snapshots baratos, deduplicación y compresión transparente. Así pense que si sincronizaba los datos que quería preservar a un volumen ZFS y tomaba un snapshots, tendría backups (podría usar los snapshots para recuperar archivos antiguos). Gracias a la deduplicación, un mismo archivo que en varios snapshots tuviese nombres diferentes sólo sería almacenado una vez. Y de bonus, compresión.
+
+El problema es que el futuro de ZFS es incierto. Lógicamente Oracle seguirá soportándolo sobre Solaris, pero lógicamente no estoy dispuesto a pagar por ello habiendo sistemas operativos gratuitos perfectamente usables. Actualmente ZFS (y Solaris) son open source, y por ello ZFS funciona en otros sistemas operativos, pero no está claro lo que pueda suceder a partir de ahora.
+
+En todo caso, me lancé a la piscina. En Linux existen dos implementaciones, ZFS on Linux[1], de reciente aparición- pero no es del todo agua clara (probablemente no se pueda distribuir dentro de Debian y se debe compilar contra el kernel- nada irresoluble pero desde luego inconveniente), así que me decidí por ZFS-Fuse[2], que está en Debian y parece más "estable".
+
+Una vez instalado mediante apt-get o similares, simplemente tenemos que hacer algo así como:
+
+zpool create zfs /dev/sdx zfs create zfs/backup zfs set dedup=verify zfs/backup zfs set compression=on zfs/backup
+
+, donde /dev/sdx es un dispositivo externo. Dedup y compression tienen varias opciones que vale la pena investigar. Una vez esto, uso un script como este para el backup:
+
+#!/bin/sh
+
+/etc/init.d/zfs-fuse start zpool import -a rsync -ax --delete --exclude ... --exclude ... / /zfs/backup/julius/root/ zfs snapshot zfs/backup@$(date +%Y%m%d%H%M) zfs list -t snapshot zpool export zfs /etc/init.d/zfs-fuse stop
+
+; la mayor parte del follón es que exporto e importo el sistema ZFS para poder desconectar el dispositivo USB.
+
+El rendimiento de ZFS bajo Fuse y mi disco USB es horripilante (3Mb/s), probablemente una confabulación de FUSE, lentitud de USB, mal disco duro externo, compresión y deduplicación, pero una vez pasa el interminable primer backup, el incremental me parece hasta más rápido que el de rdiff-backup. La deduplicación y compresión no dan muchos réditos de momento, pero es un sistema interesante.
+
+
+=> http://zfsonlinux.org/ 1: http://zfsonlinux.org/
+=> http://zfs-fuse.net/ 2: http://zfs-fuse.net/
\ No newline at end of file
diff --git a/blog/content/2012/01/mi-tema-de-wordpress.gmi b/blog/content/2012/01/mi-tema-de-wordpress.gmi
new file mode 100644
index 00000000..87baac1a
--- /dev/null
+++ b/blog/content/2012/01/mi-tema-de-wordpress.gmi
@@ -0,0 +1,10 @@
+# Mi tema de Wordpress
+2012-01-04
+
+.assistive-text, .screen-reader-text, .menu, #nav-above, #colophon {  display: none; }
+
+#page {  margin-left: auto;  margin-right: auto;  max-width: 1000px; }
+
+#primary {  max-width: 720px;  min-width: 320px;  float: left;  margin-left: 15px;  margin-right: 15px; }
+
+#secondary {  min-width: 175px;  width: 240px;  float: left; }
\ No newline at end of file
diff --git a/blog/content/2012/01/stumblr.gmi b/blog/content/2012/01/stumblr.gmi
new file mode 100644
index 00000000..c72e5e6a
--- /dev/null
+++ b/blog/content/2012/01/stumblr.gmi
@@ -0,0 +1,9 @@
+# Stumblr
+2012-01-05
+
+Me he abierto un Tumblr en koalillo.tumblr.com[1]. Sustituirá a mi uso de Google Plus para compartir cosas cortas (principalmente del Google Reader). Crosspostea a mi @koalillo[2], Facebook[3] y el lateral de este blog.
+
+
+=> http://koalillo.tumblr.com/ 1: http://koalillo.tumblr.com/
+=> https://farside.link/nitter/koalillo 2: https://farside.link/nitter/koalillo
+=> http://www.facebook.com/alex.corcoles 3: http://www.facebook.com/alex.corcoles
\ No newline at end of file
diff --git a/blog/content/2012/02/minirresena-sansa-clip-2gb.gmi b/blog/content/2012/02/minirresena-sansa-clip-2gb.gmi
new file mode 100644
index 00000000..faefdc9b
--- /dev/null
+++ b/blog/content/2012/02/minirresena-sansa-clip-2gb.gmi
@@ -0,0 +1,31 @@
+# Minirreseña : Sansa Clip + 2GB
+2012-02-10
+
+Tras un breve interludio, he podido recuperar la costumbre de escuchar música mientras trabajo. Raro que es uno, en vez de usar el ordenador donde trabajo o el móvil, me he decidido a comprarme un reproductor de MP3. Principalmente por:
+
+* No tengo ninguna radio portátil y me gusta escuchar Carrusel DeportivoTiempo de Juego. Puedo escucharlo en streaming con el móvil, pero sólo es viable cuando tengo wifi a mano y además, funde batería
+* La batería de la Blackberry me aguanta bastante (con un uso intenso he llegado a casa con un 50%), pero no me gusta despilfarrarla inútilmente
+* No me gusta tener mi colección de música en ordenadores ajenos
+
+Con ello, me puse a buscar reproductores. Criterios:
+
+* Radio FM
+* 20GB+ de capacidad; paso de tener que seleccionar música
+* Debe poderse usar para almacenar ficheros arbitrarios (Zune 120 que me cedían, eliminado [nota: los iPod requieren el uso de iTunes para gestionar música, pero puedes usarlos como mass storage para guardar ficheros. El Zune, hasta donde yo he podido ver, no)
+* Conector estándar. Bonus si se enchufa sin cable (como una memoria Flash USB) [nota: podría considerarse que el conector de los iPod es estándar de facto]
+* Carga por USB
+* Sencillez de gestión. Tengo una máquina virtual con Windows, pero en general uso Linux. Usar cosas que se basan en protocolos cerrados no me gusta (puede funcionar *ahora*, pero igual mañana no). MTP me parece aceptable (aunque no le veo la utilidad y toca un poco las narices- pero al menos es un protocolo publicado). Zune fuera otra vez (usa un MTP especial sin documentar [y ni existen implementaciones alternativas]) y iPod (iTunes, simplemente di no).
+
+Inicialmente pensaba que encontraría dispositivos que cumpliesen todo esto a porrillo, pero la verdad que al final tuve que irme al famoso Sansa Clip+[1] de 2GB con tarjeta MicroSD de 32GB. El aparato está por 36€ en amazon.es, junto con la tarjeta de memoria y gastos de envío se queda todo en unos 60€ (una auténtica ganga, en mi opinión).
+
+El único requisito que no cumple es que tiene conector para cable MiniUSB cuando hubiera preferido que fuese "macho" y se pudiese conectar directamente a un puerto USB: posibilidad de gestionar música, ficheros y cargar sin tener que tener un cable a mano. Los cables MiniUSB son suficientemente comunes como para que no me parezca algo insuperable.
+
+El funcionamiento del aparato es correcto- cumple las 15h de batería anunciadas con bastante precisión (me da para dos días sin cargarlo, pero mi intención es cargarlo mientras me voy a comer- al parecer las baterías de ion litio son amigas de las cargas frecuentes). El interfaz es de botoncitos con d-pad, todos muy correctos y se puede usar perfectamente dentro de un bolsillo (pausa, volumen, siguiente canción...), aunque lógicamente no es muy bueno para navegar (buscar un artista por nombre, por ejemplo, es un rollo en un d-pad; sería mejor algo "analógico" como la rueda de un iPod o una pantalla táctil). La funcionalidad de radio es un poco limitada (pocos presets, la navegación por presets es unidireccional).
+
+En cualquier caso, el aparato cumple con su función más que aceptablemente y con fallos perfectamente tolerables.
+
+El bonus es que es uno de los reproductores mejor soportados por Rockbox[2], un popular firmware para reproductores MP3. Este podría en principio corregir algún defectillo (supongo que la funcionalidad de radio será mejor) y mejorar el interface, a la par que ofrecer alguna funcionalidad extra (viene con bastantes juegos). Sin embargo, a pesar de que el proceso de instalación para sencillo y seguro, de momento no lo he intentado- igual cuando el aburrimiento se apodere de uno...
+
+
+=> http://www.sandisk.com/products/sansa-music-and-video-players/sandisk-sansa-clipplus-mp3-player 1: http://www.sandisk.com/products/sansa-music-and-video-players/sandisk-sansa-clipplus-mp3-player
+=> http://www.rockbox.org/ 2: http://www.rockbox.org/
\ No newline at end of file
diff --git a/blog/content/2012/03/la-guia-del-autoestopista-galactico-a-la-administracion-de-sistemas-i.gmi b/blog/content/2012/03/la-guia-del-autoestopista-galactico-a-la-administracion-de-sistemas-i.gmi
new file mode 100644
index 00000000..6dd930de
--- /dev/null
+++ b/blog/content/2012/03/la-guia-del-autoestopista-galactico-a-la-administracion-de-sistemas-i.gmi
@@ -0,0 +1,70 @@
+# La guía del autoestopista galáctico a la administración de sistemas (I)
+2012-03-18
+
+Tradicionalmente se divide el campo de la informática en dos grandes áreas: programación y administración. El programador idea software nuevo o modifica el existente para cumplir con requisitos que no cubre ningún sistema disponible, mientras que el administrador utiliza software existente para cubrir estos requisitos. El entusiasta informático (o pringado de turno) a veces adquire alguna de estas (o ambas) funciones, aunque con mayor frecuencia suele desempeñar la segunda.
+
+Mantener nuestro equipo funcionando e instalar el software que queremos es, por supuesto, administración de sistemas, así como otros temas de hardware doméstico, como mantener una red local. Esta serie de artículos, sin embargo, se centrará en la administración de sistemas no doméstica.
+
+Mucha gente desea tener un blog, una web, un sistema de correos propio, etc. por los más diversos motivos. Por supuesto, para la mayoría de cosas se pueden encontrar proveedores que por un módico precio (o en ocasiones, incluso gratis) podrá proporcionarnos estos servicios fácilmente, pero en ocasiones no encontraremos a alguien que cumpla nuestros requisitos, no querremos depender de un tercero o simplemente querremos experimentar.
+
+Cabe decir, que salvo la última situación o variantes, probablemente estemos cometiendo un error. Pero si estás leyendo esto, probablemente sea tarde para disuadirte. Así que, sigamos adelante (nota: iré recordándote esto periódicamente).
+
+Lo primero es determinar tus requisitos. ¿Queremos tener un blog? ¿Quizás unos foros? ¿Queremos almacenamiento online? ¿Un servidor de correo?
+
+Especifiquemos. ¿Cuánto espacio necesitamos? ¿Qué software cumple con nuestros deseos? Todo esto debería ser fácil de articular- estamos emprendiendo este viaje porque ninguna de las soluciones que hemos investigado cumple nuestros requisitos: ¿cuáles son?
+
+Los requisitos no están aislados, forman una cadena de dependencias. Si quiero usar Wordpress, necesitaré un servidor web capaz de ejecutar PHP de una determinada versión, una base de datos MySQL de otra versión, etc. Tomemos un momento para intentar enumerar en la medida de lo posible todos nuestros requisitos.
+
+Típicamente, necesitaremos un sistema con el que podamos satisfacer los requisitos. Hay básicamente dos alternativas, escoger un sistema gestionado o no gestionado.
+
+Un sistema gestionado es lo que comunmente se conoce por estos lares como "hosting compartido". El proveedor nos da un sistema con PHP, MySQL en unas determinadas versiones al cual no tenemos acceso completo. En cambio, un sistema no gestionado en general nos da un sistema operativo al que tenemos acceso prácticamente completo- esto es lo que en general se denomina VPS o servidor dedicado (dependiendo de si el sistema es una máquina virtual o física).
+
+En general, cuanto más gestionado el sistema, menos trabajo para nosotros pero también menos control. Si el hosting compartido cumple nuestros requisitos, seguramente será más barato y nos requerirá menos tiempo hacer funcionar lo que queremos. Muchas veces estos hostings compartidos ofrecen software conocido (i.e. Wordpress, etc.) con sencillos instaladores que lo ponen en marcha sin esfuerzo. Es poco probable, sin embargo, que quien lea estas líneas se vea satisfecho por estas opciones, pero cabe valorarlas y (una vez más), poder señalar qué requisito no cumplen.
+
+Los sistemas no gestionados son un poco más complicados. Nuestro primer paso probablemente sea escoger uno. El precio y fama son factores importantes, pero también debemos considerar otros.
+
+El sistema operativo es probablemente la decisión clave. Muchas veces nuestros propios requisitos nos forzarán a escoger uno- un software puede funcionar sólo sobre Windows o sobre alguna versión específica de Linux. Si no, la cosa es un poco más complicada.
+
+Por temas de coste, los sistemas Linux suelen ser una elección natural- Windows en general es más caro y representa una parte sustancial del coste de un alojamiento, y además muchas aplicaciones populares no están tan probadas y rodadas sobre Windows. Existen otros sistemas operativos fuera de estos dos, por supuesto, pero para las situaciones en las que nos encontramos no suelen ser muy populares ni adecuados.
+
+Dentro de las distribuciones Linux hay un vasto elenco de opciones, y resulta poco viable evaluarlas todas. Mi sugerencia se reduce a escoger sólo entre dos: CentOS/RHEL y Debian.
+
+RHEL (Redhat Enterprise Linux) es la distribución comercial de Linux más popular. Su interés se centra en dos puntos principales:
+
+* Algunos programas comerciales están pensados para RHEL
+* Su largo ciclo de vida
+
+Si deseamos ejecutar algo que requiere RHEL, raramente hay otra opción viable, así que nuestra elección está realizada. Sin embargo, esto cada día es menos habitual, así que el motivo principal para usar RHEL es su prolongado ciclo de vida. Redhat se compromete a dar actualizaciones exclusivamente de corrección de bugs y de seguridad durante mucho tiempo- concretamente de hasta 10 años.
+
+¿Por qué es importante esto? Pues porque los servicios que expongamos a Internet deben ser seguros. Nuestro servicio no funcionará si un ente hostil lo ataca con éxito y lo deja inoperativo. Existe una poderosa motivación económica que hace que sea rentable atacar sistemas, lo que se traduce en un riesgo más que significativo. Así pues, deberemos ser proactivos en la corrección de defectos de seguridad, y eso prácticamente siempre implica la instalación de nuevas versiones del software que usamos.
+
+La ventaja de RHEL es que nos proporcionan estas actualizaciones sin ningún otro tipo de cambio. Es decir, sin mejoras de funcionalidad. Esto que parece contraproducente es en cambio a menudo una gran ventaja. Una nueva funcionalidad puede introducir bugs o cambios en el funcionamiento del software que nos fuercen a trabajar; actualizar configuraciones, instalar otro software, etc. Si nuestro sistema cumple nuestros requisitos, es probable que esto no nos dé ningún beneficio y sí nos haga perder el tiempo.
+
+Una instalación con RHEL puede ser mantenida al día con correcciones de seguridad casi sin esfuerzo, lo cual es un gran beneficio.
+
+Eso sí, hay tres inconvenientes.
+
+El primero es que RHEL es un producto comercial (y bastante costoso, de hecho). Pero existe una solución sencilla- RHEL es prácticamente completamente open source, con lo que Redhat distribuye libremente el código fuente de RHEL (excepto unas partes específicas que no son open source, pero que en general no nos interesarán), con lo que existen ciertas entidades que cogen este código fuente y construyen clones de RHEL libremente distribuibles. El más popular actualmente es CentOS. La gran diferencia, más allá de las partes no open source, es que estos proyectos no suelen tener las actualizaciones listas a la misma velocidad que la propia Redhat.
+
+El segundo es que esta garantía sólo es aplicable al software incluido dentro de RHEL- cada software que necesitemos que entre dentro de nuestos requisitos que no esté en RHEL nos irá restando de la facilidad de mantenimiento. Con un poco de suerte, el software que querremos estará en repositorios de calidad como EPEL, repositorio mantenido por gente de Fedora que funciona bien y está bien actualizado- existen algunos repositorios de este tipo. Alternativamente, hay software que dispone de repositorios propios de RHEL que funcionan bastante bien. Pero añadir estos repositorios de terceros siempre añade algo de entropía al sistema e incluso podemos encontrarnos que el software que queramos no esté empaquetado para RHEL y lo tengamos que instalar desde el código fuente... haciendo de los procesos de actualización un proceso manual.
+
+El tercero es que el proceso de actualización de una versión de RHEL a otra no está soportado. Un sistema instalado con RHEL 6 (la versión más reciente), no podrá ser actualizado fácilmente a RHEL 7 cuando este salga a la luz (salen cada dos-tres años). Podremos usarlo sin problemas hasta que acabe su (largo) ciclo de vida de 10 años, pero cuando acabe o necesitemos actualizar a RHEL 7, lo mejor será construir un nuevo sistema con RHEL 7.
+
+Si el motivo para escoger RHEL es la facilidad de mantenimiento y actualización, todo requisito que se salga de los paquetes de RHEL es un motivo más para no usar RHEL.
+
+Y si el software que queremos no está en RHEL, ¿qué hacemos? Pues la otra alternativa es Debian. Debian es la distribución completamente open source más relevante del mercado. Sus objetivos incluyen el de ser "el sistema operativo open source universal", algo que incluye la voluntad de empaquetar todo software libre existente (y de hecho, también parte del no libre), algo que se refleja en el descomunal número de paquetes; si es open source, lo más probable es que esté en Debian.
+
+Sin embargo, esta gran cantidad de paquetes hace más complicado ofrecer un ciclo de vida largo como el de RHEL. Debian tiene una versión estable que sale cada más o menos un par de años (las últimas versiones estables son de 2011, 2009, 2007, 2005, 2002) y tiene actualizaciones de seguridad hasta la siguiente versión estable, así que si con RHEL podíamos estar hasta 10 años actualizando con mínimo esfuerzo, en Debian sólo podremos estarnos 2. Eso sí, Debian sí soporta actualizar entre versiones y al cabo de dos años podremos (con un poco de esfuerzo) pasarnos a la siguiente versión estable.
+
+Debian también nos ofrece testing, una versión constantemente actualizada donde van entrando paquetes nuevos a medida que van saliendo. Testing puede tener más esfuerzo de actualización (pueden entrar paquetes que introducen cambios significativos que nos obliguen a trabajar), pero dispone de software relativamente actualizado y moderno.
+
+En general, la vida con Debian es algo menos cómoda que un RHEL donde nos mantengamos dentro de los paquetes estándares, pero no mucho peor. Y si nuestros requisitos no están cubiertos por los paquetes estándar de RHEL, seguramente viviremos mucho mejor con un servidor Debian. Para ayudaros a tomar esta decisión, podéis usar los índices de paquetes de ambas distribuciones. Podéis consultar en el FTP de Redhat la lista de paquetes disponibles para RHEL 6[1] y Debian ofrece packages.debian.org donde podéis ver qué software hay en stable y testing[2].
+
+Más allá de esto, hay otras diferencias entre ambas; documentación, herramientas administrativas, etc. son diferentes y cada cuál preferirá una u otra (a mi en general me gusta más Debian, pero la documentación de RHEL es muy interesante, por ejemplo). Antes de tomar una decisión también es conveniente que las probemos- con la facilidad hoy en día de usar virtualización es muy muy sencillo instalar ambas distribuciones en máquinas virtuales y hacer pruebas.
+
+actualizado: correcciones del sospechoso habitual[3]
+
+
+=> http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/ 1: http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/
+=> http://www.debian.org/distrib/packages#view 2: http://www.debian.org/distrib/packages#view
+=> http://obm.corcoles.net 3: http://obm.corcoles.net
\ No newline at end of file
diff --git a/blog/content/2012/04/la-guia-del-autoestopista-galactico-a-la-administracion-de-sistemas-ii.gmi b/blog/content/2012/04/la-guia-del-autoestopista-galactico-a-la-administracion-de-sistemas-ii.gmi
new file mode 100644
index 00000000..807d00c8
--- /dev/null
+++ b/blog/content/2012/04/la-guia-del-autoestopista-galactico-a-la-administracion-de-sistemas-ii.gmi
@@ -0,0 +1,39 @@
+# La guía del autoestopista galáctico a la administración de sistemas (II)
+2012-04-22
+
+Si seguisteis la entrega anterior de esta saga[1], deberíais estar con una lista de requerimientos y una decisión más o menos en firme de qué distribución de Linux usaremos para cumplir nuestros requerimientos (seguramente Debian o CentOS).
+
+El paso siguiente es lanzarse a la piscina. Como dijimos anteriormente, una herramienta muy interesante a utilizar es la virtualización. La virtualización nos permite poder hacer instalaciones de sistemas operativos dentro de nuestro ordenador habitual, completamente aisladas del resto de nuestro entorno y con posibilidad de crear tantas instancias como queramos, de los sistemas operativos que queramos y crearlas, eliminarlas, arrancarlas y pararlas con total libertad. El único requisito duro que necesitamos es memoria; una máquina virtual consume en general tanta memoria como la que tenga la máquina que estemos virtualizando. A pesar de ello, hasta los ordenadores modernos más asequibles cuentan con respetables cantidades de memoria, y para muchas cosas, nos bastará para los habitualmente modestos requerimientos de lo que queramos montar (los ordenadores de hoy en día vienen con 4gb de RAM o más, y para una típica máquina con Linux, Apache, MySQL, etc. nos pueden bastar 256 o 512mb). Otro punto a tener en cuenta es la CPU- si bien en general no necesitaremos una CPU muy potente (una vez más, los requerimientos de CPU de los montajes habituales son bastante modestos), es interesante que nuestra CPU cuente con las extensiones de virtualización, que nos pueden facilitar la vida. Por último, en disco con unos 20-30gb libres por máquina virtual que deseemos suelen ser más que suficientes.
+
+Respecto a los sistemas de virtualización, ciertamente existen muchos, pero cuando quiero virtualizar sistemas "de prueba" a los que quiero acceder desde mi ordenador de escritorio, me decanto por VirtualBox[2], un excelente sistema de virtualización de Sun Oracle,  totalmente gratuito y perfectamente funcional, que cubre perfectamente todo lo que le podamos pedir a un sistema de virtualización "de escritorio".
+
+Con VirtualBox instalado y la ISO del sistema operativo que queramos instalar, nos podemos poner en marcha; creamos la máquina virtual, le conectamos la ISO y nos ponemos con el proceso de instalación. La instalación de sistemas operativos Linux se ha simplificado mucho en los últimos tiempos y, especialmente en una máquina virtual donde prácticamente no hay problemas de hardware, la instalación tiende a ser extremadamente sencilla. Unos puntos a tener en cuenta:
+
+* Particionado. A pesar de que muchas distribuciones nos pueden sugerir un particionado complejo, si no tenemos muy claro lo que hacer, o aceptamos la opción por defecto de la distribución o usamos una simple partición para todo. Usar particiones puede tener algunas ventajas, pero muchas veces nos hacen "predecir" erróneamente el uso de disco que haremos y causarnos dolores de cabeza. Con una partición única nos ahorramos estos problemas
+* Usuarios. Es siempre preferible acostumbrarse a usar un usuario no privilegiado personal y usar sudo para escalar privilegios. También es interesante tener un usuario de root, con una contraseña guardada en lugar seguro para posibles emergencias. Por supuesto, toda contraseña debe ser aceptablemente segura (que no sea fácil de acertar; yo recomiendo memorizar una frase de unas cuantas palabras, usar las iniciales de las palabras y añadir algún que otro dígito; e.g. cogiendo el título de este artículo, lgdagalads2)
+* Reloj. La hora de un sistema es más importante de lo que parece para su funcionamiento correcto y pese a que un reloj mal configurado puede no causar problemas, nos simplifica mucho la vida que el reloj sea fiable (por ejemplo,  a la hora de revisar logs es importante que estos "digan la verdad" respecto a la hora). Si la distribución no nos ofrece sincronizar el reloj con un servicio como ntpd, es conveniente que lo configuremos nosotros.
+
+En todo caso, ya durante la instalación debemos aplicar una mecánica imprescindible para que todo sea correcto. Se trata de documentar. Debemos ser capaces de reproducir **exactamente** todo lo que realicemos para poner nuestros servicios en funcionamiento. Tras el proceso de instalación y configuración, debemos obtener un documento que contenga todo lo que hacemos y que nos permita instalar otra máquina exactamente igual. Esta documentación es extremadamente útil:
+
+* Nos permite reconstruir la máquina en caso de necesidad, o crear un clon para hacer pruebas
+* Es una guía estupenda para saber cómo está configurada la máquina
+* También nos sirve de punto de partida para hacer copias de respaldo de la máquina
+
+Esta guía no tiene que ser algo más complicado que un fichero de texto plano elaborado a base de copiar y pegar con el bloc de notas. Recomiendo incluir enlaces web a la documentación que hayamos usado (manuales, HOWTOs, etc.), pero aún así incluir lo que hemos hecho (el referente puede desaparecer o cambiar). Personalmente utilizo Redmine[3], un sistema de gestión de proyectos que incluye un correcto wiki, que hace bastante cómodo mantener esta documentación.
+
+Con la guía podemos tranquilamente instalar en nuestra máquina virtual, hacer pruebas, etc. y luego ser capaces de reproducir el proceso (sin pasos en falso) en nuestra máquina en producción. Una herramienta útil que nos proporciona la virtualización son los snapshots. Fácil y cómodamente podemos guardar estados de la máquina y volver a ellos posteriormente. Esto nos permite experimentar y luego volver atrás rápidamente; así pues podemos experimentar sin miedo a "ensuciar" la máquina, tomando un snapshot antes de comenzar.
+
+Tras instalar, y en cuanto tengamos la guía para configurar nuestros servicios en producción, podemos realizar estas operaciones en nuestro entorno de producción y obtener un sistema limpio que cumple los requisitos.
+
+Una vez aquí, tenemos que ser capaces de:
+
+* Crear copias de respaldo. Fácilmente podemos programar copias del sistema con herramientas como cron, rdiff-backup, tar, etc. Partiendo de la documentación del sistema, debemos ser poder capaces de crear copias de toda la información del sistema que nos permitan restaurar el sistema en caso de desastre. Es conveniente que existan copias almacenadas de la manera más independiente del sistema original; física y geográficamente, pero también bajo otro "responsable"- si bien nuestro proveedor de hosting puede ofrecernos un sistema de copias de seguridad, puede ser conveniente almacenar copias también bajo nuestra propia propiedad o la de otro proveedor. También es importante verificar ocasionalmente las copias- un buen sistema es intentar reconstruir el sistema a partir de la documentación y las copias de seguridad en una máquina virtual
+* Actualizar. Debemos introducir en el sistema las actualizaciones (especialmente de seguridad) que vayan apareciendo, de la manera más simple posible. Existen sistemas que nos notifican o incluso pueden instalar las actualizaciones tal como aparecen automatizadamente. En un sistema muy estable tipo RHEL, puede ser válido instalarlas automáticamente dado el poco riesgo que suelen entrañar las actualizaciones. En otras situaciones es mejor recibir las notificaciones e instalar las actualizaciones manual y controladamente
+* Monitorización. Más allá de saber si los servicios están funcionando correctamente (algo a veces más problemático de comprobar de lo que parece), es interesante que recibamos notificaciones de los problemas y de ciertas métricas. Recomiendo siempre una herramienta como logwatch que nos envía un resumen diario de la actividad de la máquina. Una métrica muy interesante de monitorizar es el espacio en disco- si este se llena es un gran problema y es conveniente no dejar que suceda. Por supuesto, los errores en las copias de respaldo son otro punto muy importante. Estos temas se simplifican enormemente si podemos configurar el sistema para que pueda enviar correo con las herramientas estándar
+
+Con estos puntos cubierto, podemos dar un servicio que, pese a no ser completamente profesional, sin un uptime perfecto y sin redundancias, puede ser más que adecuado para la mayoría de los propósitos.
+
+
+=> gemini://alex.corcoles.net/2012/03/la-guia-del-autoestopista-galactico-a-la-administracion-de-sistemas-i/ 1: gemini://alex.corcoles.net/2012/03/la-guia-del-autoestopista-galactico-a-la-administracion-de-sistemas-i/
+=> https://www.virtualbox.org/ 2: https://www.virtualbox.org/
+=> http://www.redmine.org/ 3: http://www.redmine.org/
\ No newline at end of file
diff --git a/blog/content/2012/05/un-pc-enchufado-a-la-tele.gmi b/blog/content/2012/05/un-pc-enchufado-a-la-tele.gmi
new file mode 100644
index 00000000..fb98a754
--- /dev/null
+++ b/blog/content/2012/05/un-pc-enchufado-a-la-tele.gmi
@@ -0,0 +1,33 @@
+# Un PC enchufado a la tele
+2012-05-27
+
+Como todo buen informático que se precie, llevo un tiempo trabajando en un proyecto "PC enchufado a la tele". Detallo aquí un poco mi montaje actual.
+
+El punto de partida es uno de estos PCs pequeñitos con Atom. En mi caso escogí por disponibilidad un Giada SLIM-N10[1], con chipset Nvidia ION, que en teoría debería compensar la poca potencia del Atom para reproducir vídeo- dispone de descodificadores de vídeo que permiten reproducir ciertos formatos de vídeo por hardware, permitiendo ver vídeos 1080p suavemente.
+
+A este aparato le añadí un pequeño dongle Bluetooth y un teclado inalámbrico Bluetooth para controlarlo. Adicionalmente, amplié mi red con un par de dispositivos Powerline (los más baratos que encontré, 50€ el par); mi red inalámbrica no llega muy bien a la zona del televisor y la antena del Giada parece ser bastante horrible; la conexión no era nada estable y el ancho de banda bastante lamentable- el powerline, aún en malas condiciones, me da entre 3-5 megabytes/s de transferencias sostenidas sobre NFS. Esto no siempre da para streaming perfecto, especialmente de vídeos en HD, pero al menos permite copiar un vídeo para reproducción local rápida e indoloramente. Añadimos también una sintonizadora USB barata.
+
+Finalmente, conectamos el PC al televisor vía HDMI, lo que nos da 1920x1080 + audio y añadimos unos altavoces de escritorio conectados por jack de audio; esto nos da una segunda salida de audio que usaremos más adelante.
+
+En el software, escogimos Mythbuntu. MythTV parece ser la solución estándar para mediacenter con TDT (XBMC tiene arreglos para reproducir TDT, pero no parecen muy soportados). Dado que MythTV no está en Debian, parece apropiado usar Mythbuntu para instalarlo sobre Ubuntu, pues parece bastante usado y con una buena comunidad detrás.
+
+La instalación es indolora, lo único complicado fue la configuración de la sintonizadora, pues el modelo concreto que encontramos no está soportado directamente por Linux, pero existen instrucciones para hacerlo funcionar e integrarlo con DKMS[2] (con lo que se actualiza automáticamente con las actualizaciones del kernel). Hace falta un poquito de trasteo con MythTV para que el audio vaya por defecto por la salida HDMI y no por la salida de audio estándar y que utilice el ION para tratamiento de vídeo.
+
+A partir de aquí, añadimos MythWeb que nos da un interfaz web que permite ver la programación y programar grabaciones de programas con un interfaz muy práctico.
+
+Otra funcionalidad que añadimos es un servidor de MPD[3]. MPD es un reproductor de audio controlable por red, del que existen varios controladores; web, móvil, escritorio, etc. Configurándolo para que envíe su audio por la salida minijack, podemos encender los altavoces, usar nuestro PC/móvil/tablet para controlar la música sin tener que encender el televisor.
+
+También configuramos Mame, un emulador de máquinas recreativas que pese a la limitada potencia del procesador Atom funciona bastante bien.
+
+Otro añadido es configurar Flash para que utilice VDPAU, un interfaz que permite la reproducción de vídeo por hardware. Con esto, usando Chrome de escritorio podemos, por ejemplo, ver vídeos 1080p de Youtube suavemente; el teclado inalámbrico que usamos dispone de un minijoystick que podemos usar de ratón, con lo que podemos navegar sin mucho problema.
+
+Cosas de futuro en las que hay que investigar más:
+
+* Un mando inalámbrico que permita jugar a Mame sin usar el teclado Bluetooth. Podemos usar el mando de la PS3, pero sólo por USB- inalámbrico vía Bluetooth parece complicado de configurar e impráctico (al encender el mando se enciende automáticamente la PS3, etc.)
+* Un mando a distancia "normal" para controlar MythTV
+* x2vnc/Win2VNC para usar un PC normal como teclado y ratón, truco muy chulo y conveniente
+
+
+=> http://www.giada.com.au/store/SLIM-N10-B.php 1: http://www.giada.com.au/store/SLIM-N10-B.php
+=> http://linuxtv.org/wiki/index.php/Mygica_T1800B 2: http://linuxtv.org/wiki/index.php/Mygica_T1800B
+=> http://mpd.wikia.com/wiki/Music_Player_Daemon_Wiki 3: http://mpd.wikia.com/wiki/Music_Player_Daemon_Wiki
\ No newline at end of file
diff --git a/blog/content/2012/06/desarrollo-web-como-dios-manda.gmi b/blog/content/2012/06/desarrollo-web-como-dios-manda.gmi
new file mode 100644
index 00000000..ecb2e13b
--- /dev/null
+++ b/blog/content/2012/06/desarrollo-web-como-dios-manda.gmi
@@ -0,0 +1,60 @@
+# Desarrollo web como Dios manda
+2012-06-23
+
+Con la cantidad de faena a hacer en el mundo del desarrollo web, es natural preguntarse cosas como qué tecnología elegir y por dónde comenzar si uno quiere dedicarse a esto.
+
+No son preguntas triviales- la espectacularidad diversidad de plataformas, filosofías y frameworks intimida y lleva a pensar que no es posible tomar una buena decisión- es impracticable probar todas las alternativas y en las etapas iniciales de aprendizaje es difícil formarse una opinión razonada.
+
+En este post pretendo dar unos apuntes que espero sirvan para colocar a alguien en el buen camino.
+
+Una manera fácil de comenzar es por el lenguaje. Es conveniente que escojamos un lenguaje que cumpla las siguientes características:
+
+* Popular
+* Con tracción para el desarrollo web
+* De calidad
+
+Comenzando por el principio, un buen punto de partida es mi querido TIOBE[1]. El TIOBE es un ránking de la popularidad de los lenguajes de programación calculado a partir de su presencia en la web. La metodología es inevitablemente discutible, pero el ránking está bastante alineado con mi percepción, así que para mi, es una opción cómoda.
+
+En el top 20 (a junio de 2012) encontramos tan solo 8 lenguajes utilizados comunmente para el desarrollo web: Java, C#, PHP, Python, Perl, Ruby, Javascript y Visual Basic .NET. Fuera del Top 20 encontramos muy poquitas opciones (Haskell, Scala y poco más), así que nos ceñiremos a estos.
+
+Vamos a descartar unos pocos:
+
+* PHP[2]: pese a ser un lenguaje explícitamente diseñado para el desarrollo web, en mi opinión PHP nunca debe usarse para desarrollar un proyecto desde 0- a no ser que lo que queramos desarrollar sea extremadamente mínimo- ya sea porque se trate de un desarrollo extremadamente pequeño o bien que pretendamos reutilizar completamente un desarrollo existente como Wordpress o Magento. Desarrollar grandes bases de código en PHP es un ejercicio frustrante ya que, sencillamente, no está pensado para ello. Sus limitaciones en cuanto a modelo de ejecución, estructura y modularidad son motivo suficiente para descartarlo, pues el resto de lenguajes que consideramos lo superan ampliamente en estos aspectos, ofreciendo PHP muy poco para compensar (su velocidad para proyectos mínimos).Puede sernos útil conocer PHP, pues existe mucho trabajo manteniendo código PHP (sin embargo, no se trata de un trabajo especialmente gratificante) y en algún momento nos puede ser útil. Pero debe ser erradicado lo antes posible.
+* Perl[3]: durante mucho tiempo fue una de las mejores opciones disponibles, en realidad, una de las pocas viables. Una vez más, el resto de lenguajes de la lista le superan en virtudes sin que Perl ofrezca muchas ventajas propias. El mercado de Perl decae lentamente y cada vez se inician menos proyectos que lo utilicen.
+* JavaScript[4]: si bien deberemos conocer JavaScript para desarrollar efectivamente sobre la web, aún no lo considero una opción viable en el lado servidor. Tendremos que aprender JavaScript, pero el grueso del proyecto deberá ser siempre en otro de los lenguajes. Soy anti-aplicaciones web 100% Javascript, creo que su campo de aplicación es extremadamente limitado y presentan desventajas considerables, pero hay quien les encuentra virtudes
+
+C#[5] y Visual Basic .NET[6] son dos opciones que el lector mismo puede escoger descartar o considerar- desarrollar razonablemente en ambos supone unos costes que yo prefiero no asumir (se necesitan licencias de Windows para el desarrollo y despliegue y las versiones gratuitas de Visual Studio tienen bastantes limitaciones)- a parte de que soy un firme creyente en que las herramientas de desarrollo deben ser libres y gratuitas. Si eso no supone un impedimento para el lector, puede aplicar mi opinión sobre Java, ambas plataformas son extremadamente similares; quizás .NET goce de herramientas más sencillas de utilizar inicialmente, el sistema base es más completo que el de Java pero el ecosistema goza de menor vida.
+
+Por tanto, nos quedamos con Java, Python y Ruby. Los dos factores más diferenciales entre los tres para mi son:
+
+* Python[7]cuenta con el framework Django[8], que a su vez goza del "Admin". El Admin es un desarrollo genérico que implementa un sistema de gestión de modelos web genérico muy sofisticado, que nos permite definir las entidades con las que trabaja nuestra aplicación (e.g. en una web de contenidos, artículos, categorías, etc.) y obtener prácticamente sin esfuerzo una interfaz de gestión bastante buena que permite a los usuarios gestionar los objetos, añadiendo un sistema de permisos más que aceptable (i.e. podemos decir que los reporteros pueden crear y editar sus artículos y que los administradores pueden crear y gestionar secciones). Dado que en la mayoría de los proyectos se necesita una funcionalidad así y Django nos la proporciona sin dedicarle apenas tiempo (y desarrollar algo de ese calibre es considerablemente costoso), para muchos proyectos Django nos puede ahorrar muchísimo tiempo de desarrollo tedioso, dándonos una gran ventaja.Puede parecer que otras plataformas cuentan con cosas similares (e.g. Roo en Java, el scaffolding de Rails), pero no están a la altura.
+* Java[9]es el único de los lenguajes que cuenta con tipado estático. El tipado estático (deber declarar explícitamente el tipo de las variables) parece un problema (debemos "perder tiempo" especificando tipos), pero en realidad no lo es (uno ya razona sobre el tipo que debe tener una variable, escribirlo explícitamente no es costoso) y en cambio permite la existencia de herramientas sofisticadas que trabajen sobre el código. En los lenguajes dinámicos, por poner un ejemplo, es extremadamente laborioso localizar dónde se utiliza un determinado trozo de código, algo necesario para tareas como eliminarlo (debemos asegurarnos que no exista otro código que lo utilice y adaptarlo si existe) o modificarlo (debemos asegurarnos que adaptamos el código que lo utilice), tenemos que buscar las referencias por todo el código y esto puede ser extremadamente problemático si la búsqueda no es muy específica (i.e. si tenemos un campo llamado "página" en un objeto concreto, una búsqueda de texto nos reportará usos de "página" en clases no relacionadas, o que contengan "página"), pues podemos tener una cantidad de falsos positivos muy elevada fácilmente.Esto propicia que los cambios en el código sean mucho más trabajo del que debiera. En cambio, en un lenguaje estático es posible implementar búsquedas muy exactas gracias a la presencia de tipos en el código fuente (básicamente, la herramienta puede discernir si la referencia que buscamos es la que encuentra con exactitud). En Java el compilador nos avisará si un cambio/eliminación rompe código, y las herramientas nos pueden localizar exactamente todas las referencias a un trozo de código. Adicionalmente, las herramientas no se quedan aquí, sino que implementan funcionalidades similares mucho más avanzadas y potentes que no pueden ser implementadas efectivamente sobre lenguajes dinámicos.
+
+En mi opinión, ambas herramientas deben estar en el arsenal de un desarrollador web. Python + Django para proyectos sencillos o en los que el Admin de Django suponga una gran ventaja, y Java para proyectos grandes y complejos. Python nos da agilidad y el Admin y Java nos da la potencia para desarrollar sistemas complejos.
+
+Por supuesto, la cosa no se queda aquí. El desarrollo web requiere unos conocimientos de base; más allá de los conocimientos de programación estándar (que obviamente son necesarios), necesitaremos conocer:
+
+* El protocolo HTTP, el "alma" de las comunicaciones web
+* HTML + CSS, con los que desarrollamos la capa visual de la aplicación
+* JavaScript para las funcionalidades que lo requieran (con jQuery[10])
+
+Seguramente también necesitaremos un mecanismo de persistencia (donde SQL es la opción más popular, yo recomendaría usar PostgreSQL y evitar el popularísimo MySQL pero infame) y conocimientos básicos de sistemas (deberíamos saber hacer funcionar un servidor web, la base de datos, etc.).
+
+Con todo esto podríamos desarrollar alguna web sencilla con Django, que nos proporciona una plataforma bastante completa y bien documentada con la que podremos implementar bastantes proyectos.
+
+Una vez asentados los fundamentos del desarrollo web, podemos comenzar a investigar Java. Java no es como Django, que incluye prácticamente todo lo necesario en un sencillo paquete y, una vez más nos plantea unos problemas de decisión importantes. Lamentablemente, desconozco una buena referencia completa y vertical de desarrollo Java que ofrezca un stack completo comparable al de Django. Mi recomendación sería partir de Java, añadir Spring (el mecanismo de inyección de dependencias, su librería de JDBC y el motor MVC) y JSP, todo corriendo sobre un contenedor como Jetty o Tomcat (que se integre en nuestro entorno de desarrollo), utilizando Eclipse y Maven para la compilación. Desgraciadamente es una solución más compleja para la parte inicial (y muchas de ellas se deben aprender prácticamente simultáneamente, incrementando la dificultad), pero adoptando todas estas tecnologías tendremos una base similar a la de Django. El camino es mucho más largo, pero nos ofrece una alternativa más apropiada para grandes proyectos.
+
+Lógicamente, esta es una vía "ideal". Quizás no debe completarse completamente, si no hemos de trabajar en proyectos muy complejos Java es una exageración, o bien la vida nos lleve a sumergirnos en otras tecnologías, pero es un recorrido completo. Si no llegamos a Java (o incluso si llegamos), puede ser conveniente pasar tiempo usando algún microframework que no nos dé un stack completo como el de Django, Django nos lo da casi todo mascado y seguramente hay detalles interesantes de conocer a bajo nivel que nos perdamos. Hacer desarrollo web sin un stack completo ciertamente puede ayudarnos a completar nuestras habilidades. Podemos hacer esto tanto en Python (usando un microframework de los muchos existentes, o incluso desarrollando el nuestro) como en Java (programando directamente servlets en vez de usar el MVC de Spring) o en cualquier otro lenguaje.
+
+=> https://www.tiobe.com/tiobe-index/ [1] El índice TIOBE
+=> https://www.php.net/ [2] PHP
+=> https://www.perl.org [3] Perl
+=> https://en.wikipedia.org/wiki/JavaScript [4] JavaScript
+=> https://docs.microsoft.com/en-us/dotnet/csharp/ [5] C#
+=> https://docs.microsoft.com/en-us/dotnet/visual-basic/ [6] Visual Basic .NET
+=> https://www.python.org/ [7] Python
+=> https://www.djangoproject.com/ [8] Django
+=> https://www.oracle.com/java/ [9] Java
+=> https://jquery.com/ [10] jQuery
+
+=> http://obm.corcoles.net nota: más ediciones y sugerencias del de siempre
diff --git a/blog/content/2012/06/grandes-responsabilidades.gmi b/blog/content/2012/06/grandes-responsabilidades.gmi
new file mode 100644
index 00000000..4846ae65
--- /dev/null
+++ b/blog/content/2012/06/grandes-responsabilidades.gmi
@@ -0,0 +1,55 @@
+# Grandes responsabilidades
+2012-06-05
+
+Con el megapelotazo que ha supuesto los Vengadores (ya sólo a la zaga de Avatar y la inalcanzable Titanic- James échame una limosna, anda) quizás sea el momento de echar la vista atrás y soltar una sesuda reflexión sobre el "género".
+
+¿Son las pelis de superhéroes un "género" siquiera?
+
+Lo mismo supongo que se preguntarán los que piensan demasiado sobre los westerns; entre una con un John Wayne bonachón, una de Leone, Sin Perdón o Arma Joven, es difícil encontrar nada en común que no sea la época- y aún así no nos es difícil encontrar westerns como Atmósfera Cero o Firefly/Serenity ambientados en el espacio o pensar que si Yojimbo y Por Un Puñado de Dólares son básicamente la misma película, ambos deberían ser westerns, ¿no?
+
+Con las pelis de superhéroes pasa lo mismo. Yo calificaría Los Vengadores como la primera peli de superhéroes de divertimento relevante- quizás la forma verdadera de las pelis de superhéroes... ¿pues no es decir "Hulk, machaca" la auténtica esencia de los cómics de superhéroes? (Quizás otras películas, en particular Green Hornet, de Gondry, o incluso la reciente Thor, se inscriben en esta corriente, pero son sin duda obras menores). No es casual que Joss Whedon, al mando del cotarro, sea guionista habitual de Marvel y DC y haya sido precisamente él quien nos haya brindado una experiencia que hasta el momento se les había escapado a todos. Lamentablemente, la cinta cojea en ocasiones,  en mi opinión sobre todo por un exceso de escala que se le escapa en ciertos momentos a Whedon y quizás una cierta falta de ritmo a ratos (quizás por el desigual elenco de personajes).
+
+Otras cintas, de tanto o mayor calado, han ido por otros derroteros. La que es para mí la mejor película de superhéroes, X-Men 2 de Brian Singer (Sospechosos Habituales), pese a enseñarnos a mucha gente con trajes de superhéroes, no tiene apenas escenas de acción (aunque sus dos piezas principales, la introducción con Rondador Nocturno y el asalto a la Mansión de Xavier, son absolutas obras maestras del cine de acción) y se desenvuelve entre el thriller, la cinta de acción prácticamente convencional (recordemos que mucha acción está poblada de gente sin superpoderes y que, desde luego, la escala es mucho menor que Los Vengadores) y la vertiente social típica de los X-Men. Por supuesto la guinda son unos personajes perfectamente dibujados gracias a las excelentes interpretaciones de Ian McKellen, Brian Cox (Stryker) e incluso un acertadisimo, aunque secundario, John Allerdice (Pyro).
+
+Hellboy (Benicio del Toro) en cambio, parte de un cómic más atípico (Hellboy es más un detective de lo oculto que un tipo con mallas que vuela). Como en X2 las interpretaciones (merecidísimo triunfo de Ron Perlman con excelentísima contrapartida de Selma Blair) son el atractivo principal de la cinta, así como una narración y un estilo propio que combinan muy bien un cine "de autor" con cine de acción más que correcto.
+
+En otra nota, Watchmen parte de una obra que tiene superhéroes, pero que se encuadra en un género más reflexivo y analítico; Watchmen sí es descaradamente un estudio sobre la condición humana que utiliza los vigilantes enmascarados y un superpoderoso tal y como Asimov usa a los robots para hablar de las personas (y de pasada, de los superhéroes, sí). Curiosamente Watchmen ya era prácticamente más storyboard que tebeo y estoy indeciso a la hora de valorar el trabajo de Zack Snyder e incluso de los actores- ¿hacen algo más que darle movimiento a la obra de Moore y Gibbons?
+
+Aparte queda alguna rareza- yo destacaría el Hulk de Ang Lee, un preciosista experimento de montaje y fotografia que, pese a que seguramente es insostenible, representa quizá el más acertado acercamiento visual a los cómics; deja a Watchmen en el aspecto visual al nivel del betún. La peli, desgraciadamente, salvo este superlativo montaje de viñetas, poco más tiene que ver con los cómics o los superhéroes. Complejo de Edipo + Super Mario Bros como argumento más unas interpretaciones poco inspiradas lastran mortalmente la película.
+
+¿Es casual que dentro de las pelis más destacables encontremos reconocidos autores? Tim Burton, Christopher Nolan o incluso Kenneth Branagh (¡sí, amigos, recuerden que firmó Thor!) se han metido en el género con desiguales resultados: no, no todas las pelis de superhéroes son bazofia (y desde luego, pocas son realmente buenas). Sí, es un "género" de estos denostados, como los westerns lo pueden haber sido en ocasiones, o la ciencia ficción o las pelis de tiros o de patadas voladoras, pero desde luego que no merece ser despreciado. Por suerte para los aficionados, con los éxitos comerciales y la abundancia de material por adaptar, tendremos películas para rato...
+
+De bonus, un ránking. Yo consideraría The Punisher (1989, la de Dolph Lundgren) como la frontera entre lo aceptable y lo malo (más que nada porque a día de hoy no sé si me gusta de lo mala que es, no es tan mala como parece o si simplemente es mala).
+
+1. X2
+2. Iron Man
+3. Hellboy
+4. Watchmen
+5. The Dark Knight
+6. The Avengers
+7. Hulk (2003)
+8. Batman
+9. Spider-Man 2
+10. X-Men
+11. Batman Begins
+12. Spider-Man
+13. Batman Returns
+14. X-Men Origins: Wolverine
+15. X-Men: The Last Stand
+16. The Punisher (1989)
+17. Thor
+18. Blade
+19. Elektra
+20. The Green Hornet
+21. Fantastic Four
+22. The Green Lantern
+23. Daredevil
+24. Superman Returns
+25. The Incredible Hulk
+26. Superman
+27. Spider-Man 3
+
+(correcciones y retoques importantes del de siempre[1], que como siempre evita que escriba sin ninguna revisión)
+
+
+=> http://obm.corcoles.net 1: http://obm.corcoles.net
\ No newline at end of file
diff --git a/blog/content/2012/06/porque-django-no-es-la-solucion-definitiva.gmi b/blog/content/2012/06/porque-django-no-es-la-solucion-definitiva.gmi
new file mode 100644
index 00000000..398b53f4
--- /dev/null
+++ b/blog/content/2012/06/porque-django-no-es-la-solucion-definitiva.gmi
@@ -0,0 +1,40 @@
+# Porqué Django no es La Solución Definitiva
+2012-06-02
+
+Hace tiempo ya explicaba por aquí las virtudes de Django[1]. En  resumen, se trata de un framework de desarrollo en web Python que implementa un interfaz de administración prácticamente automático a un esquema relacional. Vaya, que defines tus tablas y genera un interfaz dinámico para editar registros que te ahorra una barbaridad de tiempo (como podrá atestiguar cualquiera que haya tenido que hacerse uno).
+
+Tras llevar más tiempo trabajando con Django, sigo convencido que en estos momentos es la mejor solución que existe para desarrollo web basado en CRUD sobre bases de datos; el admin no tiene equivalente alguno que yo conozca, y desarrollarse un sistema similar es extremadamente costoso.
+
+Sin embargo, creo que he aislado unos cuantos defectos clave que hay que tener en cuenta antes de comenzar a usarlo.
+
+1. 
+
+Si usamos un esquema donde queramos que la edición de un registro tenga más de un nivel de indirección, el admin no soluciona esto. Pongamos por caso que tenemos una entidad "Empleado" , otra entidad "Proyecto" y una entidad intermedia que nos representa las asignaciones de Empleados a Proyectos (por ejemplo, en esta relación intermedia podríamos querer almacenar el tiempo durante el cual el Empleado está asignado al Proyecto, su porcentaje de dedicación a él, etc.). Podremos añadir un fantástico TabularInline que nos muestre las asignaciones de Empleados dentro de la vista de detalle de Proyecto, pero no hay manera de que se pueda editar el Empleado desde la vista detalle de Proyecto; podremos editar la relación intermedia (primer nivel de indirección), pero la segunda ya no.
+
+Esto nos limita bastante el interfaz sobre esquemas de datos moderadamente complejos que nos podemos encontrar fácilmente en el mundo real; cuando tengamos estos esquemas tendremos que...
+
+1. Hackear el admin como podamos para que nos permita hacer las ediciones
+2. Buscar a alguien que haya implementado algún plugin que nos añada en esto
+3. Ignorar el admin e implementarlo nosotros mismos
+4. Simplificar nuestro esquema
+
+Ninguna de las tres soluciones es mínimamente satisfactoria
+
+2. 
+
+El admin necesita más hipervínculos. En particular, la fantástica funcionalidad de los raw_id_fields, nos permite hacer que los campos clave foránea de nuestras entidades se puedan editar con un popup selector excelente, pero no nos permite saltar a la entidad enlazada. Una de las grandes virtudes de usabilidad de la web son los enlaces, y nos serían extremadamente útiles en más lugares del admin
+
+3. 
+
+Django no proporciona suficiente potencia en el SQL subyacente a su ORM. En particular, sería harto conveniente poder disponer de, o bien un inspectdb más potente que nos permita trabajar continuamente con él (añadir campo en nuestra base de datos y que inspectdb añada dinámicamente el campo al modelo), o un mecanismo para poder personalizar automatizadamente el esquema generado; esto principalmente nos debería permitir implementar una "estrategia" de nombrado de tablas y columnas que nos permita, por ejemplo, que los nombres de tablas sean plurales o cambiar el nombre de las claves primarias surrogadas que Django añade automáticamente.
+
+Si no nos gustan los esquemas que genera Django automáticamente (y no deberían gustarnos), las alternativas son o aguantarnos, o especificarle repetidamente los nombres de tablas y columnas que debe usar o hackear Django para que haga lo que queramos. Una vez más, esto no es del todo satisfactorio.
+
+4. 
+
+A un nivel más profundo, el código de Django no es muy amigable a la extensión. Es bastante complicado añadir funcionalidad derivando de las clases de Django; el código no siempre es fácil de seguir (ya que usa bastantes metaclases y otras pythonicidades de las que no soy muy fan) ni tiene un diseño orientado a objetos muy elaborado- se echa en falta que ciertas funcionalidades estén, como mínimo, aisladas en un propio método que podamos sobreescribir para cambiarlas (o utilizar el patrón estrategia, idealmente). Siempre nos queda la opción de forkear, pero esto no es muy mantenible, o hacer monkey-patching, lo que tampoco es muy recomendable ni mantenible.
+
+Pese a todos estos puntos, sigo pensando que el admin de Django es realmente algo único que nos puede ahorrar muchísimo trabajo y proporcionar un resultado de gran calidad para muchos, muchísimos proyectos. Pero aún es mejorable- y con unas pocas mejoras localizadas podría mejorar muchísimo.
+
+
+=> gemini://alex.corcoles.net/2011/01/django-o-la-fabrica-de-churros/ 1: gemini://alex.corcoles.net/2011/01/django-o-la-fabrica-de-churros/
\ No newline at end of file
diff --git a/blog/content/2012/06/what-if-php-y-mysql-nunca-hubieran-existido.gmi b/blog/content/2012/06/what-if-php-y-mysql-nunca-hubieran-existido.gmi
new file mode 100644
index 00000000..03da92fc
--- /dev/null
+++ b/blog/content/2012/06/what-if-php-y-mysql-nunca-hubieran-existido.gmi
@@ -0,0 +1,44 @@
+# What if... PHP y MySQL nunca hubieran existido?
+2012-06-09
+
+Marvel tenía (o tiene, estoy tremendamente desactualizado) un cómic titulado "What if...?" que trataba de qué pasaría en los universos Marvel si algún acontecimiento clave hubiese seguido otro curso. Así pues, podíamos leer cosas como qué hubiese pasado si Spider-Man hubiese sucumbido al simbionte o Gwen Stacy no hubiera muerto.
+
+Yo, la verdad, prefería "What the...?", que trataba de situaciones absurdas, pero bueno.
+
+El ejercicio que me propongo hoy es "What if... PHP y MySQL nunca hubieran existido?"
+
+PHP y MySQL fueron en su momento las estrellas del desarrollo web. PHP[1] surgió de un proyecto personal de Rasmus Lerdorf[2] inicialmente publicado en 1995, que según el TIOBE[3], comenzó a dispararse en popularidad allá por 2002 y gozó de su mejor momento entre 2005 y 2010, donde inició un aparente declive (seguramente por el ascenso de otros lenguajes/frameworks para la web menos demenciales). MySQL[4] empezó como proyecto en 1994 y su primera publicación fue (la Wikipedia no es muy específica en este asunto) entre 1995 y 1998—no encuentro buenas fuentes sobre su ascenso a la fama, pero yo lo situaría aproximadamente por la misma época que el de PHP, y sin que se atisbe una caída en su popularidad (si no contamos su adquisición por parte de Oracle en 2010 y la relativa proliferación de forks).
+
+No es casual, claro, que la web explotara justo en ese momento, entre 1996 y 1998, y que los dos estuvieran en el sitio exacto, en el momento exacto para formar la MP de LAMP[5]. En un momento en el que no había una abundancia de herramientas de desarrollo web decentes (Perl[6] era probablemente la alternativa abierta más popular; los servlets de Java son del 97, pero por ejemplo hasta 1999 no existió Tomcat; ASP[7] de Microsoft data de 1998... no había muchas más cosas y por supuesto, gran parte de lo que hoy está de moda en aquella época ni existía), PHP/MySQL era una tupla muy accesible para desarrollo web —fácil de instalar, fácil de comenzar y fácil de obtener resultados rápidos— y sin mucha competencia que hiciese destacar sus defectos. Esto llevó a que prácticamente todo el segmento "no profesional" y una parte importante del profesional se volcasen en esta plataforma (las "MS Shops", por supuesto, apostaron por ASP y mucha gran empresa se fue a Java) y posteriormente, como suele suceder, el sector no profesional arrastrase al profesional.
+
+Sin embargo, hoy en día PHP está bastante denostado. Se le sigue reconociendo como vía "rápida y sucia" y goza de una inercia considerable (sobre todo, por la abundancia de mano de obra y código existente a mantener), pero puede decirse que ha pasado de moda y que sus abundantes defectos le están pasando factura; prácticamente podría decirse que Facebook es su único usuario de gran perfil (y con importantes peros). MySQL, en cambio, sigue relativamente saludable, sigue siendo extremadamente popular y, pese a que el sector crítico parece crecer día a día, no parece que vaya a ser eclipsado en breve.
+
+¿Qué hubiera pasado si Rasmus Lerdorf se hubiera avergonzado de su pequeño monstruo y hubiese decidido mantenerlo en el sótano oscuro y lúgubre que nunca debió abandonar? ¿Y si MySQL no hubiese tenido su vertiginosa aceptación, quizás por una mala fama alimentada por alguna deflagración especialmente notable?
+
+Probablemente, el mundo web hubiese sufrido algún retraso. Perl, Java o ASP no eran suficientemente accesibles en ese momento como para tomar el relevo (por diversos motivos: de coste en el caso de ASP, de accesibilidad para Java y Perl). Lo más probable es que Perl hubiese ganado bastante terreno y  hoy en día gozase de más popularidad, incluso entre los imberbes. ¿Se hubiese adelantado algún framework como el popular Ruby on Rails[8]? Yo creo que no; Rails surge ya en 2005 y no creo que se hubiese acelerado mucho su aparición en caso de haber existido un vacío. Simplemente, hubiésemos visto otros frameworks nuevos sobre algún lenguaje existente, o quizás algún framework que el tiempo olvidó habría sido adoptado masivamente. Apostaría por que Python[9], que explotó en popularidad en 2004, hubiera cubierto el vacío de PHP con algún framework.
+
+¿Consecuencias? Sí, la web retrasada 2-3 años. Probablemente los titubeos propios de PHP se hubiesen trasladado a su sustituto (algún framework sucio y bizantino de Python se habría impuesto), o quizás (Dios no lo quiera) Perl hubiese arrasado y hoy en día estaríamos condenados a prefijar todo con sigilos (pero seguramente con un framework elegante). La versión optimista (para mí) es que la web como plataforma de aplicaciones no hubiese tenido su auge y nos hubiéramos quedado mayormente en la web de contenidos y el modelo de aplicaciones de escritorio... y con toda probabilidad esto habría supuesto un buen bofetón para Linux y en menor medida para Apple (las aplicaciones web son prácticamente automáticamente multiplataforma). ¿Sería esto positivo? Por una parte, uno es de los que suscribe que nunca debimos apostar por la web para aplicaciones (sí, desde luego, para contenidos) y que quizás buen número de informáticos no tendrían que haber lidiado con los problemas de la web para este propósito y destinado su tiempo a cosas más útiles: siendo optimistas, quizá hoy tendríamos aplicaciones de escritorio multiplataforma de despliegue indoloro (e.g. Java y Web Start, pero bien) y todo sería más de color de rosa. El reverso de la moneda sería un monocultivo Microsoft y todos estaríamos desarrollando en Visual Basic (y no, no el .NET), claro está.
+
+A un nivel más elevado y más del mundo real, igual las burbujas web y sociales no hubieran nacido ni estallado nunca. Habría más desarrollo informático empresarial tradicional con el aburrimiento y la solidez consiguientes.
+
+Por otra parte, creo que la historia no habría cambiado sustancialmente sin MySQL. PostgreSQL[10] seguramente ocuparía su lugar, llevándonos a un mundo con más integridad referencial y donde nuestros datos serían un pelín menos volátiles. Defiendo que el movimiento NoSQL hubiera dado un pequeño paso atrás. Sí: con o sin web de aplicaciones y todo eso, Google hubiera existido y hubiese necesitado BigTable[11]/MapReduce[12] (es el contenido lo que es difícil de indexar). Pero parte de la necesidad de NoSQL viene de las deficiencias de MySQL y no del modelo relacional (adicionalmente, este no estaría tan desprestigiado y probablemente serían más de cuatro gatos los que sabrían sacarle partido). Y es que resulta difícil encontrar una implementación peor de SQL que MySQL (si no contamos SQLite[13], claro, pero ese juega en otra liga).
+
+Cuesta imaginar un efecto real de la no existencia de MySQL: quizás eso quiera decir que pese a que PHP haya caído antes, quizás éste haya sido más instrumental y relevante en el mundo real. MySQL simplemente ofrecía "funciona en Windows y no hay otro popular" (lo de la velocidad son historias); PHP era "tu web, ahora y sin complicaciones". Uno pensaría también que los deméritos de PHP son menores que los de MySQL: pese a que ambos son sucios y volátiles, opino que PHP es más sucio que volátil, mientras que MySQL es más volátil que sucio... y en informática, lo sucio es doloroso pero inevitable, mientras que lo volátil puede causar daños corporales permanentes.
+
+(correcciones, ediciones y sugerencias del de siempre[14])
+
+
+=> http://www.php.net/ 1: http://www.php.net/
+=> http://es.wikipedia.org/wiki/Rasmus_Lerdorf 2: http://es.wikipedia.org/wiki/Rasmus_Lerdorf
+=> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html 3: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
+=> http://www.mysql.com/ 4: http://www.mysql.com/
+=> http://es.wikipedia.org/wiki/LAMP 5: http://es.wikipedia.org/wiki/LAMP
+=> http://www.perl.org/ 6: http://www.perl.org/
+=> http://es.wikipedia.org/wiki/Active_Server_Pages 7: http://es.wikipedia.org/wiki/Active_Server_Pages
+=> http://rubyonrails.org/ 8: http://rubyonrails.org/
+=> http://www.python.org/ 9: http://www.python.org/
+=> http://www.postgresql.org/ 10: http://www.postgresql.org/
+=> http://es.wikipedia.org/wiki/BigTable 11: http://es.wikipedia.org/wiki/BigTable
+=> http://es.wikipedia.org/wiki/MapReduce 12: http://es.wikipedia.org/wiki/MapReduce
+=> http://www.sqlite.org/ 13: http://www.sqlite.org/
+=> http://obm.corcoles.net/ 14: http://obm.corcoles.net/
\ No newline at end of file
diff --git a/blog/content/2012/07/cuanto-rato-se-tarda-en-montar-un-entorno-de-desarrollo-web-java.gmi b/blog/content/2012/07/cuanto-rato-se-tarda-en-montar-un-entorno-de-desarrollo-web-java.gmi
new file mode 100644
index 00000000..23d4c42a
--- /dev/null
+++ b/blog/content/2012/07/cuanto-rato-se-tarda-en-montar-un-entorno-de-desarrollo-web-java.gmi
@@ -0,0 +1,31 @@
+# ¿Cuánto rato se tarda en montar un entorno de desarrollo web Java?
+2012-07-07
+
+Una de las quejas más comunes sobre desarrollar en Java es lo complejo que resulta montarse el entorno de desarrollo. Ciertamente, la situación hace años era un poco rollo; grandes descargas del JDK perdido entre las tinieblas, Eclipse por piezas difícil de instalar...
+
+¿Cuál es la situación actual? ¿Sigue siendo tan complejo? ¿Los anchos de banda más anchos de hoy en día ayudan?
+
+Para el propósito de este ejercicio, cogeré un Windows sin nada instalado e instalaré todo lo necesario para poder desarrollar un servlet "Hola, Mundo", con Eclipse (el entorno de desarrollo gráfico gratuito para Java más común).
+
+Los pasos que deberemos realizar son los siguientes
+
+1. Ir a la página de Oracle, Downloads, Popular Downloads, Java for Developers, JDK, Aceptar la licencia y escoger la versión adecuada (en mi caso Windows x64)... 1 minuto
+2. Descargar los 92mb... 7 minutos
+3. Ejecutar el instalador... 3 minutos (+2 minutos de JavaFX que instala por defecto)
+4. Ir a la página de Eclipse, Download Eclipse, Eclipse IDE for Java EE Developers, escoger la versión adecuada (Windows 64 bits)... 1 minuto
+5. Descargar los 221mb... 16 minutos
+6. Abrir el .zip y extraerlo (en mi caso, a mi carpeta de usuario c:\users\alex, creándose una carpeta dentro c:\users\alex\eclipse)... 4 minutos
+7. Arrancar Eclipse (en mi caso c:\users\alex\eclipse\eclipse.exe), escoger la ubicación por defecto del workspace (y marcar que no vuelva a preguntar), crear un "dynamic web project", escoger crear un nuevo runtime de Tomcat 7.0 (y darle una ruta, se lo baja y lo instala [unos 8mb]), decirle que nos genere un web.xml, hacer un click con el botón derecho y sobre la sección de servlets y decirle que nos cree uno, todo por defecto, implementar el método doGet haciendo un response.getOutputStream().print("Hello world");, hacer click derecho en el proyecto,  run as, run on server, hacer que corra en el Tomcat 7 que hemos creado anteriormente, editar la URL del navegador que se nos abra para que se corresponda a la ruta donde hemos mapeado el servlet y cargarlo ... todo unos 7 minutos
+
+En total, unos 40 minutos de los que unos 25 son unos 320mb de descargas. Lógicamente con una conexión más rápida (tengo una de 3 megabits) y sin la virtualización, que obviamente penaliza el rendimiento, podría reducirse un poco.
+
+A destacar que el proceso tradicionalmente más complejo, instalar el Tomcat y configurarlo para que se pueda usar desde el Eclipse, ha sido simplificado por la gente de Eclipse haciendo que instalarlo y autoconfigurarlo directamente al crear un proyecto sea bastante sencillo (el interfaz no es 100% intuitivo y me ha costado un pelín entenderlo, pero bueno).
+
+Por supuesto, este es un proceso mínimo usable; yo preferiría añadirle:
+
+* Instalación de egit, que sorprendentemente en la versión Java EE de Eclipse no viene cuando otras variantes de Eclipse lo traen por defecto (4 minutos de instalación desde Eclipse Marketplace, incluyendo un reinicio)
+* Instalación de m2eclipse y su plugin para WTP, que nos permite configurar proyectos usando Maven, un sistema bastante estándar de gestión de dependencias (6 minutos de instalación desde Eclipse Marketplace, con otro reinicio)
+
+, y por supuesto, que esto nos instala un sistema de desarrollo "pelado" sin framework, cuando lo recomendable es no desarrollar servlets "a pelo" si no usar algún framework como Spring. Pero esto lo trataremos en otra entrega...
+
+O sea, que podemos montar un entorno de desarrollo, con servidor de aplicaciones y entorno gráfico integrado en menos de una hora. ¿Es mucho, poco? ¿Cuánto se tarda con otras plataformas de desarrollo? ¿Es realmente un factor que eche para atrás de desarrollar con Java? ¿O son otros factores?
\ No newline at end of file
diff --git a/blog/content/2012/07/si-sigo-usando-una-blackberry.gmi b/blog/content/2012/07/si-sigo-usando-una-blackberry.gmi
new file mode 100644
index 00000000..2620e7d8
--- /dev/null
+++ b/blog/content/2012/07/si-sigo-usando-una-blackberry.gmi
@@ -0,0 +1,24 @@
+# Sí, sigo usando una Blackberry
+2012-07-04
+
+Hace eones apunte por aquí[1] que me pasaba a Blackberry, esa compañía que en aquel momento estaba apunto de extinguirse y ahora lo está mucho más. Allí indicaba las razones por las que escogía y por qué en aquel momento estaba muy contento.
+
+Sorprendentemente, y supongo que en gran parte porque me encanta llevar la contraria, un año después sigo muy contento.
+
+Sí, es básicamente el teclado. Sigo detestando cada palabra que tengo que aporrear sobre un cristal; he usado iPads, iPhones y todo tipo de Androids esporádicamente y sigue siendo una experiencia frustrante. Es harto probable que haya un prejuicio ahí y que si me sumergiese en el mundo táctil, me acabaría acostumbrando; pero, ¿por qué debería someterme a tal tortura?
+
+Indudablemente, la Blackberry tiene una larguísima lista de defectos, pero al fin y al cabo cubre mis necesidades a la perfección:
+
+* Puedo usar mensajería/redes sociales de todo tipo sin problemas; tengo los clientes que importan (Whatsapp, Twitter, Facebook, Google Talk y email) que funcionan perfectamente y que se benefician inmensamente del teclado
+* El navegador soporta el Google Reader de iPhone perfectamente, lo que cubre el 80% de mis necesidades de navegación (y en general me permite leer lo que quiero leer perfectamente adaptado a móvil desde el mismo Google Reader. La gente con feeds incompletos a veces me fuerza a ir a páginas que se le atragantan al navegador... no es frecuente pero sucede, pero se resuelve rápido con una estrellita). El resto, la mayoría del tiempo son sitios que tienen versión móvil (webs de noticias, Wikipedia, etc.).
+* GPS entre la app de Blackberry y la de Google es aceptable. El Google Maps de Blackberry tiene una búsqueda lenta y lamentable, pero se sobrevive
+* La cámara no es como para hacer fotografía profesional, ni mucho menos, pero lo suficiente como para sacarle fotos al gato y a las chorradas que uno ve por ahí
+* Es cierto, casi no hay apps, pero hay las que me importan (Tumblr, Wordpress, cartelera, Endomondo, lista de la compra, ...)
+* El frikismo ocasional (y gratuito) se ve complacido por poder tener un ssh como Dios manda y un teclado que permite meter símbolos, no-palabras y combinaciones de teclas que causarían frustración infinita en un teclado táctil
+
+Además, la ergonomía no se limita al teclado. El trackpad es superior a la pantalla táctil para muchas cosas; copiar y pegar, darle a enlaces pequeños en páginas web, moverse por listas, etc. Los atajos de teclado y búsquedas incrementales son la guinda.
+
+Por supuesto, si existiese un Android (e incluso un iOS, pero lo veo menos probable que suceda) con teclado y touchpad, que los aprovechase bien (i.e. que las aplicaciones y el sistema operativo tengan atajos de teclado y sean navegables por touchpad), cuya batería aguantase y que no tuviera serias incompatibilidades... Pues probablemente no dudaría en cambiar, pero de momento, sólo hay un fabricante que se dedica a este segmento; segmento que cada vez parece más pequeño y que me temo que acabe desapareciendo...
+
+
+=> gemini://alex.corcoles.net/2011/06/dinosaurios-que-rondan-la-tierra/ 1: gemini://alex.corcoles.net/2011/06/dinosaurios-que-rondan-la-tierra/
\ No newline at end of file
diff --git a/blog/content/2012/08/a-meternos-con-java.gmi b/blog/content/2012/08/a-meternos-con-java.gmi
new file mode 100644
index 00000000..32c9594f
--- /dev/null
+++ b/blog/content/2012/08/a-meternos-con-java.gmi
@@ -0,0 +1,43 @@
+# A meternos con Java
+2012-08-30
+
+Es deporte olímpico desde hace tiempo meterse con Java. Como plataforma es lenta, insegura e inútil. Como lenguaje, causa daños cerebrales irreparables a los programadores que lo utilizan. Para colmo, ahora ya no es propiedad de Sun (que era bastante molona), sino que ha sido absorbida por la malvada Oracle.
+
+Pues para mi sigue siendo una de las herramientas más útiles que tenemos a nuestra disposición; potente, gratuita y open source.
+
+Comencemos por la última moda. Java es inseguro.
+
+Vaya por delante que servidor navega con *todos* los plugins desconectados por defecto. Ni Flash, ni Java, ni incluso el lector de PDFs de Chrome cargan si no hago click explícito en ellos. Los navegadores son probablemente el programa de mayor riesgo de seguridad, siendo los banners de publicidad y las webs invadidas los mayores riesgos; innumerables webs sufren ataques que inyectan código malicioso en ellas y los banners de publicidad son una manera relativamente viable de colar código malicioso en webs "de confianza". Poco software más procesa más datos potencialmente hostiles de Internet.
+
+Todo el código expuesto a Internet ha sufrido vulnerabilidades; los clientes de correo, todos los navegadores y, especialmente, todos los plugins, han sufrido vulnerabilidades graves.
+
+Java no es la excepción, ni mucho menos.
+
+Dos incidentes recientes han sido especialmente notables. En abril, una vulnerabilidad de Java que *sólo* afectaba a ordenadores con OS X ejecutando la máquina virtual Java *distribuida por Apple* fue harto comentada al ser uno de los primeros malware afectando en masa a Macs. Gran parte de los medios cargaron contra Oracle por hacer de los ultraseguros Macs un coladero (por ejemplo, tras una rápida búsqueda en Google, podemos leer esto[1]).
+
+En general, estos artículos convenientemente omiten el hecho de que la vulnerabilidad había sido solventada meses antes por Oracle y había distribuido el parche. ¿Por qué no a los Macs? Pues sencillamente porque Oracle y Apple tenían un acuerdo mediante el cual es Apple la responsable de distribuir Java a los Macs (esto probablemente está vinculado a que Apple había escogido Java como una de las plataformas "oficiales" de desarrollo de aplicaciones oficiales para OS X tiempos atrás). Apple por supuesto era consciente de la vulnerabilidad y había escogido no distribuirla.
+
+En mi opinión, es completamente irracional culpar a Oracle/Java de este problema- la culpa reside plenamente en Apple; los agujeros de seguridad son inevitables y lo importante es cómo se gestionan. En este caso, mal gestionado por Apple. Podemos argumentar que Oracle hizo mal en ceder la responsabilidad de seguridad a Apple (porque en efecto, hemos visto que no ha sido buena ídea), pero al menos Oracle a partir de esto ha asumido esta responsabilidad de nuevo.
+
+El segundo incidente que tiene lugar estos días no es así, es una vulnerabilidad de Java. Según se dice, unos investigadores polacos habían alertado a Oracle de ella meses atrás y paralelamente, programadores maliciosos la habrían descubierto también y comenzado a explotar. Si esto es así, podemos cuestionar la diligencia de Oracle en tapar el agujero. Podríamos darles el benefici0 de la duda, pues otros agujeros reportados por el grupo polaco fueron parcheados diligentemente, y uno podría pensar que existe un motivo razonable por el que ese agujero en concreto se haya demorado más- pero creo que no es un argumento sólido. Yo valoro negativamente la actuación de Oracle en este incidente.
+
+Pero en definitiva, dos incidentes de notoriedad; el mayor incompetente en esta fiesta es claramente Apple, seguido de Oracle (a bastante distancia en mi opinión). Creo que es deshonesto intelectualmente machacar a Oracle sin criticar a Apple por encima- y más aún si ignoramos que los agujeros son inevitables, que el histórico del manejo de los agujeros de Java ha sido siempre bastante correcto.
+
+Pero vaya, si sólo hemos de aprender una única cosa de todo esto, es a navegar con los plugins desconectados.
+
+Por otra parte, como siempre que se oye la palabra Java, sale un coro de programadores maltratados alegando que Java les ha jodido la vida. Complejo, pesado, incómodo, etc.
+
+El problema es que para lo que se usa Java, pocas alternativas hay. Sí, para escribir programas pequeños existen bastantes soluciones mejores, como Python o Ruby; Haskell, C++, Matlab, Erlang, R, bash son claramente mejores en otras áreas más específicas.
+
+Pero para escribir aplicaciones "administrativas" grandes, no existe nada mejor. Python y Ruby son dinámicos, lo cual impide de entrada que existan herramientas suficientemente potentes como para poder refactorizar y analizar código con un mínimo de fiabilidad- en un proyecto suficientemente grande esto supone un coste en tiempo suficiente como para compensar cualquier otra ventaja que se pudiera tener. Herramientas como Eclipse son extremadamente valiosas para el desarrollo a gran escala y simplemente no pueden existir tal cual para un lenguaje dinámico (nótese que por ejemplo Google hace análisis sobre lenguajes dinámicos, pero lo hace añadiendo información de tipos al código- con lo cual se gana en herramientas, pero se pierde la supuesta ventaja de los lenguajes dinámicos).
+
+La única alternativa de calado viable es .NET. Sin embargo, es una herramienta con costes que impone unas restricciones bastante duras (e.g. nos obliga a pagar caras licencias en el servidor, lo cuál supone un impedimento importante a los escalados horizontales). Para algunos serán aceptables, para otros lo hace inviable.
+
+Sí, Java como lenguaje sufre muchas carencias; falta de lambdas y una API muy potente pero poco amigable (básicamente, para hacer cosas sencillas, es muy muy fastidioso- y uno quiere hacer cosas sencillas casi siempre); las lambdas suponen un serio inconveniente bastante insalvable (hay cosas que se expresan con mayor concisión y claridad con ellas), pero lo de la API es salvable; uno siempre puede escribir sus fachadas para las APIs complejas y olvidarse del problema (o usar las de otros; Spring en gran parte es eso).
+
+Lo otro es el ecosistema. Sí, existen librerías y frameworks con graves excesos de ingeniería. Sí, Java EE no es la plataforma más sencilla del mundo. Pero eso no es un problema de Java- especialmente porque existen frameworks y librerías bien diseñados y con una complejidad adecuada. Java + Spring MVC no será la plataforma de desarrollo web más sencilla que existe, pero su complejidad está bien alineada con su potencia.
+
+En resumen; sí, Java tiene sus defectos. Pero tiene muchos más "defectos ajenos" que propios. Y es preocupante la cantidad de detractores que no ven la viga en su propio ojo, o que critican con desconocimiento de causa. Yo ciertamente estoy contento de disponer de Java para ciertas tareas, tal como le veo muchos defectos y nunca lo usaría para todo.
+
+
+=> http://allthingsd.com/20120406/whats-this-a-mac-virus-no-actually-its-a-weakness-in-java/ 1: http://allthingsd.com/20120406/whats-this-a-mac-virus-no-actually-its-a-weakness-in-java/
\ No newline at end of file
diff --git a/blog/content/2012/09/mate-xmonad.gmi b/blog/content/2012/09/mate-xmonad.gmi
new file mode 100644
index 00000000..f0b56ebb
--- /dev/null
+++ b/blog/content/2012/09/mate-xmonad.gmi
@@ -0,0 +1,32 @@
+# MATE + xmonad
+2012-09-07
+
+Aunque Gnome 3 no me desagrada tanto como a otros, llevo un tiempo trasteando con xmonad[1], MATE[2] y otras alternativas. Tras jugar un poco hoy con el multimonitor de xmonad, he decidido lanzarme a la piscina con una combinación de MATE y xmonad.
+
+xmonad mola. Es un gestor de ventanas "tiling"; es decir, por defecto no solapa ventanas y las encaja como mosaicos, de manera que podemos visualizar fácilmente varias ventanas simultáneamente. A parte, tiene unos atajos de teclado bastante bien pensados por defecto y un soporte multimonitor bastante interesante.
+
+El problema es que es excesivamente minimalista. Uno espera un panel con un reloj, notificaciones de programas, control de redes inalámbricas, etc.; y en xmonad hay que currárselo; instalar utilidades para cada cosa, escribir scripts para arrancarlos, tunearlo todo... en fin, tiempo que te permite crearte algo 100% a medida, pero demasiado tiempo.
+
+Lo que hace bastante gente es usar un entorno de escritorio (que trae todo eso de serie) y sustituir su gestor de ventanas por xmonad. Inicialmente había trasteado con Gnome 3 para esto, pero no parece sencillo montarlo sobre la versión completa, y el "Classic" o "fallback mode" es feo y tampoco funciona muy bien.
+
+Finalmente he optado por MATE. MATE es un fork de Gnome 2, para mi enormemente familiar y que me da todas las funcionalidades que necesito. Tiene un repositorio apt para Debian y añadir un
+
+xmonad --replace
+
+al inicio es trivial. Lo único que nos queda es un mínimo tuneo para que xmonad:
+
+* use la tecla Windows en vez de alt para sus atajos
+* maneje correctamente los paneles de MATE
+
+Mi config es tan sencilla como:
+
+import XMonad import XMonad.Hooks.ManageDocks
+
+main = xmonad defaultConfig     {     	manageHook = manageDocks  manageHook defaultConfig,     	layoutHook = avoidStruts  $  layoutHook defaultConfig,     	modMask = mod4Mask      }
+
+Luego mi última personalización es dejar un solo panel inferior y llenarlo de applets. Ya sólo nos queda aprendernos los atajos por defecto de xmonad[3].
+
+
+=> http://xmonad.org 1: http://xmonad.org
+=> http://mate-desktop.org/ 2: http://mate-desktop.org/
+=> http://www.haskell.org/haskellwiki/Image:Xmbindings.png 3: http://www.haskell.org/haskellwiki/Image:Xmbindings.png
\ No newline at end of file
diff --git a/blog/content/2012/10/programacion-declarativa-contra-funcional.gmi b/blog/content/2012/10/programacion-declarativa-contra-funcional.gmi
new file mode 100644
index 00000000..43305089
--- /dev/null
+++ b/blog/content/2012/10/programacion-declarativa-contra-funcional.gmi
@@ -0,0 +1,29 @@
+# Programación declarativa contra funcional
+2012-10-06
+
+Creo que la gran parte de programadores han dado sus primeros pasos con la programación imperativa tradicional. En esta, se utilizan lenguajes de programación que reflejan más o menos directamente el funcionamiento de los ordenadores típicos; instrucciones ejecutadas secuencialmente con variables que vamos modificando y control de flujo. Por ejemplo, un problema básico de "sumar los números entre n y m" se podría implementar primitivamente de la siguiente manera:
+
+sumar ( valor inferior, valor superior) es     acumulado = 0     i = valor inferior     mientras i <= valor superior         acumulado = acumulado + i         i = i + 1     el resultado es acumulado
+
+Declaramos un acumulador en el que iremos recogiendo el valor intermedio de la suma (esto es, si sumamos los números entre 1 y 10, primero contendrá 1, luego 1+2=3, luego 6, etc.) y realizamos un bucle en el que i va cogiendo los valores entre n y m, ambos inclusive, que vamos sumando en el acumulador.
+
+Lógicamente, la mayoría de los entornos de programación cuentan con funciones estándar y estructuras de control de flujo más elaboradas que nos permiten expresar este algoritmo de una forma más concisa y clara, pero al final son equivalentes a las que usamos en esta implementación u a otras más complicadas.
+
+Aparentemente, el programa no alberga mayor dificultad, especialmente a ojos de un programador medianamente experimentado. Sin embargo, comprender la ejecución del programa pasa por saber visualizar la ejecución del algoritmo; su flujo y su estado. Para un algoritmo de 5 líneas y 2 variables esto no es excesivamente complejo, pero tampoco trivial para quien no esté acostumbrado. Creo que gran parte de la dificultad que encuentran los que aprenden a programar es en esta visualización; antes de inventar uno sus propios algoritmos creo que debe ser capaz de entender uno ya hecho- y para inventar uno posteriormente también necesitará esta habilidad de "visualización".
+
+Esta primera "valla" con la que uno se topa al aprender a programar es especialmente problemática; no la podemos rodear ni trepar progresivamente, la debemos saltar de golpe y considero que para muchos es una primera valla demasiado fuerte y que, en ocasiones, se rodea inicialmente dañando todo el proceso posterior de aprendizaje.
+
+¿Podemos mejorar esto? Consideremos la siguiente implementación del algoritmo:
+
+sumar ( valor inferior, valor superior):     el resultado es:         si valor inferior es igual a valor superior, valor inferior         si no, valor inferior + sumar (valor inferior + 1, valor superior)
+
+Observemos que aquí no hay estado. Comprender la ejecución de este algoritmo (obviando la implementación de las llamadas a funciones, que si bien es necesaria para comprender cómo el ordenador **ejecuta** el algoritmo, **no** es necesaria para comprender cómo **funciona**) es fácil pensando en una expansión algebraica:
+
+> suma de 7 a 23 = 7 + suma de 8 a 23 = 7 + 8 + suma de 9 a 23 = ... = 7 + 8 + 9 + ... + 22 + suma de 23 a 23 = 7 + 8 + 9 + ... + 22 + 23
+, con la que estará más familiarizado cualquiera que haya tenido una formación matemática media.
+
+Esta implementación, de una aproximación más funcional/declarativa, a mi entender es más sencilla de comprender y puede permitir al programador novel comenzar a implementar sus primeros algoritmos sin tener que visualizar flujo/estado sino mediante expansiones algebraicas.
+
+Pero la cuestión que se nos plantea en este punto es: ¿ayuda esto a la posterior comprensión de la programación imperativa? Es una pregunta importante, ya que si bien la programación funcional es potente, la programación imperativa es más adecuada para muchos programas que uno tendría que desarrollar (particularmente en un entorno comercial) y modela mucho mejor puntos tan importantes como son la entrada/salida.
+
+Ésta es una cuestión abierta, pero creo que como mínimo, una enseñanza inicial funcional puede ayudar al alumno a elaborar algoritmos medianamente complejos por sí solo y darle una confianza para afrontar el, más complicado a mi entender, mundo imperativo- al menos podrá haber realizado tareas complejas y no sentir la frustración que puede uno sentir al intentar implementar algoritmos iterativos simples y tener muchas dificultades a la hora de visualizar su ejecución.
\ No newline at end of file
diff --git a/blog/content/2012/11/dineropelota.gmi b/blog/content/2012/11/dineropelota.gmi
new file mode 100644
index 00000000..1cbd7e01
--- /dev/null
+++ b/blog/content/2012/11/dineropelota.gmi
@@ -0,0 +1,28 @@
+# Dineropelota
+2012-11-17
+
+El éxito de Nate Silver prediciendo las últimas elecciones en USA ha sido todo un acontecimiento público. Los medios se han hartado de comentar los métodos que le han permitido acertar correctamente el resultado en **todos** los estados con un margen de error mínimo, humillando a la legión de comentaristas políticos que extienden un dedo, lo levantan y miran de dónde sopla el viento para hacer sus predicciones.
+
+Pero para mi lo realmente interesante ha sido indagar en su biografía. A parte de haberse ganado la vida jugando al póker, Nate trabajó durante mucho tiempo en el campo de estadísticas en el béisbol.
+
+Tradicionalmente, el béisbol ha sido siempre un deporte con estadísticas al milímetro; como descendiente del cricket (que ya por el XVIII generaba bastantes datos), desde el siglo XIX durante cada partido se lleva un registro cuidadoso de todas las jugadas. El hecho de que sea un deporte con jugadas aisladas con inicio, final y resultado concreto hace que sea relativamente sencillo anotar una ingente cantidad de anotaciones sobre cada partido.
+
+Así pues, no es raro que ya hace mucho tiempo los equipos intentasen emplear las estadísticas para mejorar el rendimiento de su equipo mediante el análisis de datos para determinar táctica y estrategia o incluso para fichar jugadores. Las estadísticas de cada partido son públicas y los almanaques que recogen éstas son abundantes y populares, el uso avanzado de las estadísticas no se límita a los equipos y los comentaristas, sino que los mismos aficionados suelen estar muy familiarizados con los números.
+
+En 2002, los Oakland Athletics y su manager Billy Beane, consiguieron ensamblar un equipo extremadamente competitivo pese a no contar con unos ingresos comparables a los titanes tradicionales del deporte (su presupuesto para ese año era un tercio del de los Yankees). Para ello, bebieron de una corriente de pensamiento estadístico originada en los 50 que reanalizaba las estadísticas disponibles y creaba unas nuevas métricas que servían para valorar mejor el rendimiento de un jugador. Pasaban de estadísticas simples y evidentes como el porcentaje de bolas que conseguía batear un jugador a otros indicadores más complejos que tenían en cuenta más factores.
+
+Mediante el uso de estos indicadores, los Athletics conseguían encontrar buenos jugadores cuyas estadísticas tradicionales no eran excelentes y por tanto no estaban muy valorados, pero que sus métricas (denominadas sabermetrics) los destacaban como jugadores que podían aportar mucho a un equipo. Estos resultados también iban en direcciones opuestas, como en el caso de Silver contra los comentaristas de sillón, del olfato de los ojeadores.
+
+De esta manera, mediante el uso de estadísticas, los Athletics pudieron fichar jugadores baratos cuyo rendimiento estaba infravalorado y conseguir un éxito deportivo.
+
+Todo esto se plasmó en la película Moneyball con Brad Pitt, basada en el libro del mismo nombre, que explica la temporada de explosión de los Athletics.
+
+Por supuesto, el éxito de los Athletics llevó a otros equipos a utilizar los mismos métodos y seguir estas vías de investigación. El resultado fue el obvio; los jugadores con buenos números de sabermetrics subieron de valor, impulsando todo hacia el antiguo status quo- los equipos con dinero son los que pueden fichar a mejores jugadores según las sabermetrics, y se establece una carrera armamentística para ver quién puede encontrar métricas más efectivas que permitan descubrir a más jugadores infravalorados.
+
+Así pues, tenemos que un análisis estadístico concienzudo nos lleva a unos resultados deportivos tangibles y un cambio sustancial en la operativa de los equipos deportivos y una validación del método analítico en un terreno aparentemente tan caótico y subjetivo como el deporte.
+
+¿Es esto aplicable a otros deportes? ¿Podemos medir y optimizar el rendimiento deportivo?
+
+Seguramente sí. Sin embargo, está clarísimo que hay muchos y populares deportes que están en pañales estadísticamente. El fútbol, deporte rey, prácticamente no tiene estadísticas. Su naturaleza fluida y continua no parece proporcionar muchas oportunidades de generar datos; aún hoy tras los partidos no vemos más que un puñado de estadísticas muy genéricas, de las cuáles muchas no parecen tener mucho valor. Se han hecho esfuerzos analíticos y ahora vemos estadísticas como los kilómetros recorridos por cada jugador, pero al menos no se han hecho públicas ninguna métrica que parezca útil. Así pues, sigue en la época de los analistas de sillón que dictaminan sobre la cualidad de los jugadores y muy probablemente, existe una ventana de oportunidad para que un analista logre un salto cualitativo que cambie el fútbol moderno. Seguramente dentro de las casas de apuestas (que cuentan con unos sofisticados métodos de análisis que estiman probabilidades en tiempo real durante el desarrollo de los partidos), ya haya quien esté trabajando en ello.
+
+Por otra parte, observando el campo del motor vemos un caso bien distinto. Los equipos disponen de sofisticados datos telemétricos que permiten analizar hasta el más mínimo detalle de los movimientos del coche sobre la pista. Los sistemas de medición generan una cantidad de datos que seguramente hacen palidecer en cuanto al volumen a los datos de un partido de béisbol. Los datos de telemetría se utilizan extensivamente para analizar el rendimiento del coche y afinar su configuración, y para analizar la conducción de los pilotos y hallar puntos de mejora. Sin embargo, estos datos son coto privado de cada equipo y no circulan. Desgraciadamente, estos datos quizás nos permitirían responder a preguntas como quiénes son los mejores pilotos, que dado el gran peso del rendimiento del coche sobre el del piloto, a día de hoy son muy difíciles de contestar y quedan con un análisis muy superficial.
\ No newline at end of file
diff --git a/blog/content/2012/11/que-es-el-rpc.gmi b/blog/content/2012/11/que-es-el-rpc.gmi
new file mode 100644
index 00000000..6aa7fb03
--- /dev/null
+++ b/blog/content/2012/11/que-es-el-rpc.gmi
@@ -0,0 +1,43 @@
+# ¿Qué es el RPC?
+2012-11-28
+
+Aunque ciertos conceptos de programación son más viejos que yo, hay ciertas técnicas muy potentes que son desconocidas o ignoradas por mucha (demasiada) gente.
+
+A principios de los 80 (la Wikipedia cita un RFC de 1975 y, cómo no, Xerox) se hizo la formulación obvia que la comunicación entre sistemas se podía modelar como una llana y simple llamada a una función que se ejecuta en otro sistema y nos devuelve el valor.
+
+El mecanismo que se utilice para ello debe ser irrelevante, nosotros sólo queremos ser capaces de escribir:
+
+> resultado = suma(a,b)
+y que la suma se realice en el sistema remoto. A esto le llamaron llamada de procedimiento remoto o Remote Procedure Call en inglés.
+
+Sun implementó uno de los primeros sistemas de RPC para implementar el sistema de archivos distribuido NFS, y a lo largo del tiempo han ido apareciendo diferentes mecanismos de RPC para diferentes plataformas y necesidades.
+
+Con la popularización de la WWW, el protocolo HTTP y Javascript en los 90, pronto la gente comenzó a implementar comunicaciones entre sistema utilizándolos. Por ejemplo, una web podía exponer algunos de sus contenidos y funcionalidades en HTML para consumo humano, pero también exponerlos para consumo de otros sistemas. Mecanismos simples como poner una URL en la que si hacemos un POST http con unos argumentos, nos devuelve el resultado de una operación en un formato fácilmente parseable.
+
+Pronto, uno de los padres fundadores del HTTP, procesó los principios fundamentales del HTTP y la WWW, en concreto que todo era una cuestión de URLs y acciones como GET/POST/PUT/DELETE que soporta el protocolo HTTP; cada URL representa un recurso y podemos expresar acciones mediante los "verbos" HTTP. A esto le llamó REST y supuso una perspectiva limpia y poderosa de lo que es la WWW.
+
+De allí se pasó a los RESTful Web Services, maneras de exponer servicios en Internet utilizando los principios del REST.
+
+Típicamente, los desarrolladores de servicios web utilizan técnicas similares a las del desarrollo de aplicaciones web para publicar servicios REST, y los desarrolladores de servicio ejecutan las llamadas HTTP correspondientes para utilizarlos. Los formatos se intercambian en cualquier formato de intercambio de datos; desde texto plano, a XML u otros formatos como JSON, YAML o lo que se le ocurra la persona, teniendo que codificarse en origen y decodificarse e interpretarse en destino.
+
+Pero paralelamente, otros desarrolladores recordaron el RPC y desarrollaron sistemas de RPC sobre HTTP. Uno de los primeros fue XMLRPC, que posteriormente evolucionaría hacia el denostado SOAP. Muchas implementaciones de RPC sobre HTTP inicialmente eran malas; en parte por ser nuevas y primitivas, pero principalmente por la interoperabilidad. Mucho RPC anterior era entre sistemas muy homogénenos, con el mismo lenguaje en cliente y en servidor y desarrollados por las mismas personas, pero en el mundo de la WWW, son comunes entornos más heterogéneos, con lo que el RPC es mucho menos sencillo; diferentes modelos de datos y convenciones en cada extremo de la comunicación trae muchas dificultades y muchos RPC primitivos tenían grandes problemas de interoperabilidad.
+
+La visión de la transparencia entre sistemas no se daba. A veces, incluso, utilizando el mismo lenguaje pero diferentes implementaciones del mismo protocolo se tenían muchos problemas.
+
+Queda claro que una idea, por buena que sea, está limitada por sus implementaciones, y el pobre estado de los RPC sobre http ha impulsado muchísimo el uso de REST en vez de RPC. Eso es malo, porque en general REST te da más trabajo que RPC; mientras que en REST uno debe definir el formato de datos de intercambio e implementar la codificación y decodificación de estos, los mecanismos RPC realizan todo el trabajo sucio sin que el programador se tenga que preocupar de nada.
+
+Además, para invocar un servicio REST, simplemente has de usar las librerías de HTTP y de codificación que hayas escogido (parseo de texto plano, XML, JSON, etc.); con un sistema de RPC has de aprender a usar la librería, que si bien te puede ahorrar código, es más complicada conceptualmente.
+
+Esto llevó a que SOAP fuese condenado por gran parte del mercado (la interoperabilidad era siempre problemática, las librerías complejas, etc.) y el REST se popularizase mucho e incluso fuese en la práctica la mejor opción en muchos casos.
+
+Sin embargo, el RPC ha avanzado mucho. Disponemos de librerías decentes de SOAP, XML-RPC y otros protocolos como JSON-RPC para la mayoría de lenguajes, y hoy en día ya no me sorprende consumir un servicio implementado en un lenguaje desde otro sin ningún problema.
+
+Por otra parte, gente como Facebook y Google han inventado protocolos nuevos que son decididamente interoperables y multilenguaje, como Thrift de Facebook (ahora Apache) y los protobuf, que resuelven el RPC de una manera limpia y eficiente.
+
+Con RPC nos podemos ahorrar mucho código repetitivo de comunicación que supone REST, con el consiguiente aumento de productividad.
+
+¿Deja de tener sentido REST y sólo debemos comunicarnos mediante mecanismos RPC, por tanto?
+
+No, desde luego que no. Aún pueden existir problemas de interoperabilidad entre algunas plataformas poco populares, o los mecanismos de RPC puede que no sean buenos. REST es siempre un mínimo común denominador y la verdadera manera de asegurarnos que nuestros servicios pueden ser utilizados universalmente- incluso yo recomendaría que aunque implementemos RPC, ofrezcamos también REST para quien no pueda utilizarlo (recordemos igualmente que puede ser sencillo exponer un mismo servicio tanto con XML-RPC, como con JSON-RPC simultáneamente sin mucho esfuerzo, ampliando horizontes), y REST sigue siendo útil para exploración y "descubribilidad".
+
+Pero, cuando sea posible y adecuado, ahorrémonos escribir código de más.
\ No newline at end of file
diff --git a/blog/content/2012/12/x-men-la-vieja-generacion.gmi b/blog/content/2012/12/x-men-la-vieja-generacion.gmi
new file mode 100644
index 00000000..fbb9e9d2
--- /dev/null
+++ b/blog/content/2012/12/x-men-la-vieja-generacion.gmi
@@ -0,0 +1,52 @@
+# X-Men: La vieja generación
+2012-12-28
+
+X-Men: Primera Generación es la nueva entrega de la saga mutante marcada por el regreso de Bryan Singer. Tras Batman Vuelve en el 92, las pelis de superhéroes habían quedado relegadas a Spawns, Blades y Batmans infames, hasta que en 2000, con un presupuesto de mínimos acorde con la crisis del género, Singer encontró un enfoque moderno y verosímil e hizo una peli de calidad aprovechando las posibilidades de los poderes, sembrando la semilla que llevaría a Spider-Man un par de años más tarde, que reventaría los records de taquilla del género y puso en marcha la maquinaria comercial que hoy nos bombardea continuamente.
+
+Tras la primera entrega, Singer firmó X2, en mi opinión una obra maestra que ya con medios respetables conseguía aprovechar al máximo el potencial de los superhéroes, dentro de una excelente película sin apenas puntos flojos, nos dejó por ejemplo con dos memorables escenas de acción (Rondador Nocturno en la Casa Blanca y el asalto a la mansión Xavier) que son dos joyas del cine.
+
+El traspiés vino en la siguiente entrega- los cantos de sirena llevaron a Singer a intentar reflotar la franquicia de Superman con nefastos resultados, y lo peor es que dejó su saga en manos del incompetente Brett Ratner, que firmaría la mediocre X3 cuyos únicos momentos de brillo serían meramente inerciales. Paralelamente, un spinoff bastante olvidable con Lobezno pasaría sin pena ni gloria por las pantallas.
+
+Pero el hijo pródigo ha vuelto, aunque sólo en calidad de productor. X-Men: Primera Generación es una precuela que narra los orígenes del Profesor Xavier y Magneto. La historia se enmarca dentro del conflicto de los misiles de Cuba, claramente una estratagema de Sebastian Shaw (Kevin Bacon) y su Hellfire Club de mutantes selectos, que Xavier y el sr. Imán deberán detener.
+
+El guión quizá sea el elemento más débil de la película- juega demasiado entre la consistencia con entregas anteriores, fidelidad a los cómics y un argumento extremadamente ambicioso y no acaba de cuajar en ningún aspecto; hay agujeros e incongruencias, en ocasiones los personajes se separan demasiado de sus orígenes de papel y la historia no conduce demasiado hábilmente la película.
+
+Pero como contrapartida, tenemos los actores. Especialmente, algunos de ellos. Por qué no decirlo, el Magneto de Michael Fassbender está ahí ahí con el Magneto del magnífico Ian McKellen. Fassbender atraviesa todos los sentimientos con una facilidad y realidad pasmosa, en una interpretación absolutamente espléndida y sobresaliente. Ciertamente el personaje de Magneto da para muchísimo y especialmente en sus orígenes como amigo del que posteriormente sería su némesis, el Profesor X. Sus conflictos internos, sus giros y su tragedia son el punto fuerte de la película. Desgraciadamente, James McAvoy está meramente correcto tirando a bien como el profesor telépata- no queda claro si por el personaje o por la interpretación- como todos los buenos, se nos antoja un poco soso al lado de un goloso villano. Una lástima porque de haber igualado a Fassbender, es posible que muchas de las debilidades de la película hubiesen quedado totalmente eclipsadas por las interacciones entre ambos.
+
+Kevin Bacon como Sebastian Shaw también destaca, así como la mayoría de secundarios; especialmente Rose Byrne como Moira MacTaggert, la humana asociada/ayudante/amante de Xavier (aquí agente de la CIA en vez de genética con Nóbel) y Jennifer Lawrence (la prota de Los Juegos del Hambre) como Mística. Quizá cojea un poco el personaje de Emma Frost, que ya venía un poco cojo de los tebeos y que además se ve lastrado por los peores efectos especiales de toda la película.
+
+En cuanto a la acción y los efectos, en general muy bien. Ninguna escena de acción llega a las alturas de X2- no están tan bien pensadas y no utilizan los poderes a su nivel, y lo más destacable en ellas es, como no, Magneto, seguido de un demoníaco Azazel que está muy aprovechado.
+
+En definitiva, una peli de superhéroes decente y correcta, e impulsada a mayores cotas por el sublime trabajo de Fassbender como Magneto, que nos demuestra, como hizo hicieran antes Hugh Jackman como Lobezno, Robert Downey Jr. como Iron Man, Ian MacKellen como Magneto y un escaso puñado de actores más, lo que se puede hacer con estos personajes.
+
+El ránking quedaría así:
+
+1. X2
+2. Iron Man
+3. Hellboy
+4. Watchmen
+5. The Dark Knight
+6. The Avengers
+7. **X-Men: Primera Generación**
+8. Hulk (2003)
+9. Batman
+10. Spider-Man 2
+11. X-Men
+12. Batman Begins
+13. Spider-Man
+14. Batman Returns
+15. Iron Man 2
+16. X-Men Origins: Wolverine
+17. X-Men: The Last Stand
+18. The Punisher (1989)
+19. Thor
+20. Blade
+21. Elektra
+22. The Green Hornet
+23. Fantastic Four
+24. The Green Lantern
+25. Daredevil
+26. Superman Returns
+27. The Incredible Hulk
+28. Superman
+29. Spider-Man 3
\ No newline at end of file