100DaysOfHomeLab: día 2 – wordpress, las cachés y su prima

En este servidor, esferas.org, ya tengo cuatro instalaciones de wordpress independientes de todo excepto de la base de datos. El servidor no tiene una gran configuración hardware por lo que intento que la cosa vaya lo más fluida posible. Y hoy me ha dado por revisar el asunto de los cachés. En la página de salud del sitio, en el que siempre me dicen que hay uno o dos o tres elementos a comprobar están insistiendo mucho en que necesito un caché de objetos persistente.

100DaystoOffload: día 3 – aclarando conceptos sobre Mastodon y ActivityPub

Ayer estuve hablando con Ángel sobre el tema del fediverso y las diferencias entre Mastodon y cualquier servidor ActivityPub. Voy a transcribir aquí su respuesta para que quede constancia para el futuro.

En el principio todo era caos y llegó el ActivityPub que es una especificación para mandar mensajes de un usuario a otro, más o menos como un software de mensajería instantánea. Cada usuario tiene anunciado en su objeto JSON Person un URL que acepta HTTP POST en el que puedes escribir mensajes y que se llama Inbox. Cada vez que escribes una genialidad, tu obligación es clavarle en el Inbox de todos y cada uno de los pájaros que un día te dijeron (con el mensaje apropiado) que te quieren seguir.

Entonces alguien se dio cuenta de que si te siguen cienmil pájaros en la misma instancia, eso supone enchufarle cienmil mensajes en cienmil conexiones HTTP POST, y que eso es una puta locura. Entonces inventaron una cosa que se llama sharedInbox: es un Inbox único POR INSTANCIA y que también va anunciado en el objeto Person de cada usuario. Una vez hecho eso, tú solo escribes 1 mensaje en ese Inbox y el software se encarga internamente de distribuir tu mensaje a los cienmil pájaros que te siguen dentro de la instancia. Todo guay.
Fíjate que aún no he mencionado nada de «instancias federadas» ni «tags».

Pero entonces al tipo del Mastodon (a John Mastodon :-) se le ocurrió una cosa: ya que me entran por el sharedInbox chopomil mensajes para distribuir a mis hijitos, ¿por qué no mostrar TODO ESE CHORRO en un feed especial? Y va y lo llama «Federated timeline» porque esto es el fediverso y eso. Así que eso es un «efecto lateral» de los buzones compartidos. Está guay, pero no es parte del protocolo, o no al menos de cómo estaban los nodos ActivityPub pensados desde el principio.

Y después viene lo de los tags: ya que tengo el chorro de mensajes y muchos de ellos vienen marcados por hashtags, ¿por qué no poner búsquedas por hashtag, y después, por qué no seguir a los hashtags directamente? Guay, buena idea, pero tampoco forma parte del protocolo, aunque no está realmente «violándolo». Es más, sí que está saltándose parte de la especificación: cada hashtag, dentro del mensaje ActivityPub, tiene un URL que apunta a DENTRO DE LA INSTANCIA QUE LO GENERA donde se supone que están almacenados los tags. ¿Qué hace Mastodon? Tira ese URL a la basura y lo apunta hacia dentro de sí mismo.

Snac no tiene buzones compartidos. Por tanto, no hay un timeline federado ni hay hashtags a los que seguir.

Menciona a snac como ejemplo de servidor ActivityPub que es mucho más sencillo de instalar y probar que cualquier otra cosa de las que abundan en el fediverso. De lo hinchados que están esos entornos y el hostión que van a darse si tienen éxito de verdad hablaré otro día. Sí que reconozco que haberme acercado al fediverso desde Mastodon ha desvirtuado mucho mi idea sobre ello. He aprendido mal. Pero todos tranquilos, que eso tiene arreglo.

100DaysOfCode: día 7 – nueva idea y continuación de otros

Hoy he tenido un día regular en este reto. Me he pasado parte de la mañana enfrascado en muchos temas y le he dado demasiadas vueltas a la parte de administración. Espero recuperar tiempo mañana.

ttt

Aquí el trabajo ha sido poco. Un test de un módulo Perl escrito y funcional que falla en todos los aspectos que tiene que fallar porque el código que testea no existe en su mayoría. Respecto al módulo he avanzado bastante, especialmente cuando me he dado cuenta de que son tres métodos públicos, sin atributos de clase, y que no merecía la pena emplear bibliotecas de código para automatizar la clase. Vamos, ni ésta ni ninguna de las otras tres en las que está compuesto.

mydevtools

Aquí he estado pensando bastante y me he lanzado a crear una nueva herramienta que las unifique a todas. Así, sin miedo, pero con esperanza brillando en mis ojitos de que esta vez voy a conseguirlo.

No, en serio. El único problema, si puedo llamarlo así, que encuentro con este paquete es que son demasiados los scripts que lo componen y aunque lo tengo bastante documentado me pierdo en el nombre, los parámetros y el orden de uso que tengo que darle en cada momento.

He ideado un programa llamado mybuild que va a reunir toda la funcionalidad que tienen los otros para no tener tanto espacio de nombres ocupado. Si total, las tareas son las mismas de siempre.

Ahora mismo en un archivo make tengo la siguiente disposición con las tareas comunes en un directorio de desarrollo.

all:

build: build-manpages

build-manpages: extract_pod
        build_repo_manpages -b -s docs

extract_pod:
        extract_pod_manpages -t docs

install:        install-docs install-lib

install-docs:
        build_repo_manpages -i -s docs -t $(DESTDIR)/usr/share/man

install-lib:
        install_repo_files libmyparams-perl $(DESTDIR)

clean: clean-docs clean-tmp

clean-tmp:
        find . \( -name "*.bak" -o -name "*.orig" -o -name "*.deb" \) -delete -print

clean-docs:
        build_repo_manpages -c -s docs

Más o menos así. Depende de la antigüedad del proyecto utilizaré unos u otros para hacer lo mismo en todas las fases: inicialización, construcción, testeo, instalación y empaquetado. Y siempre tengo que mirar ejemplos de otros proyectos recientes o tirar de página de manual para saber cómo funciona. No está bien.

La herramienta que he comenzado dará un aspecto más sencillo a los archivos make:

all:

build: build-docs build-binary 

build-docs:
    mybuild build docs

build-binary:
    mybuild build bin

clean: clean-repo clean-docs 
    mybuild clean bin

clean-repo:
    mybuild clean repo

clean-docs:
    mybuild clean docs

Creo que la idea se pilla. Se llama al programa con la operación y luego el tópico y se encarga, como ya hacen lo otros programas, de mirar valores por defecto, comprobar si se puede o no hacer algo, hacerlo o no, y dar los errores correspondientes; todo con la máxima de que va a ser empleado en otros programas y que debe morirse si hay algo de verdad mal y no decir ni pío si el resto va bien o no ha tenido que hacer nada.

He empezado escribiendo la documentación y luego pasaré a los test. No tengo prisa pero estaría bien que algunos de los tópicos estuviesen cubiertos como la documentación, tema más que trillado por el paquete, lo antes posible.

Ah, lo mismo el nombre es demasiado largo y lo acorto con uno de mis famosos y valorados acrónimos. :-)