# perdiendo.org/museodemetralla

entraron en mi cabeza (201) | libros (20) | me lo llevo puesto (7) | pelis (2) | Renta básica (9) | series (6) | escasez (2) | frikeando (94) | arduino (1) | autoreferencial (11) | bici (1) | esperanto (4) | eve online (3) | git (2) | GNU/linux (4) | markdown (7) | nexus7 (2) | python (7) | raspberry pi (3) | vim (1) | wordpress (1) | zatchtronics (3) | hago (761) | canciones (157) | borradores (7) | cover (42) | el extremo inútil de la escoba (2) | elec (1) | GRACO (2) | guitarlele (11) | ruiditos (11) | Solenoide (1) | fotos (37) | nanowrimo (3) | novela (26) | criaturas del pantano (5) | el año que no follamos (12) | huim (5) | rehab (4) | poemas (357) | Anclajes (15) | andando (3) | B.A.R (7) | Canción de cuna para un borracho (38) | Cercos vacíos (37) | Cien puentes en la cabeza (7) | Conejo azul (6) | Contenido del juego (5) | De tiendas (3) | del pantano (3) | Destrozos (2) | Epilogo (4) | Fuegos de artificio (5) | Imposible rescate (15) | Jugando a rojo (7) | Libro del desencuentro (2) | Lo que sé de Marte (11) | Los cuentos (21) | Montaje del juego (5) | Orden de salida (4) | palitos (31) | Piernas abiertas (7) | Poemas medianos (12) | Privado de sueño (7) | rasguemas (5) | Tanto para nada (17) | Todo a 100 (2) | Uno (4) | relatos (97) | anatemas (9) | orbital (2) | prompts (8) | vindicaciones (103) | perdiendo (1.711) | atranques (1) |

git y los tres estados

Git toma instantáneas de tus documentos a las que posteriormente puedes volver si lo necesitas. Incrementa las versiones añadiendo sólo los cambios, por lo que cada foto no pesa el total de su contenido, sino sólo en lo que difiere de la anterior. Si un archivo no se ha modificado git no lo guarda de nuevo, sino que incluye un enlace al archivo anterior.

De momento los comandos a los que iré aludiendo no son importantes, ya los explicaré más adelante y sólo los menciono para que se vayan asociando mentalmente.

  1. Confirmado (commited). El archivo ha sido añadido a una instantanea.

  2. Modificado (modified). El archivo ha sido modificado desde la última instantánea.

  3. Preparado (staged). El archivo está preparado para entrar en una nueva instantánea, pero no lo ha hecho todavía.

Tú inicias un proyecto con un par de archivos. En el ejemplo una novela, que consta del archivo ficha.md y novela.md. En ese momento los archivos están fuera de git, ya que no se se le ha indicado que tiene que hacerles seguimiento. Una vez que estén como queremos para una primera instantánea, utilizaremos git add ficha.md, git add novela.md o simplemente git add . para incluirlos.

En ese momento los archivos estarán en el tercer estado, preparados para la instantánea. Podemos seguir trabajando sobre ellos, pero si no volvemos a añadirlos con add al guardar la instantánea se guardarán tal y como estaban cuando utilizamos el git add.

Así, un mismo archivo puede estar en tres estados diferentes a la vez, y lo utilizaremos según nos convenga. Habrá una versión del archivo commited que será la que guardamos la última vez, otra versión stagged con los cambios que hemos ido haciendo hasta el objetivo que queremos que sea nuestra siguiente instantánea y modificado con el comienzo de los siguientes cambios.

Pongamos que el primer cambio importante que queremos registrar en instantáneas es, simplemente, cuando colocamos la ficha estándar que utilizamos para la historia y los personajes, que es ficha.md. En ese caso, una vez metida en la carpeta la marcamos como preparada con git add ficha.md y git commit con la descripción, por ejemplo, «ficha insertada». Después de hacerlo empezamos a trabajar el primer personaje en ella, y cuando terminamos lo marcamos con git add y seguimos con el siguiente personaje porque estamos inspirados. En ese caso tendríamos una instantanea con la ficha vacía, el mismo archivo preparado con la descripción del primer personaje y el mismo archivo modificado con la descripción del segundo personaje.

Para no perder nada haríamos commit con el comentario «descripción primer personaje», volveríamos a hacer git add para cambiar la parte del archivo modificado a preparado y haríamos un nuevo commit con el mensaje «descripción segundo personaje».

No es que ese tenga que ser el modo de trabajar, son sólo las distintas opciones. Podemos hacer una instantánea cuando hayamos terminado algo, seguir modificando hasta llegar a un punto que nos interese guardar y en ese mismo momento prepararlo (add) y fotografiarlo (commit).

Las tres grandes secciones de un proyecto git son, respectivamente:

  1. El directorio de git donde se guardan las instantáneas.

  2. El area de trabajo, que es dónde estamos haciendo cambios.

  3. El área de preparación, que es donde están los archivos fijados para la siguiente instantánea.

Una vez fijada la última, cuando sigamos haciendo cambios los archivos que toquemos estarán en el área de trabajo, y los que preparemos para el siguiente fijado estarán en al área de preparación. Para que un archivo pase a estar modificado sólo tenemos que modificarlo desde la última instantánea, para prepararlo tenemos que hacer git add sobre él y para fijarlo git commit.

bienvenidos a mi salón

Esa caja negra es el museo ahora.

En las vacaciones de octubre del año pasado empecé a trastear con la raspi, con la idea de montar un servidor en ella. Con la remota idea de alojar este museo en ella. Ha sido un tiempo complicado, he tenido que aprender muchas cosas, pero por fin el museo está en mi salón.

En amazon sólo monté una imagen de debian y sobre él apache, mysql y php, así que en cierto modo ya estaba aprendiendo lo que necesitaba.

El problema es que en amazon tienes un montón de seguridad, se puede joder tu server pero siempre quedarán copias (¿quedarán?), pero ahora, en la raspi… bueno, todo depende de lo que pueda hacer en un momento dado, y la posibilidad de que todo esto se pierda es más factible. Tengo una copia de todo lo que sucede en mega a través de mega-cmd, pero es una copia sincronizada. Si fastidio algo en local, fastidio algo en remoto. Si por algo todo se borra en local, todo se borrará en remoto.

Ahora todo está aquí, en cosas tangibles. La raspi, la tarjeta sd, el usb. Bienvenidos al museo, aparentemente más precario que nunca. Si algo se jode me llevará más tiempo y conocimientos que nunca solucionarlo.

Pero es hermoso. Lo es. Es hermoso que cada vez que entréis a verme os sentéis en mi salón. Sed bienvenidos. Coged una cerveza de la nevera.

Ha hecho falta un montón de conocimiento. Gran parte de ello, aunque me temo que no todo, está en r4sp1. Ha hecho falta saber un montón de cosas que siempre quise saber. Veremos qué sucede. La aventura continúa, la historia no lo tiene tan seguro. Pero la aventura continúa y eso es lo desternillante.

fractalmente complejo cuanto más te acercas

Jekyll es lento para tanta mandanga. Se puede utilizar la opción

--incremental

para que no recree las mismas entradas una y otra vez, pero tarda millones de años en el feed (que podría deshabilitar) que defiendo por todos los medios que pueda. Por otro lado, en mi eterna carrera de amateur picaflor, en picocms he descubierto que puedes insertar archivos en el .twig (que me huelo que es más de twig que de picocms) con algo como:

 {% include 'thtml/tu-archivo.thtml' %}

Sólo tienes que insertar en la carpeta del tema en el que estés trabajando el .thtml correspondiente. Esa tontuna te permite, por ejemplo, hacer un pie de página que cambiar en un sólo archivo. Los archivos .twig en los que se inserta son una especie de estructura en la que después picocms coloca el contenido. Puedes necesitar varias estructuras para diferentes cosas, y tiene pinta de ser muy potente, pero imagina que tienes 30 o 40 diferentes y que cambia el año y tienes que modificarlas una a una. Encontrar en alguna parte esa simple solución le ha dado muchos más puntos al gestor de contenido.

Seguro que en cuanto entre alguien que entienda realmente de lo que estoy hablando se va a echar unas buenas risas con lo poco que entiendo yo.

El tema del blog… está complicado y no lo está (siguiendo con picocms). No está pensado para uno, pero se puede implementar con un .twig en el que incluyas algo como esto:

<div class="container">
        {{ content }}

        {% for page in pages|sort_by("time")|reverse %}
        {% if page.id starts with "blog/" and not page.hidden %}
        <div class="post">
            <p class="date">{{ page.date_formatted }}</p>
            <h3><a href="{{ page.url }}">{{ page.title }}</a></h3>
            <p class="excerpt">{{ page.description }}</p>
        </div>
    {% endif %}
{% endfor %}
</div>

Y después de un tiempo buscando encontré un plugin (pagination) que resuelve lo de dividir en páginas las chorrocientas entradas, pero no habría modo de navegar por año. Habría que darle a un número de página al azar (la 15, por ejemplo) e ir aproximándose. Por eso decidí hacer un archivo anual y, dentro de cada uno, otro mensual. Eso hace que tenga que generar 16 años * 12 meses = 192 plantillas .twig. No es por no hacerlo, con copypastes modificando una sola línea en cada uno es tedioso pero muy factible, pero no me parece una solución bonita. Me parece una cutrada.

Picocms es muy versátil pero tienes que saber unos mínimos, y yo no los sé. Al menos no de momento, y comprendo que estoy dando palos de ciego en muchas cuestiones.

Por otra parte me gusta el plugin de jekyll para importar del xml de wordpress. Te separa las entradas por un lado y el contenido multimedia por el otro. Ambos cms utilizan básicamente archivos markdown con un encabezado en yaml, así que se me ocurren modos de adaptar lo que jekyll necesita y recoge a cosas que picocms pueda interpretar. Puedo eliminar del XML de wordpress los campos que no me interesen, por ejemplo. O puedo eliminarlos luego de algún modo automátizado utilizando algún script de python. No sé.

Picocms no me termina de convencer porque necesitas el cms para interpretar los archivos. Jekyll puede ser lento, pero construye archivos html y css (bueno, SASS, un CSS vitaminado del que no había oído hablar hasta ayer, más lío) que no necesitan más interprete que el navegador.

Por otro lado por simple volúmen de contenido, por más tontaco que sea, aumentan las visitas, y la instancia de Amazon está cada día más colapsada. No voy a pagarles más de esos 60 pavos al año, que con eso me compro la raspi, la tarjeta sd, el cargador, un pendrive y la caja. Me ha gustado mucho aprender cómo tiene Amazon montado el garito, pero todo tiene un límite. Quizá mude wp a la raspi, que era lo que quería evitar, y ya veremos. Pero en la raspi ya está r4sp1, el extremo inutil de la escoba, palabra de bob, zilgu (esta, la pobre, no tendría ni que mencionarla, ya contaré su historia y el horror de que estuviera hecha en flash), un servidor de mumble, otro de XMPP, otro de transmission, una vpn, uno de netdata… y un montón de otras cosas que ya ni recuerdo haber metido ahí. ¿Reventara?, ¿paso todas las webs a la vieja raspi, y monto en la actual el blog y los servicios?

No sé, no tengo ni idea. Me explota la cabeza.