Doctorado

@article{lafuente_critica_2013,
	title = {La crítica de la ciencia},
	volume = {141},
	url = {http://www.profesiones.org/var/plain/storage/original/application/55787586cfc72081a1dc891d40a3fbb5.pdf},
	journal = {Profesiones},
	author = {Lafuente, Antonio},
	month = feb,
	year = {2013},
	note = {00000},
	pages = {48--49}
}

@misc{noauthor_pharo_nodate,
	title = {Pharo source documentation: {Collections}-{Strings}},
	shorttitle = {pharo-sourcedocs-strings},
	url = {http://magaloma.seasidehosting.st/Collections-Strings},
	urldate = {2014-09-23},
	note = {00000}
}

@book{girba_moose_nodate,
	title = {The {Moose} {Book}: {Introduction}},
	shorttitle = {girba-moose-book-intro},
	url = {http://www.themoosebook.org/book/index.html},
	urldate = {2014-09-27},
	author = {Girba, Tudor},
	note = {00000}
}

@misc{bergel_software_2014,
	title = {Software as graph},
	url = {http://vimeo.com/94724841},
	urldate = {2014-06-24},
	author = {Bergel, Alexandre},
	year = {2014},

	title = {the glamorous toolkit},
	url = {http://gt.moosetechnology.org/},
	urldate = {2014-10-21},
	author = {Girba, Tudor and Chis, Andrei and Syrel, Alex},
	year = {2014},
	note = {00000}
}

@incollection{sharp_chapter_1997,
	title = {Chapter 12. {Strings}},
	isbn = {0-07-913036-4},
	shorttitle = {sbe-strings},
	url = {http://stephane.ducasse.free.fr/FreeBooks/ByExample/14%20-%20Chapter%2012%20-%20Strings.pdf},
	booktitle = {Smalltalk by {Example}: the {Developer}'s {Guide}},
	author = {Sharp, Alex},
	year = {1997},
	note = {00000}
}

@incollection{girba_glamour_2013,
	title = {Glamour},
	isbn = {978-3-9523341-6-4},
	shorttitle = {pbe2-glamour},
	booktitle = {Deep into pharo},
	author = {Girba, Tudor},
	year = {2013},
	note = {00002},
	pages = {191--207}
}

@misc{noauthor_pharo_nodate-1,
	title = {Pharo - {Welcome} to {Pharo}!},
	shorttitle = {pharo-sitio-web},
	url = {http://pharo.org/},
	urldate = {2014-10-21},
	note = {00000}
}

@misc{activist_object_curating_nodate,
	title = {Curating the {Activist} {Object}: {Project} {History}},
	url = {http://activistobject.wordpress.com/project-history/},
	urldate = {2014-10-01},
	author = {{Activist Object}},
	note = {00000}

	title = {You {Are} {Not} a {Gadget}: {A} {Manifesto}},
	isbn = {0-307-26964-7 978-0-307-26964-5},
	url = {http://gen.lib.rus.ec/book/index.php?md5=84de2a0765823489be4f2ec72f031aff},
	publisher = {Knopf},
	author = {Lanier, Jaron},
	year = {2010}
}

@misc{caekenberghe_smalltalk_2012,
	title = {Smalltalk {Object} {Notation} ({STON})},
	shorttitle = {caekenberghe-ston},
	url = {https://github.com/svenvc/ston/blob/master/ston-paper.md},
	urldate = {2014-09-23},
	author = {Caekenberghe, Sven Van},
	month = may,
	year = {2012},
	note = {00000}
}

@article{luna_cardenas_resolucion_2007,
	title = {Resolución {Colectiva} de {Problemas} desde {Modelos} {Multiagente}: un diálogo entre la teoría y el aula},
	shorttitle = {luna-maestria},
	url = {http://mutabit.com/deltas/repos.fossil/offray-maestria-tesis/doc/tip/EscritoTesis/articuloTesisMaestriaRevistaMagis.pdf},
	author = {Luna Cárdenas, Offray Vladimir},
	year = {2007},

	shorttitle = {{JupyterLab}},
	url = {https://www.youtube.com/watch?v=Ejh0ftSjk6g},
	urldate = {2018-04-18},
	author = {Granger, Brian},
	year = {2016},
	keywords = {Julia, Python, Interactive Computing, Jupyter Notebook, JupyterLab, R Programming Language}
}

@book{bergel_deep_2013,
	title = {Deep into {Pharo}},
	isbn = {978-3-9523341-6-4},
	url = {https://open.umn.edu/opentextbooks/BookDetail.aspx?bookId=315},
	abstract = {"Pharo is a clean, innovative, open-source, live-programming environment. Deep into Pharo is the second volume of a series of books covering Pharo. Whereas the first volume is intended for newcomers, this second volume covers deeper topics. You will learn about Pharo frameworks and libraries such as Glamour, PetitParser, Roassal, FileSystem, Regex, and Socket. You will explore the language with chapters on exceptions, blocks, small integers, and floats. You will discover tools such as profilers, Metacello and Gofer."--Open Textbook Library.},
	language = {English},
	urldate = {2018-04-19},
	author = {Bergel, Alexandre and Cassou, Damien and Ducasse, Stéphane and Laval, Jannik and {Open Textbook Library}},
	year = {2013},
	note = {OCLC: 957555902}
}

		el mismo sistema de información.
		El código mostrado a la izquierda produce la visualización de datos a la derecha y es 
		esta conversación bimodal código-visualización la que permite la exploración interactiva
		de sistemas complejos.
		Este vídeo fue un argumento fuerte para la elección de Pharo como plataforma para el
		prototipado de Grafoscopio, pues mostraba una conversación del software como material
		que no había visto con tal practicidad y fluidez en otros entornos de computo y
		permitiría prototipar ágilmente las ideas que esta tesis busca explorar.}
	\label{fig:software-as-graph}%
\end{figure*}


\section{Hacer Software: Una experiencia de aprendizaje comunitario}\label{grafoscopio-una-experiencia-de-aprendizaje-comunitario}

Como se dijo, el desarrollo de software en este escrito es visto como un acto de enculturación 

Estas comunidades particulares de software libre se articulan alrededor de los artefactos que usan 
y lo que estos posibilitan. 
Ahora bien, hay varias comunidades interrelacionadas en Pharo y hablaré de ellas de manera indistinta 
como la comunidades Pharo, en plural, sin embargo, vale la pena hacer algunas claridades, a partir
de lo que ellas dicen de sí mismas a través de los artefactos y proyectos que las convocan:

\begin{itemize}
	\item Pharo (\cite{noauthor_pharo_nodate-1}):
		\begin{quote}
			Te da control total sobre tu experiencia de programación. Enfocado en
			simplicidad y realimentación inmediada, es un entorno puro de
			programación orientada a objetos \emph{y} un poderoso entorno (piensa en
			un IDE y un OS empacados en uno).\footnote{IDE y OS son las siglas para
				Entorno Integrado de Desarrollo y Sistema Operativo, respectivamente,
				por sus iniciales en inglés.}
		\end{quote}
	\item Moose (\cite{girba_moose_nodate}):
		\begin{quote}
			es una plataforma de código abierto para expresar análisis de sistemas
			software y datos en general. En otras palabras, su objetivo principales
			es asistir y habilitar al humano en el proceso de comprender grandes
			cantidades de datos.
			
			Se dirige a varias categorías de personas:
			\begin{itemize}
				\item
				investigadores en el área de análisis de software, minería e
				ingeniería inversa.
				\item
				ingeniereos y arquitectos quienes quieren entender sistemas y datos y
				\item
				constructores de herramientas.
			\end{itemize}		
		\end{quote}
%PENDIENTE: Escribir a Alex sobre la versión que decía esto:
	\item El proyecto de Visualización Agil, construido sobre estas plataformas, 
		afirma (``Agile Visualization'' n.d.):
		\begin{quote}
			La visualización ágil es acerca de usar los recursos computacionales
			para agrandar la mente y las capacidades cognitivas de nuestro cerebro.
			Crear una visualización a la medida, en ciclos extremadamente cortos de
			producción es lo que caracteriza las ténicas de visualización,

Una vez decido que se usaría Pharo, la exploración inició con las interfaces gráficas 
que servirían para el proyecto. 
Se inició mirando la interface del sistema de ayuda de Pharo como tal (véase figura
\ref{arbol-ayuda-pharo}), ya que unas capturas de pantalla de un sitio relacionado
(Squeak/Smalltalk) y una exploración preliminar mostraban un sistema similar al de navegación
arbórea, que seguramente estaría disponible para varias variantes de Smalltalk. 
Sin embargo, ya que el sistema de ayuda estaba pensado para programadores, la creación de
jerarquías arbóreas y nuevos temas dentro del mismo requería la escritura de código en el
navegador de clases de Pharo y se requería una experiencia mucho más fluida de escritura
que permitiese la creación rápida de tales jeraquías sin necesidad de programar.
El código fuente del sistema de ayudas, en particular el subconjunto de paquetes agrupados 
bajo la denominación
\texttt{Help-System-Core\textgreater{}\textgreater{}\ Model\textgreater{}\textgreater{}\ HelpTopic},
sirvió como plantilla para desarrollar la lógica subyacente de Grafoscopio, lo que muestra
una de las ventajas fundamentales de entorno continuo de programación ofrecido por Pharo, 
en el que no se diferencia entre la aplicación, el entorno de desarrollo y el código fuente,
pues si se encuentra una funcionalidad interesante, es posible acceder a sus instrucciones y 
copiarlas o modifcarlas hasta lograr una experiencia de uso cercana a la deseada.

En este periodo inicial se aprendió esencialmente sobre la jerarquía de clases, la definición
de objetos y métodos (\cite{bergel_deep_2013}) y el uso de colecciones (\cite{noauthor_pharo_nodate})
y cadenas de texto (\cite{sharp_chapter_1997}), que permitieron definir el modelo y comportamiento
base para sobre ellos hacer la Interfaz Gráfica de Usuario (GUI, por sus siglas en inglés).

\begin{figure}[th]
	\begin{center}
		\includegraphics[width=\linewidth]{Parte2/arbol-ayuda-pharo.png}
		\caption[Sistema de ayuda de Pharo]
		{Sistema de ayuda de Pharo. Se puede ver que formar una jerarquía se hace programando. La idea de Grafoscopio era evitar eso para 
			que cualquiera pudiera crearlas desde una interface gráfica
			\label{arbol-ayuda-pharo}}  
	\end{center}
\end{figure}

Con la funcionalidad subyacente para definir una jerarquía arbórea de objetos: crearlos,
asociarlos como hijos entre sí, borrarlos y moverlos a distintas partes de la jerarquía,
se procedió a construir el borrador de la interfaz gráfica.
Se evaluaron distintas alternativas dentro del ecosistema Pharo, como Maui y Spec, pero se
continuo con Moose y su \emph{toolkit} Glamorous (\cite{girba_glamour_2013}) para la creación
de la interfaces de usuario, debido a lo sencillo de su sintaxis y su rapidez de prototipado 
de interfaces. 
Los primeros resultados de la interface se pueden ver en la figura \ref{ui-primeros-resultados}

\begin{figure*}[th]%
	\centering
	\includegraphics[width=0.45\linewidth]{Parte2/interface-nodos-recursivos.jpg}
	\quad
	\includegraphics[width=0.45\linewidth]{Parte2/nodos-ubicaciones-especificas.jpg}

estaban implementados. 
De hecho eso y la inercia comunitaria que puede contestar rápidamente o en un par de
semanas, sumado a mi propia inexperiencia en el uso del lenguaje y el entorno, demoró mucho
lograr una parte clave de la experiencia de uso, que era la actualización automática de la
información en la medida en que se escribía en el árbol, lo que era necesario para tener una
experiencia mínima de escritura amigable, que otros \emph{toolkits} de interface gráfica ya 
proveen y a que se adecuan más a las expectativas del usuario\footnote{Otros toolkits de 
	desarrollo visual (como Qt o Gtk) proveen ese tipo de comportamiento 
	de auto-actualización por omisión, aunque la experiencia de programar en ellos, 
	como en la mayoría de lenguajes, es fracturada en el sentido de que no se cuenta 
	con un continuo entre la interface, el lenguaje de programación, el sistema de 
	gestión de código fuente y la misma interface.
	En ese sentido, las demoras que pueden haber al elegir aprender una tecnología 
	no tan popular como Pharo/Smalltalk son compensadas por la integración del entorno 
	y la uniformidad del lenguaje y el paradigma, pues como se dijo, aprender en entorno 
	y modificarlo/extenderlo para proyectos particulares, como Grafoscopio, ocurre desde 
	una experiencia consistente e integrada todo el tiempo.}. 
Finalmente fue posible implementar la característica de auto-actualización, para lo cual 
fue necesario entender el concepto de \emph{ports} (puertos) y el envío de información entre ellos. 
Llegar a dicha comprensión implicó reducir la funcionalidad de auto-actualización a su mínimo. 
Para ello se creó, en pocas líneas de código y después de quitar todas las complicaciones extra, 
una interface a la medida que se pudiera auto-actualizar con el uso de puertos (véase figura 
\ref{ui-auto-actualizar}).
Desnudar al problema para llegar a su escencia fue proceso que tardó casi semana y media y fue 
de los más demorado de entender y programar en mi posición de novato.
Sin embargo, esta experiencia de un ejemplo funcional mínimo que representara la esencia del
problema, para pedir ayuda en las comunidades de Pharo o brindarla en las comunidades locales,
demostró ser un aprendizaje clave para el futuro.

\begin{figure*}%
	\centering
	\includegraphics[width=0.45\linewidth]{Parte2/autoactualizacion-en-navegador-minimalista-panel-original.png}
	\qquad
	\includegraphics[width=0.45\linewidth]{Parte2/autoactualizacion-en-navegador-minimalista-panel-actualizado.png}
	\caption[Navegador minimalista para probar la auto-actualización]
	{Navegador minimalista para probar la auto-actualización. Izquierda, 
		en su estado original, como estaban los dos desde el código. Derecha actualizado. 
		La esquina superior derecha con una marca en naranja es la marca clásica de \emph{Pharo} de 
		que ese panel ha recibido una actualización que aún no ha sido procesada (se le conoce como \emph{dirty}}%
	\label{ui-auto-actualizar}%
\end{figure*}

Cuando la actualización automática del contenido en los nodos funcionó el siguiente paso fue 
la persistencia de la información, es decir, su representación y almacenamiento para ser
transmitida y usada posteriormente.
Es de anotar que Pharo tiene un modelo de persistencia por omisión bastante funcional, 
llamado la imagen, que permite almacenar el estado de todo el entorno y su ejecución y retomarlo 
de nuevo, justo donde se dejó, con lo cual las primeras fases del prototipado pueden aplazar problemas de
persistencia y delegarlos en la imagen (de hecho durante varias semanas Grafoscopio no tenía
un modelo de persistencia propia y los documentos en él se guardaban dentro de la imagen).
La imagen también habilita el tener entornos portables y durables de computo y estar en
condiciones de leer lo que se ha almacenado en ellas incluso décadas después (véase figuras
\ref{fig:trino-persistencia} y \ref{fig:persistencia-imagen}).

\marginpar{
	\captionsetup{type=figure}
	\centering
	\includegraphics[width=\marginparwidth]{Parte2/trino-persistencia.png}
	\caption[Trino sobre investigación reproducible y perdurable]
	{Trino sobre investigación reproducible y perdurable usando el modelo de persistencia
		de Pharo, basado en la imagen. (ver \url{https://is.gd/4TiNrH}). }
	\label{fig:trino-persistencia}
}

Sin embargo, se requería otro modelo de persistencia, distinto a la imagen de Pharo, que 
permitiera almacenar y transmitir las libretas interactivas por fuera de ella y versionarlas,
de modo que las personas pudiesen colaborar y construir dichos documentos interactivos
usando los habituales archivos de documento a los que se encuentran habituados y las
utilidades para trabajar con ellos (enviarlos por correo, trazar su historia, etc.)
Para esto se usó la librería STON desarrollada por \cite{caekenberghe_smalltalk_2012}.
Esta librería está inspirada en el popular y sencillo lenguaje de serialización de datos JSON, 
pero tiene la ventaja de poder expresar el árbol de manera directa y sencilla, incluidas las 
referencias (circulares o no) entre diferentes objetos y su lugar en la jerarquía de clases de Pharo. 
STON sabe de los objetos dentro de Pharo y puede serializarlos a archivos de texto o a partir de ellos 
cargarlos dentro de Pharo de nuevo.
Así, cada nuevo objeto definido, como los nodos del árbol, fueron mapeados en archivos de texto plano, 
que pueden ser compartidos con sólo enviarlos por correo, versionados fácilmente para guardar su historia 
y cargados de nuevo en Grafoscopio para continuar con su edición visual e interactiva.

Las únicas inquietudes fueron referidas a si se podía representar el texto incluidas los saltos de línea 
de manera que no ocuparan líneas largas con caracteres especiales (como \texttt{\textbackslash{}n}) y
cómo quitar algunos metadados del texto, como la fuente, el color, etc. de manera que su representación 
se mantuviese sencilla.
La resolución de ellas, por el propio autor del software, permitió un formato altamente eficiente
y amigable para la producción de documentos estructurados en este esquema arbóreo y, por ejemplo,
el código fuente del Manual de Grafoscopio ocupa 140 kb para un documento de PDF de 60 páginas y
1.9 Mb, mientras que el código fuente del Manual de Periodismo de datos ocupa cerca de 600 kb
para un documento PDF de 13 Mb y 316 páginas, lo cual muestra la eficiencia del formato de
persistencia desarrollado y el esquema de referencias a archivos de imágenes (PNG, JPEG, etc)
por fuera del documento (se hablará en mayor de estos documentos en la sección sobre prototipos).
%PENDIENTE: Referencias a los manuales dentro de este documento.

\begin{figure*}[th]%
	\centering
	\subfloat[Explicación de la simulación]{
		\includegraphics[width=0.45\linewidth]{Parte2/multiagentes-2.jpg}
		\label{subfig:multiagentes-2}}
	\quad
	\subfloat[Simulación ejecutación]{
		\includegraphics[width=0.45\linewidth]{Parte2/multiagentes-3.jpg}
		\label{subfig:multiagentes-3}}
	\caption[La imagen: Persistencia sofisticada]
	{La imagen en Pharo y Smalltalk son una manera de persistencia sofisticada,
		que permite almacenar y retomar el trabajo que se hecho incluso décadas
		después. 
		El trino en la imagen \ref{fig:trino-persistencia} muestra como es
		posible hoy ejecutar la simulación hecha en 2007 para una investigación
		de maestría \cite{luna_cardenas_resolucion_2007}. 
		Las figuras, \ref{subfig:multiagentes-2}
		y \ref{subfig:multiagentes-3}, son un detalle de dicha simulación 
		ejecutándose en noviembre de 2017.
		La simulación y su material acompañante se puede descargar desde:
		\url{http://mutabit.com/repos.fossil/offray-maestria-tesis/}}
	\label{fig:persistencia-imagen}%
\end{figure*}

Gracias a STON, la persistencia fue muy fluida y sólo tomo unas cuantro líneas de código. 
En la figura \ref{persistencia} se ven una captura de pantalla de un trozo del árbol que 
representa la estructura completa de las primeras versiones preliminares para este escrito,
incluidos nodos invisibles y otros metadatos, y, aprovechando su brevedad, el código que 
implementa la persistencia del árbol en disco duro (disponible desde la opción de menú 
``\texttt{Notebook\ \textgreater{}\ Save\ as...}'').

\begin{figure*}[tb]%
	\centering
	\subfloat[]{
		\includegraphics[width=0.35\linewidth]{Parte2/arbol-detalle.png}
		\label{subfig:arbol-detalle}}
	\qquad
	\subfloat[]{
		\includegraphics[width=0.57\linewidth]{Parte2/persistencia-guardar-como.png}
		\label{subfig:persistencia-guardar-como}}
	\caption[Grafoscopio: Persistencia primeras versiones]{Persistencia.  
		Izquierda, detalle de un trozo del árbol que representa todo este escrito. 
		Derecha, el método completo que implementa la persistencia de dicho árbol en pocas líneas 
		de código gracias a STON.}%
	\label{persistencia}%
\end{figure*}




















\marginpar{
	\captionsetup{type=figure}
	\centering
	\includegraphics[width=\marginparwidth]{Parte2/sorted_binary_tree_preorder.pdf}
	\caption[Recorrido de un arbol en preorden]
	{Recorrido de un arbol en preorden, que es clave para pasar del documento


		arbóreo en Grafoscopio, a documentos ``lineales'' en formatos como














		PDF, HTML, doc (Word) y/o odt (Writer), empleando el excelente conversor










		Pandoc.
		(Imagen tomada de la Wikipedia: \url{http://ur1.ca/igfow})}
	\label{fig:arbol-preorden}
}





La última característica a implementar antes de empezar la escritura del artículo fue el

recorrido del árbol en preorden.
Dicho recorrido permite ir desde la raíz del árbol a cada uno de los nodos hijos hasta 
alcanzar el nodo más profundo dentro de una jerarquía y luego aplicar el mismo recorrido a los 
nodos restantes (véase figura \ref{fig:arbol-preorden}).
Existen diferentes estrategias para dicho recorrido, pero las que a mi juicio es mejor 
y más elegante es la definición recursiva del recurrido en preorden, en la recorren un árbol en 
preorden consiste en visitar un nodo raíz y luego visitar en preorde los subárboles restantes.
La implementación de la recurrencia en un entorno objetual puro es diferente de los entornos mixtos, 
como Python y otros similares, en los que pueden enmascarar o desviarse del comportamiento objetual 
detrás de otras sintaxis.
La sintaxis de objetos puros Pharo, por el contrario, sólo permite el hecho de que sean los 
mensajes entre objetos los que permitan implementar la recurrencia y el hecho de que las 
variables pertenezcan a los objetos del dominio y sus métodos y no sean externas a los mismos.
Pensar desde este enfoque purista implicó revisar la literatura(Kent Beck, n.d.) y volver a 
los fundamentos, reimplementando parte de los ejercicios clásicos como las Torres de Hanoi
(Ted Kaehler and Dave Patterson 1986) e hizo que la implementación tomase un par de dias.
Una vez se tuvo el recorrido en preorden, la exportación a formatos como Markdown y PDF fue
directa y se inicio la escritura como tal del artículo, borrador para este capítulo y otros
documentos, como los manuales y tutoriales interactivos, desarrollados a lo largo de la 
investigación (véase capítulos  \ref{prototipos} y \ref{materialidades}).
La escritura tales documentos permitió afinar la funcionalidad del prototipo, la documentación 
y de las prácticas de aprendizaje y comunitarias alrededor de ellos, siguiendo los ciclos de
realimentación ilustrados en la figura \ref{fig:realimentacion-artefacto-escritura}.
Una descripción detallada de este proceso está en el capítulo \ref{materialidades},
debido a su caracter clave durante toda esta investigación y sus repercusiones en
otras investigaciones y prácticas comunitarias venideras.









La integración con referencias bibliográficas se hizo a través del
gestor de código abierto Zotero vía Bibtex y las etiquetas
\texttt{{[}@autor{]}} colocadas dentro del texto, que soporta el
Markdown extendido de Pandoc (véase figura \ref{integracion-zotero}).
Las referencias bibliográficas eran almacenadas en línea desde Zotero, a
través de su integración con firefox. también se colocaban metadatos y
se hacían anotaciones y luego eran exportadas a formato BibTeX. 
Una vez en dicho formato se hacía un post-procesamiento desde Grafoscopio, 
que permitía asociar llaves personalizadas a las referencias bibliográficas
y se integraba la bibliografía al PDF final vía Pandoc.\footnote{El
	soporte para llaves personalizadas esta provisto de manera limitada en
	Zotero y se hace a través de \emph{plugins} como Better BibTeX
	(ZotPlus n.d.). Sin embargo no fue claro cómo lograr una exportación
	fluida. Después de consultar la Interface de Programación de
	Aplicaciones de Zotero (Zotero API, por sus siglas en inglés) ((Fritz
	n.d.), (Amanda Morton n.d.), (``Zotero Web API Documentation V. 3''
	n.d.), (``Zotero with LaTeX and BibTeX - Zotero at MIT - Research

	\end{itemize}
	\item
	Este escrito y otra documentación:
	\url{http://mutabit.com/deltas/repos.fossil/grafoscopio/} (Luna
	Cárdenas n.d.)
\end{itemize}








Grafoscopio, según su sitio web, es: 

\begin{quote}
	una herramienta amoldable para documentación interactiva y visualización de datos, que está siendo usada para ciencia abierta, ciudadanas y de garage, investigación reproducibles, (h)ac(k)tivismo, innovación abierta y comunitaria , visualizaciones de dominio específico, y periodismo de datos, entre otros usos actuales y potenciales. Grafoscopio está cubierto por una licencia libre y de código abierto (MIT) y se socializa, realimenta y modifica en un taller-hackatón recurrente de una semana llamado el Data Week, que está orientado principalmente desde preguntas ciudadanas mediadas por datos y visualización.
	
	Grafoscopio es y usa ``infraestructuras de bolsillo'', sencillas y autocontenidas, que pueden ejecutarse On/Off-line, 

	\subfloat[]{
		\includegraphics[width=0.45\linewidth]{./Parte2/artefacto-realimentacion.png}
		\label{subfig:artefacto-realimentacion}}
	\quad
	\subfloat[]{
		\includegraphics[width=0.45\linewidth]{./Parte2/markus-artefacto-realimentacion.jpg}
		\label{subfig:markus-artefacto-realimentacion}}




	\caption[Algunas charlas del ESUG 2016]
	{Explicación.}
	\label{fig:esug2016}
\end{figure*}

\chapter{El Data Week, las Data Rodas y otros encuentros}\label{dataweek}

el sistema a través de paquetes y cómo se podía empezar a navegar y deconstruir dicho conocimiento.
Esto constituyó un avance respecto a lo anterior, pero no había un paquete de visualización 
totalmente usable por un participante 
al final del evento, ni mucho menos por alquien externo.
Quedó más claro que la intensión del \emph{Data Week}, en parte, era iterar sobre esos 
prototipos imperfectos e irlos mejorando con sucesivas ediciones.

La tercera edición se probó partir el \emph{Data Week} en dos sesiones, ambas de jueves a 
sábado, de 2:30 PM a 6:30 PM (ocurridas en febrero 25 al 27 y marzo 3 al 5 de 2016).
Si bien estas sesiones implicaban que algunas personas deberían contar con dos tardes dentro 
del horario laboral habitual, o bien los asistentes contaban con flexibilidad del tiempo, 
o bien era un permiso que se podía solicitar en caso de que no.
Lo cierto es que esta forma de organización generó la asistencia más regular, con jornadas 
suficientemente intensivas para avanzar el el problema.
Una particularidad acá fue el cambio del problema, para adecuarlo a las necesidades percibidas 
en la investigación Ciudad de Datos, según uno de los coinvestigadores.
Esto trajo la ventaja de triangular información: ya no estábamos más centrados en los temas de 
redes sociales, sino que podíamos poner a circular en ellas información extraida de otros lados, 
en este caso del portal de contratación pública, en aras de articularnos con la naciente comunidad 
\emph{Open Data Colombia} (OpenDataCo) y el \emph{scrapper} de contratos del portal 
gubernamental colombiano ``contratos.gov.co'' (prizbilla-xxx).
Además nos alineaba con otras comunidades como OpenBugets\footnote{\url{http://openbudgets.eu/}}, 
OpenSpending\footnote{\url{https://openspending.org/}} y algunos proyectos y temáticas de la 
Open Knowledge Foundation\footnote{\url{https://discuss.okfn.org/}}.

También mostraba el potencial del trabajo desde individuos y pequeños colectivos: por ejemplo, 
el proyecto OpenSpending mostraba como 76 países habían liberado 1105 datasets conteniendo 
28'369.534 registros [@OpenSpending, index].
El scrapper de un sólo individuo, y la organización y limpieza posterior en la comunidad 
OpenDataCo y el Data Week 3ra edición, logró liberar (XXX)  registros para 15 años de contratación.
Sin embargo, tenía un riesgo, como se señaló antes de la ejecución del taller al coinvestigador, 
y es que familiarizarse con los datos y sus visualizaciones y lograr continuidad y resultados 
con el problema era algo difícil para un problema de una semana, si nadie se iba a ocupar de 
dichos datos después.
Liberar los datos no bastaba, había que comprometerse con encontrar las estructuras e historias 
dentro de dichos datos y contarlas.
A esto se sumaron dificultades con la conexión entre Pharo y SQLite, el motor de datos para 
trabajar el dataset de contratos, que, si bien fueron temporales debido a la transición a la 
siguiente versión de Pharo, en un evento intensivo como el Data Week, cobraron su tiempo y causaron 
descontento entre los participantes, un par de ellos reportó que no concebián como una cosa que en 
los demás lenguajes de programación está resuelta, en este termina siendo un impedimento tan grande 
para el tratamiento de datos.
Finalmente logramos rodear el problema, no sin una considerable pérdida de tiempo y fluidez 
durante la realización del taller/hackatón.
Aún así los asistentes mantuvieron el interés y hubo 3 sesiones de un día, posteriores al evento, 
para continuar con el problema y la solicitud de crear una lista de correo para los asistentes 
al Data Week.
Si bien dicha solicitud no fue implementada inmediatamente, e invité a la gente a la comunidad 
de OpenDataCo, con el ánimo de dinamizarla, la implementé con el tiempo, al ver el interés 
sostenido de los participantes y la necesidad de tratar temas específicos a los interesados 
en Grafoscopio y los asistentes al Data Week.

Desde la edición 4 del data week se consolidó el esquema, de la anterior, de dividir el encuentro 
en dos sesiones.
Esta se realizó en el colaboratorio de Medellín (ver fotos), también en alianza con el proyecto 
Ciudad de Datos, pero se volvió al problema de visibilizar la comunicación en Twitter, ya no 
desde los mapas del silencio, sino desde un proyecto llamado \emph{data selfies}, que se basaba 
en la información provista por cada usuario de Twitter, en lugar de la información desde el scrapper.

La edición 5 del Data Week se realizó de septiembre 22 al 24 y 29 de septiembre a octubre 1 de 2016.
En esta edición se continuó con el problema de los Data Selfies, pero hubo interesantes
exploraciones de teorías y proyectos relacionados con lo que se planteaba en el evento y
se mejoró la infraestructura que soportaba la interconexión con repositorios de documentación
en Fossil.

La edición 6 fue una edición ``unipersonal'' e hizo énfasis en la \emph{hackatón} como una
forma de resistencia y crítica civil a los proyectos de enagenación de lo público, 
particularmente las bibliotecas, para la apropiación de los privados, particularmente 
Microsoft, sobre la base de enseñar a todos a hacer código.
Esta perspectiva crítica intentaba ilustrar otras formas de empezar con la programación,
otras iniciativas y comunidades que se acercaban críticamente e ellas y por ello continuo
la numeración de ediciones que se llevaban hasta el momento, pues si bien la dinámica fue 
distinta,se construía desde las mismas perspectivas.
El énfasis acá estuvo en mejorar la infraestructura, usando lo desarrollado en la edición
anterior.

%NOTE: Ediciones 7, 8, 9 , 10, 11 y 12.

\section{Espacios virtuales: Etherpads, Lista de correo, Telegram y Fossil }

	\label{fig:roassal-infomed}
\end{figure*}

La descripción detallada de este problema y su análisis están en Gil 2015.
Acá se mencionarán los hitos de este abordaje, que complementan el texto del blog:

\begin{itemize}

	\item Pasar de \emph{tener la información} como lugar de inicio, a \emph{usar su ausencia} 
		como lugar problémico e investigativo.

	\item Se partió de una visualización base de \emph{The Guardian}, respecto a ausencias
		y presencias, en este caso de derechos en la población homosexual, como modelo del tipo
		de visualización que se quería (veáse figuras tales y pascuales).

	\item Se adaptó una visualización preexistente, que era para información jerárquica, 
		de modo que permitiera trabajar con la información recolectada, que era de naturaleza
		tabular.
		Se hizo un algoritmo de conversión de formato tabular a jerárquico y se creó un Lenguaje
		de Dominio Específico (DSL, por sus siglas en inglés) para hablar del problema en cuestión.

	\item Yaneth Gil participó de la visualización como experta de dominio, indicando qué quería ver,
		qué formatos tenían los datos, parámetros estéticos de las visualizaciones e incluso haciendo
		comentarios sobre los algoritmos implementados en Smalltalk, si bien no programaba este lenguaje.
		Yo comentaba qué se podía implementar, forzaba el entorno y mi conocimiento para lograr algunas
		de sus visualizaciones, y establecimos un sistema de convenciones \emph{ad-hoc} para poder 
		hacerle consultas a los datos.
		Se produjo, así, una negociación entre mi rol como visualizador/programador y el de ella como 
		experta de dominio.

	\item La solución fue implementada de manera ágil aunque poco elegante. 
		Habían muchos parámetros en los mensajes del DSL y no se usaba la infraestructura de
		\emph{builders}, que permitía abstraer el problema y generar visualizaciones sin
		transformaciones de datos y el uso de convenciones \emph{ad-hoc}, que facilitaran su visualización
		y consulta.
		Aún así fue funcional y dio cuenta de los tiempos estrechos para la implementación.	

	\item En las distintas implementaciones, tanto de la solución rápida, como de las más elegante, 
		se contó con la ayuda de la comunidad de Pharo, particularmente de Miltón Mamani, primero
		en un encuentro en Argentina, de la comunidad de Smalltalk, luego de manera remota por chat
		y finalmente durante mi pasantía doctoral en Chile.
		El uso de soluciones cada vez más formales tuvo que ver con mi comprensión progresiva
		del problema, el motor de visualización y sus constructos y maneras más acertivas de 
		participar en la comunidad, pues desde el comienzo Miltón estaba ofreciéndome soluciones
		formales (construyendo \emph{builders}), pero yo no tenía los preconceptos adecuados para
		aprenderlos y quería continuar con lo que ya tenía y sacar un prototipo funcional desde
		lo que ya entendía.
		Esto a su vez fortaleció la motivación para crear en los \emph{Data Weeks} caminos de
		aprendizaje que facilitaran los recorridos para otros novatos, a partir de mis errores y rutas,
		pero sin tener que repetirlas.
		Algunos \emph{builders} y problemas pre-tratados ayudarían a futuros aprendices, 
		a enfocarse en lo conceptual y crear código más suscinto, comprensible y elegante.
\end{itemize}

\section{Panamá Papers: investigación reproducible y activismo de datos incluyente}



Otro proyecto realizado durante la pasantía doctoral en Chile fue el de los \emph{Panama Papers}.
(luna 2016-pp).
En este periodo, además se mejoraron las visualizaciones de de medicamentos vía \emph{builders}
y también la interfaz gráfica de Grafoscopio empleando el puente entre el \emph{framework} de 
Spec y las herramientas adaptables \emph{GT Tools} del proyecto Moose, desarrollado por
Johan Fabri y con su acompañamiento.

\begin{figure*}[tbh]
	\centering
	\subfloat[]{
		\includegraphics[width=0.45\linewidth]{./Parte2/Countries_implicated_in_the_Panama_Papers.png}