Indie Web con Brea

que-por-que.md
Login

File docs/es/que-por-que.md from the latest check-in


---
titulo: Qué es Brea y por qué existe
origenes:
  - https://docutopia.tupale.co/brea
destinos:
  - https://mutabit.com/repos.fossil/brea/file?name=wiki/intro.md&txt=1
siguiente: abrebocas
breaks: false
toc: true

---

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][br] usa el software [Fossil][fs] como parte clave de su
memoria distribuida, como veremos luego).

[br]: https://mutabit.com/repos.fossil/brea/


- 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][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](https://es.wikipedia.org/wiki/Html), 
[CSS](https://en.wikipedia.org/wiki/Html) y [Javascript](https://es.wikipedia.org/wiki/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][flatcms].
    - **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][cms:w], 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][tup].
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](https://jamstack.org/what-is-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](./index.html#infrabolsillo) 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][br], 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](./glosario.html) que los agilizara.
Ya [Pharo][ph] y [Grafoscopio][gf] nos estaban permitiendo expandir el CMS que usábamos 
(llamado [Grav](getgrav.org)), 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:

<figure>
<a href="https://i.imgur.com/QLIppvz.jpeg">
<img src="https://i.imgur.com/QLIppvz.jpeg"
     width="95%"></a>
<figcaption>
<b>Figura 1 ❭ Flujo de datos y publicación en Brea.</b>
</figcaption>
</figure>


Un ejemplo concreto del mismo es este:

<figure>
<div class="row">
  <div class="column">
	<div class="row">
	  <a href="https://i.imgur.com/PsGiedJ.png">
	    <img
	      src="https://i.imgur.com/PsGiedJ.png"
	      alt="Plantilla." width="95%"   ></a>
	</div>
	<div class="row">
	 <a href="https://imgur.com/YVxq3Hq.png">    
	  <img
	    src="https://imgur.com/YVxq3Hq.png"
	    alt="Plantilla." width="95%"   ></a>
	</div>
  </div>
<div class="column">
<a href="https://i.imgur.com/YkD5CDU.png">
<img
  src="https://i.imgur.com/YkD5CDU.png"
  alt="Plantilla." width="90%"></a>
</div>    
</div>
<figcaption>
<b>Figura 2 ❭ Flujo de publicación de Brea ilustrado |</b> Arriba: texto de entrada al blog escrita en Markdown. 
  Abajo Izquierda: plantilla en Mustache para las entradas a blog. Abajo Derecha: Página HTML final resultante 
  de aplicar la plantilla Mustache al texto en Markdown. (Click en las imágenes para verlas a tamaño completo.)
</figcaption>    
</figure>                    

<br>
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.

:::info

----
  
  [**Alan Kay**](https://en.wikipedia.org/wiki/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](https://opensource.fandom.com/wiki/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](http://web2py.com/) una interfaz web que permitiera crear y subir repositorios
  de Fossil (similar a [ChiselApp](https://chiselapp.com/)) 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][iwsci] (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](http://hackbo.co/) (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](http://diariosdeunapandemia.art) (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][502LabIS] (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](https://mutabit.com/repos.fossil/indieweb/) (2020, ago-dic?): Se lanzan los talleres 
  quincenales y se organizan las memorias en el Wiki/micrositio.



[502LabIS]: https://mutabit.com/repos.fossil/502Lab/doc/trunk/wiki/Ironsworn/index.html
[br]: https://mutabit.com/repos.fossil/brea/
[cms:w]: https://en.wikipedia.org/wiki/List_of_content_management_systems
[flatcms]: https://www.staticgen.com/
[gfc]: https://mutabit.com/grafoscopio/
[grav]: https://getgrav.org/
[iwsci]: http://mutabit.com/offray/static/blog/output/posts/indie-science-indie-web-opengarage-science.html
[tup]: https://tupale.co/