Notas sobre lo que uno puede aprender en la DjangoCon 2014

Este fin de semana he tenido más tiempo libre de lo habitual y me he dedicado a ver algunos de los vídeos de la DjangoCon 2014, la conferencia anual sobre Django más importante a nivel mundial. En mi opinión, cualquier desarrollador con la intención de programar seriamente debería asistir a conferencias de este tipo, aunque sea a nivel nacional. Allí van los mejores a hablar de las tecnologías más punteras, las mejores prácticas, los errores más frecuentes. Un par de días de asistir a charlas (o unas horas de ver vídeos, en su defecto) te pueden aportar más que decenas de días trabajando tú solo o buscando aleatoriamente por la red.

Ir presencialmente a las conferencias tiene el punto añadido de que conoces gentecilla del mundillo, a los pros y a los no tan pros, una comunidad cercana a la que acudir cuando tienes dudas y crear un ambiente de colegueo súper chulo, que te anima a seguir trabajando duro para hacer las cosas bien. Cosas del software libre… :-)

Escribo estas líneas para recordarme a mi yo futuro qué es lo que aprendido en algunas de las charlas que he visto y, ya de paso, que le sea útil a alguien más. Todo el mundo sabe que tengo memoria de pez, y además me va muy bien escribir las cosas para fijarlas en mi cabeza. Here we go!

Development with Ansible and VMs

Últimamente estoy muy interesado en el tema DevOps, porque he visto verdaderos problemas en algunas de las estrategias de desarrollo y deployment de algunos clientes con los que he trabajado. De esto habla Jeff Schenk en Development with Ansible and VMs. ¿A quién no le ha pasado lo típico de tener que esperar a que los 7 planetas del sistema solar se alineen para que un proyecto arranque en su ordenador porque la información de configuración no está en ningún sitio o está desactualizada?

Aquí viene “The holy grail” aka “la madre del cordero” que son las máquinas virtuales que se parecen lo más posible a la máquina de producción y que se configuran/instalan (provisionan) con un sistema automático. Las tecnologías clave se llaman vagrant y ansible. Vagrant es “simplemente” un sistema que te permite escribir la definición de una máquina virtual en un archivo de texto llamado “Vagrantfile” y viene con la batería añadida de que configura automáticamente una carpeta compartida entre la máquina virtual que creas y tu propia máquina (la anfitriona). Así puedes editar lo que quieras con tu propio IDE en vez de con vim/emacs, y correr las aplicaciones desde la máquina virtual. Si uno se quiere flipar, puede incluso lanzar varias máquinas enlazadas simulando la estructura de producción, pero quizá sea pasarse un poco.

El otro ingrediente, ansible, es un sistema similar a Chef y Puppet (¡pero más moderno y escrito en Python!) que permite especificar una lista de instrucciones para instalar y configurar los servicios que queremos en la máquina virtual. Esto incluye, por ejemplo, descargar e instalar Nginx, Gunicorn y Django con archivos de configuración basados en una plantilla que escribimos nosotros, crear usuarios, cambiar permisos de carpetas y un largo etcétera.

Con estas dos herramientas, ejecutando un simple “vagrant up” tendremos un entorno de desarrollo listo en la máquina de cualquier desarrollador. ¿Que viene un nuevo miembro al equipo técnico? vagrant up y a correr. Quien piense que esto no es la leche, es que no se entera de nada.

DjangoCon 2014- Performant Django

Otra rama que me está molando mucho actualmente es el tema de performance y escalabilidad. No es un secreto que trabajo en Lead Ratings, y aquí tenemos que enfrentarnos a cargas de cientos de miles de leads (clientes en potencia) cada dos por tres. O uno hace el proceso eficiente o no hay máquina que lo aguante.

La primera de las charlas que he visto sobre este tema y probablemente la más general es Performant Django, por Ara Anjargolian. Este chico tartamudeante dice cosas básicas pero muy importantes, que diría que muchos desarrolladores de Django out there no conocen.

En primer lugar, cómo optimizar la parte del front-end de la aplicación. Resumen: cachear recursos estáticos y reducir el número de requests a éstos concatenándolos y minificándolos. Herramientas: django-pipeline, webassets. También existe la posibilidad más avanzada de dejar que el cliente renderice las plantillas enviándoselas como handlebars y los datos como JSON y hala.

Luego pasa a la parte del back-end, es decir, el código Python. Cosas generales: usar cached sessions (en lugar de en la base de datos) y compilar las plantillas. Empezar siempre por hacer un profiling del código para ver qué partes se deben mejorar. Dicen por ahí que un 20% del código es responsable de un 80% del tiempo de proceso. Hay que identificarlo y optimizar ese 20% en vez de lanzarnos a optimizar sin saber dónde. Herramientas: django-debug-toolbar y django-devserver.

Dicho esto, el principal culpable de que una aplicación de Django funcione lentamente es un excesivo número de queries SQL. Esto viene en parte motivado por la abstracción que añade el ORM de Django, que nos oculta un poco cuándo y qué queries SQL se hacen. Para hacer menos queries en sitios obvios, utilizar select_related() y prefetch_related().

Para mejorar la eficiencia de las queries y recuperación de datos: values/values_list() evita el overhead de crear el objeto de Python y evita tener que recuperar la fila entera, si no la necesitamos. Añadir db_index=True en las columnas que utilizamos para filtrar más a menudo.

Cuando no podemos optimizar más el número de queries o su calidad: usar denormalización. Esto significa repetir en más de un sitio de la base de datos una información. El ejemplo canónico es contar el número de comentarios en un post. Si añadimos un contador al post con este número que se actualice cada vez que se añada uno, nos evitamos tener que hacer un count() en la base de datos.

Finalmente, cache. Es imposible ir más allá de un cierto nivel de escalabilidad sin usar caches. A nivel de función: django-cache-utils, django-cache-helper. A nivel de query SQL: django-cache-machine, django-cacheops.

A Nice Problem to Have: Django Under Heavy Load

Este tío tiene una dicción mucho más segura y va más al grano. Tiene pinta de DB Analyst duro.

Empieza por lo de siempre: menos SQL queries. Ya sea con prefetch_related/select_related o cache.

Toca un punto muy importante a considerar cuando tienes cientos de miles de filas: sharding. Sharding consiste en poner las filas de un mismo modelo en distintas bases de datos. Por ejemplo, los tweets de cada grupo de usuarios en una base de datos distinta.

De nuevo, profiling. Sin profiling no hay revolución. New Relic is awesome. Eso dice. Si lo dice este tipo con esa dicción, me lo creo. Tengo que probarlo aunque haya que pagar. :D  Statsd también tiene muy buena pinta, aunque parece que tiene curro de montarlo y eso me aburre un poco.

En realidad, aquí Joshua habla de un profiling más avanzado, no sólo mirar el número de queries y tal, sino monitorizar también la carga de los procesadores, memoria, I/O… ¡El bottleneck puede estar en cualquier sitio!

Para aliviar los cuellos de botella, muy importante: hacer algo más que cambiar el cuello de botella a otro sitio. Si pones el doble de servidores web puedes sobrecargar la base de datos, etc.

Lo siguiente tiene todo que ver con “getting cozy with your database”. Y es que, como ya hemos dicho más arriba

Mejorar las queries SQL mediante generics. Menos queries dentro de for-loops por favor.

PostgreSQL rocks. Apunte mental: ver qué bases de datos puedo migrar a PostgreSQL. Desarrollar estrategias adecuadas de índices en las tablas.

Usar SQL EXPLAIN con las instrucciones SQL para ver qué es lo que está haciendo el motor y detectar índices. Para sacar el SQL de un QuerySet en Django: print qs.query.

Usar un disco duro de tipo SSD para los archivos temporales de la base de datos. Considerar sharding para conjuntos de datos grandes que le vengan al pelo.

A veces conviene tratar de utilizar tecnologías que no sean SQL para ciertas tareas. Por ejemplo SQL sucks para agregación de datos (mirar Red Shift o Vertica), operaciones de búsqueda avanzadas (Solr, Lucene), acceso rápido a un registro específico (Redis), datos multi-dimensionales (MongoDB) o grafos (Neo4J, Titan). Elegir la herramienta adecuada para cada tarea en vez de siempre el martillo. :D  Pero tener cuidado y mantener siempre una única fuente de verdad (single source of truth) en la base de datos para no liarse.

Finalmente, downstream caching. Esto es, usar la cache de los navegadores de los clientes devolviendo 304 (not modified) en lugar de 200 (ok). Para esto, lo mejor es utilizar nuestro propio conocimiento sobre nuestras vistas y devolver 304 cuando no han cambiado.

High Performance Django: From Runserver to Reddit Hugs

La siguiente y última charla sobre performance que he visto ha sido ésta. En este caso el foco no se pone en cómo optimizar el código de nuestra aplicación sino en la diferencia al utilizar distintos servidores.

Las configuraciones que prueba Peter Baumgartner son las siguientes (¡todas en EC2 bajo Docker!):

  • runserver
  • uwsgi
  • nginx + 2*uwsgi
  • varnish + 2*uwsgi

Para hacer los benchmarks utiliza Apache JMeter, una herramienta gráfica que yo no he probado, pero que parece bastante flexible y… ¡pinta gráficos! Las demostraciones las hace en vivo y en directo.

Como es de esperar, a medida que va probando stacks más abajo de la lista, los resultados van mejorando. Más peticiones por segundo, menor tiempo de respuesta a cada petición.

El resumen es que es increíble lo que se puede ganar en performance simplemente variando el stack de servidores de nuestro sistema. Y si podemos poner una downstream cache como Varnish, increíble. Sin tener que tocar una línea de código de nuestra aplicación.

Los cuellos de botella pueden estar en cualquier parte. Consideraré comprar el libro de este tipo, que cuesta en PDF 39$. Me parece carillo, ¿pero quién sabe lo bien que puede estar y lo útil que me puede ser? Ansia de conocimiento… :-)

Inheriting a Sloppy Codebase: A Practical Guide to Wrangling Chaotic Code

Slides

Este es el último vídeo que he visto que quería comentar. Todos nos hemos encontrado alguna vez con un proyecto que hemos mirado el código y hemos dicho puffffffffffff. Pero en serio: pufffff. Facepalms, gota que nos cae por la sien, caquita, lo que queráis. Ésto es lo que Casey Kinsey llama “sloppy code”.

Como él es muy políticamente correcto, dice que una mierda de código no se debe sólamente a inexperiencia, sino también a hacer las cosas (demasiado) rápido (rapid prototyping) o a no tener intención de mantener el código que escrito en un futuro cercano. Que los “protitipos” que creamos muchas veces los subimos a producción sin ningún cuidado y ahí se quedan hasta que a alguien se le tiene que caer la gotita por la sien.

La primera parte de la charla creo que se podría resumir en dos cosas. Antes de ponerte a poner un poco de orden en el código:

  • Limpiar la lista de dependencias instalando una por una y viendo qué falla, para eliminar las que no se necesiten y congelarlas en un bonito requirements.txt.
  • Escribir tests funcionales que cubran cerca de un 95% de código y tests unitarios para tareas críticas.

Yo también cometo el error a diario de ponerme a cambiar cosas de un código que no tengo controlado sin escribir los tests correspondientes. Y también lo lamento cada día. No es broma. Cuando uno tiene que lidiar con un buen trozaco de “sloppy code” la probabilidad de que cambies una cosa en apariencia inocua y que te cargues funcionalidades importantes no es nada pequeña.

La segunda parte de la charla versa sobre chapucillas típicas que uno se puede encontrar trabajando con el “sloppy code” e ideas sobre cómo arreglarlas. Pero las chapuzas que muestra en sus slides no son nada comparado con lo que te puedes encontrar por ahí. No kidding. Code horror.

Bueno, esto es todo por el momento amigos. Seguro que vosotros encontráis muchas otras charlas interesantes en la lista. Desde luego que seguro que las hay.

¿Hay un DjangoCon en España? :-)

Factory Boy

Hoy he empezado a utilizar una nueva herramienta para un proyecto de Django en el que estoy trabajando: Factory Boy.

La descripción del proyecto lo dice bastante claro: es una herramienta para ayudar en la creación de fixtures para tests, es decir, conjuntos de datos de prueba sobre los que correr tests de código automáticos.

En un proyecto de código real, es fácil que nos encontramos dos cosas:

1. Tendremos modelos con un montón de campos, bastantes de ellos obligatorios.

2. El volumen de relaciones entre distintos modelos puede ser alto. Por ejemplo, un libro puede tener una FK hacia un autor, y el autor a su vez una FK hacia su país de nacimiento, etc.

¿A qué nos lleva esto? Que para poder probar cualquier cosa en nuestros tests automáticos necesitamos un conjunto relativamente grande y pesado de objetos de prueba (la fixture) sobre los que correr la mayoría de los tests. Para solucionar este problema, lo que yo normalmente hacía era crear una fixture básica principal sobre la que corría todos los tests luego.

Esto tiene el inconveniente básico de que todos los tests que usen esa fixture tendrán que recrear cada vez esos objetos (porque Django hace un necesario flush de las BBDD antes de cada nuevo test), lo que lleva mucho tiempo.

Uno puede pensar en montar una jerarquía de fixtures para que cada conjunto de tests sólo cree (más o menos) los objetos que necesite. En mi opinión, esto puede ser una pesadilla de mantener y, por lo tanto, una razón más para acabar no escribiendo tests automáticos, por lo que yo no lo recomiendo.

Aquí es donde entra Factory Boy, que a mi juicio tiene básicamente dos ventajas muy importantes:

1. Permite poner valores por defecto (incluso dinámicos) para los distintos campos del modelo, de forma que al crearlo sólo hay que especificar los valores que no queremos que sean los por defecto.

Esto puede parecer una tontería, pero si se tienen muchos campos obligatorios es una bendición. Especialmente cuando se añaden campos nuevos a los modelos: en vez de tener que cambiarlo en todas partes, basta con cambiarlo en la definición de la factoría y punto.

2. Permite crear objetos en cadena. Es decir, si el modelo libro tiene una FK a un autor obligatoria, se pueden especificar los atributos deseados del libro y el autor se creará solo con los valores por defecto que hayamos especificado.

Aquí es donde se ahorra también un montón de tiempo, ya que podemos crear fácilmente los objetos que se necesitarán en cada test al inicio de la función del propio test, en vez de hacer una función setUp compartida para todos los tests que cree objetos que no necesitan todos los tests.

En resumen, una herramienta muy útil que recomiendo a cualquiera que haga TDD con Python, y especialmente con Django.

Rendimiento universitario y becas

La última propuesta del Gobierno de reforma del sistema de becas universitarias ha provocado un gran debate en torno a la finalidad de estas becas en la sociedad y sus requisitos asociados. Creo que nadie está en desacuerdo con que existan una serie de requisitos académicos que obliguen a los estudiantes beneficiarios de una beca a tener un rendimiento que, por decirlo de alguna manera, reconozca el esfuerzo económico que la sociedad en conjunto hace para posibilitar estas becas. La discusión radica más bien en el nivel de estos requisitos académicos que se exigen, es decir, a qué altura se pone la barrera de acceso a las becas.

Cuenta Wert a La Razón [1] que ha visto que mucha gente no tenía ni idea de que «la beca no sólo consiste en no cobrar las tasas, sino que consiste en dar dinero al estudiante para compensarle que no se incorpore al mercado de trabajo o facilitarle que viva fuera del lugar de su residencia habitual». Pues bien, yo creo que, de la misma manera, también hay mucha gente que no tiene ni idea de que el sistema de becas actual [2] ya incluye múltiples requisitos económicos y académicos para ser beneficiario de estas becas.

En primer lugar, a pesar de que pueda llegar a parecerlo al hablar Wert de forma general de “la beca”, no es cierto que todas las becas incluyan una compensación por no incorporarse al mercado de trabajo. Esta componente, llamada “beca salario” o “ayuda compensatoria”, se reserva únicamente a los casos de familias con menos recursos; por ejemplo, familias de tres miembros (caso de hijo único, ya que se incluyen los padres) que no superen los 10.606€ de renta anual. Igualmente, existen umbrales de renta para las componentes de ayudas de transporte, de residencia o de material.

En segundo lugar, la componente de matrícula de la beca sólo cubre la primera matrícula de cada asignatura. Es decir, si suspendes una asignatura y te vuelves a matricular de ella (por ejemplo, porque es obligatoria), tienes que pagar las tasas completas. Las becas te abandonan en aquellas asignaturas donde tengas dificultades; no se te permite ni un desliz.

En relación a este tema, es importante desmentir otro de los mitos imperantes en el discurso del Gobierno, retratado en este artículo de Esperanza Aguirre [3], que dice que «sin demagogia, podemos afirmar que todos los estudiantes universitarios españoles ya tienen una beca del 75% del coste de sus estudios». Pues lo siento, Esperanza, pero sí que es demagogia porque no es cierto. Como se puede comprobar si se lee el famoso RD 14/2012 [4], el límite de matrícula de hasta un 25% del precio total sólo se corresponde a primeras matrículas de grado y de másters habilitantes (de Arquitectura, Derecho, ingenierías y poco más). En el caso de segundas matrículas, este límite sube hasta un 40% del total, y hasta un 75% en el caso de terceras. Si hablamos de másters no habilitantes (como puede ser uno de Informàtica), la horquilla en primera matrícula ya llega hasta el 50%. Por tanto y con esta información sobre la mesa, podemos afirmar que esta idea de que los fondos públicos ya cubren el 75% de la matrícula de todo estudiante universitario es rotundamente falsa y demagógica.

Por otra parte y como ya se avanzaba en la introducción, también existen numerosos requisitos académicos para obtener y mantener la beca. En primer lugar, si se quiere poder acceder a todas las componentes, es necesario matricularse de 60 créditos anuales, es decir, estudiar a tiempo completo. Nada de matriculase de menos asignaturas para que te quede tiempo para trabajar.

Pero aquí viene la bomba. Para poder optar a la beca, se deben haber aprobado en el curso anterior un 90% de los créditos en el caso de Artes y Humanidades o Ciencias Sociales y Jurídicas, porcentaje que se reduce a un 80% en el caso de Ciencias y Ciencias de la Salud y un 65% para Ingenierías y Arquitectura. En el caso de los másteres, se exige una nota media mínima de un 7 o un 6,5 el año anterior, para no habilitantes y habilitantes, respectivamente. En la mayoría de los casos, si el año pasado tuviste un desliz en un par de asignaturas, puedes decir adiós a la beca.

¿No son lo bastante contundentes ya estos requisitos? Pues hay más y jugosos. Uno poco conocido es que la beca sólo cubre durante un año más a la duración estimada de los estudios realizados (dos en Arquitectura e ingenierías), y en este caso las cuantías recibidas se reducen a la mitad. Es decir, si los estudios de Física están programados para 5 años, el sexto año la beca se reduciría a la mitad y el séptimo no habría beca. Hay que tener en cuenta que la proporción de alumnos que acaban los estudios universitarios en el tiempo programado es, para muchas carreras, muy pequeña, y no necesariamente porque los estudiantes no se esfuercen.

Por último, pero no por ello menos importante, si un estudiante becado no supera el 50% de los créditos matriculados, tiene que devolver el importe íntegro de la beca, con excepción de las tasas de matrícula. Se acabó eso de matricularse de una carrera, que te vaya fatal el primer año, te cambies a algo que se te dé mejor y te vayas de rositas: ahora te irás además con una bonita deuda.

Con todo lo aquí expuesto, creo que queda más que suficientemente probado que ya existen requisitos bastante contundentes (algunos excesivamente contundentes, en mi opinión) que aseguran que el sistema de becas actual no es un agujero negro de dinero que traga sin control y nunca rinde cuentas. Cuando Wert dice [1] que «la mitad de los estudiantes que ingresan con una nota inferior al 6,5 no acaban graduándose» no debemos preocuparnos tanto por esa mitad que recibe fondos públicos y no se gradua, sino por la mitad que podría dejar de graduarse si le impedimos el acceso a las becas.

 

[1] http://www.larazon.es/detalle_normal/noticias/2845045/wert-si-no-me-sintiera-apoyado-por-rajoy-no

[2] http://www.boe.es/boe/dias/2012/08/14/pdfs/BOE-A-2012-10850.pdf

[3] http://esperanza.ppmadrid.es/becas/

[4] http://www.boe.es/boe/dias/2012/04/21/pdfs/BOE-A-2012-5337.pdf

SomSants, la xarxa social del barri

[Article publicat a La Burxa n169 (gener 2013), escrit pel Chris i jo]

SomSants és una xarxa social pel barri de Sants. Una eina web de comunicació oberta, creada amb programari lliure i gestionada de molt aprop, per nosaltres, per tu. L’us és semblant al Twitter; pots enviar missatges petits explicant què estàs fent, contestar altres missatges, citar reunions i esdeveniments, compartir fitxers i enllaços, etc.

SomSants neix de l’observació de que les llistes de correu que normalment fem servir no promouen la difusió ni conviden a la participació: el que es desenvolupa a cada grup queda aillat de la feina que es fa en els altres. Una xarxa social com SomSants és un complement natural de les llistes de correu, ja que presenta la informació en un format accessible per a tothom, fent que els missatges arribin més lluny, enriquint el teixit associatiu, col·laboratiu i social del barri i evitant a més a més convertir les nostres dades en mercaderia a les mans de xarxes comercials com ara Facebook, Twitter o Tuenti.

Entra-hi ara i dóna un cop d’ull al que es mou pel barri! No cal registrar-s’hi per a llegir la informació, però si ho fas en podràs publicar, subscriure’t a les actualitzacions d’altres, treballar en grup, enviar missatges privats, etc. Uneix-t’hi!!

Una asamblea no es un pasatiempo

[Actualización: consultar el artículo La tiranía de la falta de estructuras que transmite una idea en la misma línea que este artículo]

En gran parte de la sociedad las asambleas gozan de una considerable mala prensa. Reuniones en las que se desparrama sobre multitud de temas, acaban más tarde de lo que se pensaba, no se sabe bien qué se está votando y nadie toma responsabilidades sobre lo que se decide. No podemos tachar esta mala prensa exactamente de prejuicio, porque es verdad que muchas asambleas sufren estos y otros problemas, pero tampoco deberíamos pensar que estos problemas son intrínsecos de las asambleas y que es imposible eliminarlos o al menos paliarlos.

Es muy cierto que la horizontalidad de las asambleas plantea retos que en métodos de organización más jerárquicos no existen, pero también esta horizontalidad es precisamente, si la asamblea se desarrolla adecuadamente, la que las dota de una mayor riqueza y capacidad de tomar mejores decisiones con las que más gente está de acuerdo. Gran parte de los problemas organizativos que aparecen en las asambleas probablemente provienen del hecho de que vivimos en una sociedad apreciablemente jerarquizada, donde estamos acostumbrados a reuniones (formales) también jerarquizadas.

Es por eso que cuando se rompen las jerarquías explícitas nos vemos en la tesitura de pensar, ¿quién hace qué? ¿Quién tiene la responsabilidad de preparar la reunión? ¿Cuál es el sistema de decisión? Cuando las reglas no vienen dadas de fuera sino que tenemos que establecerlas nosotros mismos, nos podemos sentir abrumados y bloqueados.

Esto lleva muchas veces a que estas reglas y mecanismos no se establezcan y las asambleas se conviertan en algo totalmente informal, lo que genera la mala prensa ya mencionada. Es un grave error pensar que, por el hecho de que no exista una jerarquía y unas reglas marcadas de antemano, una asamblea ha de ser siempre informal y sin grandes preparaciones ni estructura.

Precisamente todo lo contrario. Para que una reunión en la que mucha gente no tiene claro cuál es su función y se quiere favorecer el intercambio de ideas y el acercamiento de posiciones, la preparación, la moderación y la formalización de esquemas de trabajo es fundamental. Normalmente la gente con más experiencia en reuniones asamblearias y/o más don de palabra es la que suele tomar la batuta y ayudar activamente con la organización, pero es importante que estas metodologías se desarrollen, aprendan y asuman por todo el grupo, favoreciendo la rotatividad (especialmente en el tema de moderación y preparación del orden del día).

Una pequeña ayuda
Desde estas líneas se podrían ofrecer multitud de pequeños consejos, pero para una introducción general se puede consultar, por ejemplo, el título (PDF gratuito) “Asambleas y reuniones – Metodologías de autoorganización” por Ana Rosa Lorenzo Vila y Miguel Martínez López y editado por Traficantes de Sueños en el 2001.

Esta guía se centra en tres niveles de objetivos. El primero, de eficacia: que se cumplan los objetivos para los que fue convocada la asamblea. El segundo, de participación democrática: que todas las opiniones y sugerencias sean escuchadas y no haya imposiciones ni coacciones. Y el tercero, de buen clima grupal: que las relaciones entre los miembros de la asamblea sean de cordialidad, cooperación y confianza.

Así, se desarrollan, entre otros, los temas de cómo preparar las asambleas -orden del día, duración de las sesiones, organización del espacio-, los diferentes tipos de opiniones -cada uno con sus técnicas propias-, los procesos de toma de decisiones consensuadas colectivas, el papel de la moderación -que muchas veces no se respeta o incluso no existe-, cómo desarrollar asambleas en colectivos numerosos -que normalmente requieren información y debate previo en grupos más pequeños y un esfuerzo especial en la preparación y moderación-, la toma de actas, mecanismos de resolución de conflictos y frustración dentro del grupo, técnicas de comunicación efectiva y métodos de auto-evaluación para conseguir una constante mejora.

A pesar de su relativa antigüedad (motivo por el cual no se trata el uso de nuevas tecnologías en la organización y difusión de información), el texto mantiene una vigencia más que notable. En multitud de ocasiones el lector se verá sorprendido al encontrarse reflejado en los ejemplos que se plantean. En resumen, una guía de muy recomendable lectura para todos los que participan asiduamente en asambleas, tanto si tienen amplia experiencia previa como si no.

Cernunnos, XVII

Hoy ha sido mi último día de trabajo en Cernunnos. La tarea del día ha sido llenar el bancal elevado con ramas. De nuevo, puede parecer una trivialidad, pero hay que hacerlo tratando de que quede el menor número de huecos posible para que en el futuro haya muchos nutrientes para las plantitas. Es como un tetris pero con muchas más combinaciones. Además, muchas ramas eran muy largas y hemos tenido que cortarlas, lo que me ha llevado al descubrimiento de otra de mis herramientas preferidas: el hacha.

Al igual que el pico, se utiliza cargando fuerza hacia atrás y descargándola contra lo que tienes delante, pero esta vez con la dificultad añadida de que lo que golpeas es una rama que gira y rebota elásticamente si no la sujetas bien. Asímismo, el hacha implica una necesidad de perfeccionamiento de técnica similar al caso del martillo y que el manejo del pico apenas requiere. Total, que me lo he pasado muy bien, aunque la lentitud a la que se rellena el tetris a veces es un poco frustrante.

También he acabado hoy mi lectura saltarina -dícese de aquella en la cual se saltan los capítulos que empiezan a parecer pesados o poco interesantes, por prisa- de “The One Straw Revolution” por Masanobu Fukuoka. Este hombre era un japonés estudioso de la agricultura científica que un día se iluminó y decidió dejar su trabajo y dedicarse a lo que él denomina “agricultura natural”, que es como la biológica pero además tratando de ahorrar todo el trabajo innecesario posible por parte del agricultor, y respetando al máximo el devenir de la naturaleza. Además, considera que la ciencia nunca podrá entender la naturaleza y la forma en que las plantas crecen naturalmente porque es incapaz de ver (y vivir) el todo, centrándose únicamente en las partes. De hecho, niega que el intelecto humano pueda llegar a entender el mundo porque sólo percibe su abstracción incompleta e irreal.

Si bien las ideas que tiene para cultivar sin pesticidas, herbicidas o fertilizantes artificiales y ahorrando trabajo superfluo me parecen de lo más interesantes y útiles, no me gusta el misticismo, el continuo ataque a la ciencia y, sobre todo, su constante prepotencia. Escribe como si todo el resto de científicos y políticos fuesen incapaces de entender la verdad a la que él a llegado. Entiendo que a la ciencia todavía le queda mucho camino, pero de ahí a negar que pueda obtener resultados útiles investigando los patrones de crecimiento de las plantas, me parece fanatismo. Es como quien se niega a reconocer los avances de la medicina moderna sólo porque hayan aparecido y proliferado enfermedades nuevas fruto de la masificación e industrialización de nuestras vidas. No hay más que comparar datos de la esperanza de vida de hace unos decenios y la de hoy en día en muchos países industrializados. Con todo, me parece que es un libro interesante de leer en muchas partes, sobre todo en las que narra experiencias con expertos estudiosos de agricultura, que son divertidas.

Cernunnos, XVI

Hoy hemos vuelto de nuevo a los pueblos abandonados a coger moras y a explorar. Unnarr sorprendentemente ha accedido a venir con nosotros, aunque quizá sólo lo ha hecho porque venía Margo.

Me ha gustado más esta segunda vez porque hemos subido a la parte un poco más oculta de Barxa, con zonas de pastos y lugares mágicos con combra y árboles macos, donde hemos comido y leído hasta que el Sol se ha calmado un rato. Después de ver estas zonas veo más viable y apetecible okupar algún día Barxa, más teniendo en cuenta que tiene al lado un arroyo con agua incluso durante este verano.

Esta vez después de pasar Froxende hemos seguido por un camino que subía la colina hacia territorio inexplorado en busca de nuevos pueblos, abandonados o sin abandonar. Después de una caminata de casi una hora y mucha subida hemos llegado a un pueblo en mucho mejor estado que Barxa y Froxende, pero también en proceso de convertirse en ruinas. Hemos gritado muchos “holas” pero la máxima respuesta ha sido un perro a lo lejos. En una especie de huerta había cebollas y lechugas con muy buena pinta y, como no había nadie, hemos decidido coger una de cada. Me siento un poco mal por llevarme cosas que no son mías sin permiso, pero bueno, había muchas cebollas y muchas lechugas. ¡Aunque la cebolla que hemos cogido vale por cuatro como mínimo! Perdón a la gente que pudo haberlas cultivado por llevarnos las cosas estas, os compensaremos. 0:-)

En el camino de vuelta hemos parado en Barxa a coger moras, que hay un montón y enormes, pero nos hemos ido pronto porque ya estaba anocheciendo. Al poco nos hemos encontrado con los gritos de Paris y Andru, que habían venido a buscarnos preocupados por si Unnarr se había escapado y andábamos buscándolo. En absoluto, ¡se ha portado muy bien todo el camino!

Hemos llegado a casa casi sin luz ya y devorado la cena, que estábamos con un hambre atroz después de todo el día caminando. Esta noche vamos a dormir como angelitos.

Cernunnos, XV

Hoy es sábado y normalmente solemos tomarnos el fin de semana libre, pero alguna fuerza cósmica nos ha hecho tener ganas de trabajar un poco. Probablemente el hecho de que el miércoles estuvimos todo el día fuera sin currar en la huerta apenas.

Para empezar hemos movido unos troncos grandes al hueco del bancal alto que estamos construyendo, y más tarde yo he colocado algunas ramas y trozos de madera más pequeños al lado (foto pendiente). Este bancal es un poco como un hijo para mí, pues con David he limpiado la zona, cavado el hueco y ahora vienen los troncos. No me va a dar tiempo a verlo acabado ahora, pero supongo que si vuelvo en un futuro veré judías plantadas.

Ya por la tarde y después de un delicioso almuerzo con judías pintas cocinadas lentamente -cortesía de Paris y su receta familiar- hemos jugado un Power Grid, al que he perdido estrepitósamente, y luego me he ido a recoger endrinas. Como Margo recogió muchísimas el otro día quedan cada vez menos, así que me he tenido que emplear a fondo para conseguir las de árboles lejanos y/o ramas altas.

Por la noche hemos tomado bocaditos de coco, sidra de manzana y cerveza estilo ale mientras jugábamos al Dixit. Todo un festín nada habitual donde me tengo que controlar para no dejar sin comida y bebida a los demás, que soy un glotón lleno de gula. ¡Al infierno!

Cernunnos, XIV

Al final no he ido yo a Monforte, sino que los chicos se han ofrecido amablemente a hacerme ellos los recados de la carta y los quesos. Merci!

Yo me he quedado en casa con Margo y nos hemos dedicado a acabar el trabajo del último día amontonando todas las zarzas que quitamos y arrancando raíces de tamaño descomunal (fotos pendientes) de cuajo, además de rastrillar la zona. Por ahí es por donde van a dar vueltas las gallinas y no queremos que se pinchen demasiado.

En medio del curro he escuchado cómo llegaba un coche y a gente hablar que no eran los chicos. He subido y eran dos hombres rondando la cincuentena que estaban buscando orégano. Que no todo el monte es orégano, pero en nuestra huerta tenemos mucho. Me han contado que ellos de niños bajaban a bañarse a la parte del río de nuestra casa y que en aquellos tiempos había mucha gente por la zona con tractores haciendo la vendimia. También que la casa donde vivimos nosotros antes era de un cura y que uno de ellos ayudó personalmente en su construcción. Los dos eran de Quiroga, el pueblo más cercano, al lado de Monforte de Lemos.

A mediodía hemos hecho una tortilla española que ha quedado especialmente bien, teniendo en cuenta el miedo terrible que tengo yo normalmente a equivocarme en las proporciones en esta receta y destrozar la tortilla.

Por la tarde he estado acabándome de leer un libro titulado “An Anti-Capitalist Manifesto”, por Alex Callinicos, donde desde una perspectiva marxista trata de argumentar que no es posible un mundo justo, democrático y sostenible dentro del capitalismo, el cual lleva irremediablemente a la acumulación de capital en manos de unos pocos, crisis económicas, graves problemas medio-ambientales y provoca conflictos políticos y armados a escala internacional. Asímismo, esboza un modelo socialista de planificación descentralizada multi-nivel, con pequeños espacios para el mercado y la propiedad privada, y propone una serie de demandas políticas para encaminarnos hacia este mundo socialista poniendo en jaque el capitalismo, como el establecimiento de uan renta básica universal, la cancelación de la deuda del Tercer Mundo, la introducción coordinada de la Tasa Tobin y los controles de capital, la reducción de la jornada laboral y la renacionalización de las industrias públicas privatizadas.

El libro destaca especialmente en las múltiples referencias a acontecimientos políticos históricos recientes y textos de personas influyentes en movimientos anti-capitalistas. Creo que sólo por esto merece la pena leerlo, porque la verdad que se me queda algo corto en el terreno teórico, repitiendo simplemente el credo marxista para afirmar que el capitalismo es indomable y, por lo tanto, cualquier tipo de socialdemocracia capitalista una contradicción. Lo proximo que tengo para leer son textos de Trotsky, aunque no creo que me dé tiempo a casi nada*.

Este finde probablemente volveremos a Barxa y Froxende, los pueblos abandonados, espero que esta vez sin lluvia y con una saca para recoger las moras de tamaño descomunal de Barxa y hacer más mermeladas para el inverno.

Por cierto, no sé si habréis probado la mermelada de madroño, pero no sabe a (casi nada) y tiene una textura bastante cutre. Nosotros la hemos probado con miel y con queso pero los estropea; es mejor sola. Vaya con el símbolo de Madrid…

¡Ah, y el domingo probablemente hagamos french toasts para desayunar! Pan empapado en huevo con leche y luego frito, ya demás luego se le puede echar queso y otras delicias por encima, mmm. ¡Vivan los domingos!

* Efectivamente, no me dio tiempo.

Cernunnos, XIII

La larga residencia en Cernunnos comienza a tener efecto. Margo me pregunta a mí si un cierto trabajo está terminado y le enseño dónde están las endrinas, por qué hay un vaso en medio del camino a la huerta o cómo cortamos el pan. Hace falta una semanita para acostumbrarse a los hábitos de nuestra casa.

Por la mañana hemos seguido con el trabajo gallinero-wise. Como queremos verdaderas free-range chicken, hemos estado  limpiando toda una zona de zarzas malvadas con ayuda de la hoz y la guadaña. Por el camino había unas cuantas parras enmarañadas que hemos intentado salvar, aunque no lo hemos conseguido con todas. ¡Una incluso tenía uvas! Lo que quiere decir que hay esperanza para futuros vinos.

Mi ojo derecho ya está bien, pero gracias al trabajo de la mañana he ganado dos nuevas pupas: dos espinas de zarza bastante clavadas en los dedos de la mano. Con la ayuda de unas pinzas he conseguido sacarme una, pero la otra imposible y me cae justo en la yema del dedo gordo, por donde agarro el bolígrafo, y me está costando lo suyo escribir. Dice Andru que al cabo de un par de días sale la espina sola; será si no me la meto continuamente al escribir y currar, pero tengo esperanzas en mi sistema inmunológico.

Por la tarde me he entrado la proactividad y me he dedicado, con ayuda de Margo, a seguir pintando el techo de la casa de blanco. Hemos acabado un buen trozo y ahora la casa tiene más luz. :)

Mañana voy de nuevo a Monforte con los chicos* porque quiero enviar la carta que se me quedó sin enviar y es importante. Ya que salgo, probablemente aproveche para comprar un queso o dos para llevar a Barcelona. Un Cremosiño, que es un queso que hacen en Pontevedra y que en casa comemos mucho untado en pan. No es especialmente sabroso, pero sí muy cremoso y con un nombre guay. Seguro que mis compis de piso se sonríen. =)

* Al final no fui.