Qué es Brea y por qué existe
Brea es un generador de sitios web simple, distribuido, basado en archivos planos para datos, texto y código, públicos y abiertos (en breve explicaremos cada una de las partes de esta definición). Su nombre se deriva de una broma nerd entre amigos, indicando cómo los pozos de brea facilitaban la creación y preservación de fósiles (y Brea usa el software Fossil como parte clave de su memoria distribuida, como veremos luego).
- Generador de sitios web:
- simple (sim plex, una sóla trenza): no muy enmarañado, o no muchos componentes entrelazados..
- distribuido: la información puede estar en múltiples lugares.
- basado en archivos planos: sin base de datos (después lo vemos en detalle).
- para datos, texto y código: tres formatos predilectos para estar en línea (sobre video, audio, multimedia, que se almacenan de manera externa).
- públicos y abiertos: Por omisión supondremos que queremos compartir ampliamente la información y que se encuentra bajo licencias que permite su distribución amplia (y eventual modificación). Esta opción se puede cambiar para ciertos repositorios.
Personalización y dinamismo o ¿por qué crear otro gestor de contenidos (CMS) más?
Los Sistemas Gestores de Contenidos o CMS (por las siglas en inglés de Content Management System), son artefactos que nos permiten publicar una porción de Internet muy visible, llamada la web. Para esto toman información almancena y representada en algún formato y lugar, la transforman en formatos que la web entienden (una combinación de HTML, CSS y Javascript) y la hacen disponible a través de una dirección web. Gracias a los CMS podemos tomar archivos de texto plano y convertirlos en páginas web, o imágenes de viajes o historias y volverlas galerías web, e incluso tomar archivos como documentos hechos en procesadores de palabra (MS Word, Libre Office Writer, Apple pages) o PDF y compartirlos en línea.
Los CMS son esencialmente de dos tipos:
- Dinámicos:
- Idea clave: Una base de datos almacena y produce, vía consultas a ella, el contenido que el sitio web despliega.
- Ejemplos: Wordpress, Drupal, Joomla, Mediawiki y basados en Django, Plone, Rails, etc.
- Ventajas: Alta popularidad y mucho conocimiento desplegado, incluida amplia oferta de servicios profesionales, plugins y extensiones prexistentes.
- Desventajas: Muchos puntos de ataque debido a su complejidad. Baja portabilidad, vincula y depende de versiones particulares de componentes para el despligue (o de migraciones entre ellas)
- Estáticos: (También conocidos como basados en archivos planos o flat file CMS).
- Idea clave: Un sistema de archivos y carpetas plano almacena y produce vía trozos de código, (llamados scripts) el contenido web que el sitio web despliega.
- Ejemplos: Jekyll, Grav, Hugo, Nikola, Pelican, Dokuwiki y un largo etcétera.
- Ventajas: alta simpleza, seguridad (menores componentes de ataque) y portabilidad (en una carpeta, está todo el sitio).
- Desventajas: Menor oferta de servicios profesionales y plugins prexistentes.
A pesar de la numerosa cantidad de CMS, prácticamente todos ellos, tanto estáticos como dinámicos, suelen suponer que la información que despliegan en la web, se origina/almancena dentro del CMS mismo (ya sea en la base de datos o en una carpeta del CMS), mientras que en nuestros proyectos, recurrentemente el origen de dichos datos era diverso: archivos planos en una carpeta, notas en Docutopia/CodiMD, galerías de contenidos en Internet Archive, datos comunitarios definidos en Tupale. Dicha diversidad de orígenes también requería una diversidad de representaciones en línea. Es decir, teníamos que ocuparnos tanto de cambiar el transfondo (back end) de almacenamiento como la interfaz (frontend) web de los CMS y aquello que los conectaba (middleware). Luego aprenderíamos que esa idea, que resonaba entre nosotros hace tiempo, también era parte del espíritu de la época, con los llamados CMS desacoplados o headless y el movimiento del JAMStack, que se hacían más populares en la medida en que, en parelelo, acá retomábamos ideas antiguas, las (re)escribíamos en código y prosa y socializábamos en talleres. Sin embargo, al ser movimientos ubicados en el Norte y el Sur Global, los desarrollos son resonantes, pero diferentes. Creemos que nuestro enfoque tiene valores diferenciales desde las llamadas infraestructuras de bolsillo que hacen parte de esta conversación global con enfoques más minimalistas y ágiles, además de contextuales a las realidades locales, pero que se pueden aplicar en muchos lugares del Norte y Sur.
Por ello decidimos retomar y reenfocar Brea, para consolidar nuestro propio CMS de archivos planos (estático) con fuentes de información y presentaciones para las mismas diversas. Pues si se trataba de hacer cambios en esos 3 componentes esenciales (back end, frontend y middleware), era mejor contar con un entorno de Live Coding que los agilizara. Ya Pharo y Grafoscopio nos estaban permitiendo expandir el CMS que usábamos (llamado Grav), así que retomar y extender Brea fue el siguiente paso hacia simplificar las infraestructuras, dándonos más agilidad y personalización.
La idea básica del flujo de trabajo es la siguiente:
Un ejemplo concreto del mismo es este:
Nos ocuparemos de alimentar, diversificar y robustecer “las flechas” de la Figura 1. Es decir, de que aquello que conecta a las distintas fuentes y formatos para almacenar, representar conectar y publicar nuestros datos.
Alan Kay, cuyo grupo en Xeron Parc fue pionero, a través de en Smalltalk, en la interfaz gráfica de ventanas y la programación orientada a objetos, lamentaba no haberla llamado programación orientada a mensajes en alguna entrevista, donde también hacía alusión a cómo los japonenes usan la palabra “ma” para referirse al espacio entre las cosas, que a su vez las conecta y que eso era lo que él quería enfatizar a través de los mensajes.
En español “ma” serían los intersticios. En Brea y Grafoscopio haremos énfasis en ellos y cómo pueden interconectar lo diverso.
Genealogía y prototipos
Algunas ideas son de cocción lenta. Acá están los apartes más relevantes de la historia de esta:
- SVNWiki (Comienzos del 2000’s): Si bien no fue un proyecto directamente relacionado con Brea, sí creo que sembró subliminalmente la idea en varios sentidos. Era un wiki que empleaba el sistema de control de versiones SVN para hospedar y distribuir los contenidos, editables tanto desde la interface web, como desde el sistema de archivos. Realizado por Alejandro Forero, de FreaksUnidos y otra de sus ideas adelantada a su tiempo.
- Brea en web2py (2011 o 2013): Esta exploración consistió principalmente en crear en el excelente web2py una interfaz web que permitiera crear y subir repositorios de Fossil (similar a ChiselApp) pero usando Python en lugar de PHP. La documentación del mismo ya permitía combinar YAML para metadatos y lenguajes de etiquetamiento ligero para la documentación. Si bien el prototipo preliminar dio buenos resultados, no se continuó la exploración, ni se socializó más allá de unos.
- Indie Web Science (2013-2014): Los principios de la IndieWeb se asociaron a proyectos relacionados con investigación reproducible, narrativas y ciencia de datos, explorados desde el entonces llamado IPython Notebook (que luego se convertiría en Jupyter Notebook).
- Brea en Pharo (2016-2017): Con motivo de algunos eventos nacionales e internacionales (Festival de la Imagen, ISEA, re:publica), se re-escribió la idea original de Brea en Pharo, ya no con la intención de hospedar repositorios, sino de facilitar la consulta y el despliegue de datos.
- HackBo (2019): Se empieza la migración del sitio web del hackerspace a HTML5Up y se considera la idea de usar el lenguajes de plantillas Mustache para crear nuevas versiones del mismo.
- Catálogo | Diarios de una Pandemia (2020 jun): Este proyecto se hizo frenéticamente y requirió retomar Brea agregándole Mustache y fuentes de datos a medida desde Archive.
- Wiki | 502Lab (2020 jul): Se inicia este wiki organizando el código escrito anteriormente de maneras más claras y tranquilas.
- Blog | Adriana, Offray, +? (2020, sep-ago): Se empiezan a prototipar lugares de presencia en línea personales y para colectivas, recogiendo los aprendizajes e infraestucturas de los proyectos anteriores.
- IndieWeb con Brea (2020, ago-dic?): Se lanzan los talleres quincenales y se organizan las memorias en el Wiki/micrositio.