\chapter{Grafoscopio}\label{grafoscopio}
%PENDIENTE: https://www.slideshare.net/MarcusDenker/perfection-feedback-loops-or-why-worse-is-better-65540840
%Slide 33: Todo lo terminado encarnará su propia critica.
\epigraph{Todo lo que puedas *terminar* encarnará su propia crítica}
{-- Markus Denker, Perfection \& Feedback Loops or: why worse is better \url{https://is.gd/worse_better}}
Grafoscopio\footnote{Quisiera agradecer especialmente a Yaneth Gil y Andrés
Calderón por escuchar varias de mis reflexiones y padecimientos durante
el desarrollo temprano de este escrito/prototipo.
A la primera, le agradezco particularmente la conversación sobre el nombre
del software y al segundo, su ayuda con la compresión de la recurrencia en
el árbol \(n\)-ario (efectivamente, como dice la broma de Internet: para
entender la recurrencia, primero hay que entender la recurrencia).}
es el artefacto digital central de esta tesis.
Es el prototipo que permite explorar la pregunta de investigación sobre
``¿cómo cambiamos los artefactos digitales que nos cambian?'' y construir
hipótesis y prácticas al respecto.
Alrededor de él se conformó una comunidad, con distintos espacios y
lugares de encuentros y se construyeron distintos artefactos(ver capítulo \ref{dataweek}).
Este capítulo explora su historia y los conceptos fundamentales alrededor del mismo\footnote{
Este capítulo vincula y retoma largos apartes de un texto en borrador que fue escrito por
el autor de esta tesis como primer artículo sobre Grafoscopio, titulado ``Metáforas y
artefactos alternativos de escritura para jalonar la investigación abierta y la ciencia
ciudadana y de garage'' %REF
y los extiende desde los desarrollos y perspectivas desde ese entonces hasta el momento
de cierre de la tesis.
En ese sentido, el texto de este capítulo es una reelaboración de lo que ocurrió
después del examen de candidatura, del mismo modo que las primeras partes de esta
tesis retoman y se reelaboran sobre los textos presentado para dicho examen.
\\
Mis estudiantes de la cohorte 11B de la Maestría en Didáctica de las
Ciencias de la Fundación Universitaria Autónoma de Colombia leyeron,
como una de las actividades de nuestro seminario de software libre y
educación, borradores de este artículo e hicieron valiosos comentarios.
}.
Se considerarán las motivaciones e historia detrás de Grafoscopio, así como
los movimientos conexos al mismo: investigación reproducible, ciencia de garage
y ciudadana, visualización y activismo de datos, objetos activistas, entre otros
y cómo Grafoscopio es un prototipo de software para escritura no lineal y en
profundidad tanto para la academia, como consecuente con esos movimientos conexos.
Dicho prototipo, por tanto usa estándares abiertos, software libre y repositorios de
código, para disponer para otros el conjunto de herramientas y datos que permitan mayor
trazabilidad y transparencia en la construcción de diversos objetos de conocimiento, en
particular el texto escrito, pero sin limitarse a él.
Se mostrarán las ideas claves sobre los temas relacionados de esta tesis respecto
a la construcción de artefactos autorreferenciales, que complementan las dinámicas
autopoiéticas propias de las comunidades de práctica, y del desarrollo de
software como labor artesanal.
Puede parecer paradójico que se de cuenta de esas otras formas y objetos de conocimiento,
precisamente a través de la escritura académica, en artículos indexados y esta misma tesis,
pero esto habilita un puente entre aquellas prácticas y objetos visibles e invisibles.
Esta parte del texto, por tanto, es un escrito que reflexiona sobre la escritura
académica, como forma de comunicación y producción por excelencia dentro
de la academía misma y de ella hacia afuera, introduciendo nuevas metáforas escriturales
y artefactos digitales para deconstruirla y habla precisamente sobre tales metáforas y
artefactos, desde \emph{el interior} de los mismos, pero permitiendo la creación de otros
artefactos ``externos'', como los textos para someter a publicación, sin limitarse a ellos,
ni validarse exclusivamente mediante la escritura académica.
%Ello permitirá la conexión con los dos capítulos siguientes, referidos a las
%dinámicas que se desarrollaron alrededor de Grafoscopio (Data Weeks, Data Rodas y
%otros encuentros), así como los otros artefactos digitales que se construyeron
%gracias a la interacción entre Grafoscopio y tales dinámicas.
\section{Investigaciones y ciencias otras, objetos de investigación reproducibles y
activistas}\label{parientes-cercanos-de-oruxedgenes-distintos-investigaciuxf3n-y-ciencia-abiertas-ciencia-de-garaje-ciudana-objetos-de-investigaciuxf3n-y-activistas}
Como se apreció en los antecedentes, Grafoscopio tenía la intensión de explorar
formas de escribir diferentes, que permitieran amplificar las voces de las comunidades
de base, usando maneras de argumentar desde los datos y las visualizaciones, en particular
en relación con las interacciones entre dichas comunidades y entidades estatales.
Ejemplos de ello se empezaron a avisorar en la Gobernatón y los prototipos de
\emph{Indie Web Science}, antes abordados.
Grafoscopio también tenía la intensión de visibilizar los múltiples objetos
de investigación, de los cuales la academia suele no dar cuenta, debido a las
prácticas de validación de saberes que privilegian excesivamente lo escrito y la
publicación indexada.
Como se vera en detalle más adelante, estas dos búsquedas tenían una intensión común:
construir nuevas metáforas que a su vez permitiesen adquirir nuevos alfabetismos
sobre escritura, mediada por código, datos y visualización, lo que, a su vez,
permitiera deconstruir la metáfora original: \emph{cambiando así el artefacto que nos cambia}.
En ese sentido las elecciones hechas, por ejemplo, que el texto se presente como un árbol,
son temporales y puntos de partida para deconstruir dichas elecciones nuevamente.
Distintas iniciativas, colectivas e individuales están deconstruyendo y reconfigurando las
prácticas con las cuales se apropia, produce y comunican saberes.
Se agrupan bajo distintas denominaciones, como investigación y ciencia abiertas,
ciencia de garage, \emph{research object}, \emph{activist object}
(se hará referencia a ellas de modo colectivo con la sigla ICACG), complementado y en muchas
ocaciones contrastando críticamente las maneras y lugares hegemónicos desde los que se realizan
las labores de apropiación, producción y comunicación de saberes al interior de la academia y se
repiensan los pactos entre esta y la ciudadanía.
Pues, como diría \cite{lafuente_critica_2013},
``la divulgación no es el único pacto posible entre ciencia y sociedad''.
Podemos, entonces, imaginar tránsitos de doble vía de saberes y comunicación, que también
van desde la ciudadanía hacia las instituciones científicas para revertir esa lógica
donde las comunidades son vistos como simples ``objetos de estudio'' y se convierte
en ``sujetos estudiosos'' y donde en tampoco son ``usuarios finales'' de lo que la
ciencia produce y es mediado por el mercado y entregado a ciudadanos y comunidades vía la
tecnología.
Los colectivos y e individuos, en su caracter de académicos vinculados a las instituciones,
como ciudadanos fuera de ellas, o en algún lugar intermedio, están pensando en maneras distintas
de comunicar las respuestas que saberes académicos tradicionalmente se han hecho, de colocar
nuevas preguntas en la intersección entre saberes o de abordar de manera más horizontal y
participativa la construcción de saberes y la formulación de preguntas y respuestas.
Todas esas nuevas prácticas del ICACG tienen en común la idea de hacer más transparente, abierta
y participativa la construcción de saberes.
Esto implica descentrarse del producto, usualmente el texto escrito, desde el que se da cuenta de
los resultados de investigación, y visibilizar más el proceso.
Construir un puente entre el producto escrito y el proceso que involucra otros artefactos,
como bases de datos, entrevistas, repositorios y artefactos digitales de código, implicará
nuevas prácticas académicas que pasarán por lo escritural, pero que también necesitan otro tipo
de metáforas alrededor de la escritura, que la conecten con todo lo invisible que esta deja atrás.
El texto publicado, es entonces sólo la ``superficie'' de la investigación, pero el acto de
escribir para la academia debe contar con artefactos que den cuenta de sus profundidades y de
su caracter no lineal, ya que, además, no vamos del título a las conclusiones de manera organizada,
sino que en la medida en que exploramos un problema, se nos ocurren en distintos momentos los
elementos que luego incorporamos a esta narrativa lineal y ordenada del texto final.
La ICACG y los objetos de investigación y activistas son parientes cercanos,
en el sentido que consideran maneras alternativas de apropiar, construir y comunicar
conocimiento y otros pactos y preguntas posibles en la relación entre ciencia y ciudadanía,
que van más allá de la divulgación de una vía entre las instituciones científicas y
académicas y la ciudadanía en general.
A pesar de estar interconectados, entre estos modos de hacer también existe un dialogo
crítico y en ocasiones contrapuesto y no es de extrañar que, al ser un discurso y práctica
emergentes, los lugares donde las deficiones y prácticas se consolidan sean principalmente
sitios en línea, sin publicaciones canónicas fruto del acuerdo, aunque eso sí, muchas
iniciativas cuentan con el respaldo de prestigiosas instituciones académicas y con intereses
en las prácticas que ocurren tanto en el Norte Global, como en el Sur Global.
Consideraré en este apartado algunas definiciones, a fin de dar una mirada panorámica
e introductoria al fenómeno, sin ahondar en los diálogos críticos alrededor del mismo.
La \cite{wikipedia_open_2014} define la investigación abierta como:
\begin{quote}
La investigación abierta es conducida en el espíritu del software libre
y de código abierto. De modo similar a los esquemas del código abierto,
que son construidos alrededor del código fuente que es hecho público, el
tema central de la investigación abierta es dar cuenta clara de la
metodología disponible libremente vía Internet, junto con cualesquiera
datos o resultados extraídos o derivados de ellos. Esto permite la
colaboración masiva distribuida y una en la cual cualquiera pueda
participar en cualquier nivel del proyecto.
[...]
Si la investigación es de naturaleza científica, es frecuentemente
referida como ciencia abierta. La investigación abierta puede también
incluir ciencias sociales, humanidades, matemáticas, ingeniería y
medicina.
[...]
La investigación abierta está preocupada por hacer la investigación
científica más transparente, más colaborativa y más eficiente. Un
aspecto central es proveer acceso a información científica,
especialmente a la investigación publicada es revistas académicas y a
los datos subyacentes, que mucha de la ciencia tradicional intenta
ocultar. Otros aspectos son formas más abiertas de colaboración e
involucramiento con una audiencia más amplia, incluyendo científicos
ciudadanos.
\end{quote}
La ciencia abierta es, entonces, un subconjunto de la investigación
abierta, que involucra varios campos científicos.
Sin embargo la investigación abierta va mucho más allá de los campos
científicos.
En nuestra experiencia en los Data Weeks y Data Rodas y otros encuentros,
fue recurrente la presencia de periodistas interesados por el campo
del periodismo de datos, activistas de derechos humanos en entornos digitales,
libertad de expresión, memoria y privacidad, entre otros.
Incluso hay un tema de investigación reproducible, %PENDIENTE:
que se deriva de la investigación abierta y que pretende que las
afirmaciones hechas en la investigación puedan ser contrastados y
extendidos por cualquier lector o coinvestigador.
En el caso de Grafoscopio, como veremos en los prototipos del capítulo %PENDIENTE
este permite acceder a infraestructura para investigación reproducible que
es de bajo costo y altamente portable y poderosa, útil a todos los perfiles
antes mencionados..
Por otra parte, el proyecto del \cite{research_object_research_nodate} dice:
\begin{quote}
Los resultados útiles de la investigación no son sólo publicaciones
tradicionales. En cambio ellos son todo lo demás que entra en y soporta
una investigación.
[...]
Los ``Objetos de Investigación'' describen un número de inciativas y
abordajes que tratan de describir y asociar todo este contenido junto en
un mecanimos legible por máquinas de modo que pueda ser más fácilmente
encontrado y compartido.
[...]
Aún más, con artefactos de investigación asociados y descritos de manera
legible por máquinas, podemos empezar a explorar incluso formas más
interesantes y novedosas de hacer la investigación reutilizable.
[...]
Un conjunto de principios junta muchas de esas iniciativas dispares. Lo
que difiere grandemente son los mecanismos que esas iniciativas usan
para lograr esos objetivos. Sin embargo al procurar seguir un conjunto
común de principios, significa que es más probable ser ampliamente
interoperable y reusable
\end{quote}
Dichos principios son (\cite{research_object_research_nodate}, ibid) :
\begin{quote}
\textbf{Identidad}: Usar identificadores globalmente únicos como nombres
para las cosas. Por ejemplo DOI's para publicaciones o ORCID para
investigadores. Esto es por dos razones:
\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
Para que podamos hablar de formas no ambigüas sobre las cosas.
\item
Para que la gente pueda encontrar esas cosas.
\end{enumerate}
\textbf{Agregación}: Usar algún mecanimos de agregación para asociar
cosas que están relacionados o hacen parte de una más amplia
investigación, estudio, etc. Este es un valor nuclear de los objetos de
investigación - proveer los artefactos de soporte que hacen la
investigación potencialmente útil para alguien más.
\textbf{Anotación} Proveer metadatos adicionales acerca de esas cosas,
cómo se relacionan entre sí, de dónde vienen, cuándo, etc. Esto ayuda a
la gente a descubrir que datos son relevantes y potencialmente útiles.
\end{quote}
En cuanto al objeto de investigación, Grafoscopio aborda los principios de agregación y anotación,
al permitir explicitar objetos de investigación relacionados y proveer metadatos a partir de árbol
de escritura, que muestra los orígenes de esos otros objetos y la historia del mismo árbol y el
prototipo de escritura a partir de repositorios de código (se verá más al respecto en la siguiente
sección).
La agregación y anotación se hacen de modo práctico, pero no se usa ningún estandar de metadatos
para la interoperabilidad, salvo importantes estándares \emph{ad-hoc} como formatos abiertos usados
para representar, compartir y publicar el contenido fruto de este prototipo
(STON\footnote{\url{https://is.gd/ston1}}, BibTeX\footnote{\url{https://es.wikipedia.org/wiki/BibTeX}},
Markdown, PDF).
En principio de identidad también se aborda de manera informal, pues en los repositorios de código
se pueden hacer alusión a una copia única de un archivo o estado del sofware en un momento
específico del tiempo y esta investigación ha producido objetos con identificadores más formales
como el artículo \emph{Grafoscopio: A moldable tool for literate computing and reproducible research}
(ver figura \ref{fig:joss-grafoscopio}), cuyo Identificador de Objeto Digital o DOI es 10.21105/joss.00251,
pero valdría la pena considerar la identificación dentro de ciclos de publicación académica y
reproducible como un problema a abordar en el futuro (al respecto véanse las conclusiones).
El \cite{activist_object_curating_2014} afirma:
\begin{quote}
Las infraestructuras digitales, las tecnologías mundanas, las arquitecturas
ad-hoc, y los nuevos modos de narrar y documentar están remodelando las
prácticas políticas de activistas y ciudadanos.
Sabemos que las políticas no sólo están hechas de discurso, por el contrario,
están hechas de objetos e infraestructuras que deberíamos considerar
cuidadosamente.
Queremos tomar inspiración de esta idea para aproximarnos a la cultura material
del activismo político.
Específicamente pretendemos explorar las precarias condiciones del diseño improvisado
de los objetos activistas y las implicaciones de las prácticas de documentar y curar
los materiales políticos.
\end{quote}
%\marginpar{
% \captionsetup{type=figure}
% \centering
% \includegraphics[width=\marginparwidth]{./Parte2/grafoscopio-timeline.png}
% \caption[Miniatura, de linea de tiempo de Grafoscopio]
% {Miniatura, de linea de tiempo de Grafoscopio. A través de repositorios de código fuente,
% Grafoscopio, permite trazar la historia de los documentos creadod con él y otros artefactos
% relacionados.}
% \label{fig:nombre}
%}
La deconstrucción acá presente piensa la documentación como un objeto activista, no sólo asociada
a las prácticas políticas explícitas, sino aquellas que día a día transitan en los documentos
académicos que cosifican la relación poder-conocimiento, pues propone otros artefactos para
escribir y publicar dentro y fuera de la academia.
La sección de prototipos, particularmente el Manual de Periodismo de Datos, muestra cómo
esas otras formas de publicar pueden hacerse posibles en la práctica.
También piensa las infraestructuras activistas, pues surge de necesidades sentidas respecto
a la creación de capacidad en comunidades de base desde HackBo, tanto en sus saberes, como
en las materialidades que los soportan, como se verá en los capítulos del Data Week y los
prototipos del Portal de Software Libre y los Data Selfies de Twitter.
Sobre la ciencia de garage \cite{critical_art_emsamble_ciencia_2009} dice:
\begin{quote}
Ciencia de garaje es un término rebosante de posibilidades utópicas; sin
embargo, a diferencia de otras florituras retóricas utópicas, la forma
de producción que describe puede tener un impacto revolucionario en el
paisaje de la vida cotidiana. En su visión más pomposa la ciencia de
garaje se asocia con visionarios excéntricos y hackers de super nivel
que han cambiado el mundo. La bombilla, la radioactividad, los
antibióticos, el sintetizador, el ordenador personal, etc. Todos
comenzaron de alguna manera como trabajos caseros. Puede que los
resultados revolucionarios no sean probables pero sin duda son posibles.
Pero incluso desde una perspectiva más cotidiana hay un montón de
razones para continuar con la ciencia de garaje. Antes de que la Era
Reagan comenzara a minarla, la ciencia ciudadana se fomentaba en EEUU,
incluso por parte del Gobierno (aunque a veces por razones bastante
cínicas). Numerosas publicaciones, revistas y otros proveedores de
ciencia atendían a las necesidades de un nutrido público amateur ansioso
de acercarse a los nuevos sistemas del conocimiento científico y a los
nuevos materiales y procesos de la ciencia. El resultado fue la creación
de una ciudadanía suficientemente enterada de los desarrollos
científicos -- y, todavía más importante, de su aplicación en la esfera
pública -- y con capacidad suficiente para participar de manera
inteligente en las políticas científicas.
No hace falta decir que cuando los neoliberales llegaron al poder se
dieron cuenta rápidamente de que había que parar esta forma de política,
y la mejor manera de hacerlo era detener toda manifestación de ciencia
amateur. Creían que la gestión y el desarrollo del conocimiento debían
llevarlo a cabo pequeños grupos de ``expertos'' que compartían los
valores ideológicos del neoliberalismo, de forma que el conocimiento y
su aplicación pudiera ser controlada únicamente de arriba abajo.
{[}\ldots{}{]}
Para Critical Art Ensemble parte de nuestra lucha ha sido establecer la
ciencia como un lugar popular para la intervención cultural, y de ese
modo contribuir a una pedagogía que otorga poder a la gente para retar a
los expertos, para convertirse en activos participantes en las políticas
del conocimiento de las esferas científica y tecnológica, y expandir las
posibilidades para la producción cultural en las disciplinas
científicas.
\end{quote}
Por su parte, \cite{lafuente_amateurs_2014} conecta a la ciencia ciudadana con
el movimiento hacker cuando afirma:
\begin{quote}
Quienes lucharon por la democratización de la experticia (peritaje,
evaluación) nunca imaginaron que llegaría nada comparable al movimiento
hacker. Originariamente eran unos cuantos programadores que se negaron a
permitir que una empresa pudiera patentar el código, algo que para ellos
era tan absurdo como privatizar las leyes de Newton, los teoremas
matemáticos o el genoma humano. No se pueden reclamar derechos sobre los
descubrimientos, incluidos los anónimos, como es el caso de la lengua,
el folklore o las semillas. Todos son bienes heredados que debemos legar
intactos a nuestros hijos. Inicialmente la resistencia era para defender
el conocimiento de su apropiación corporativa. Pero no tardaron en
mostrarse ecos en muchos ámbitos del saber. Wikipedia, sin duda, es un
hermoso ejemplo de cómo preservar el conocimiento para todos y, lo
mejor, entre todos.
\end{quote}
\begin{quote}
La cultura hacker pronto resonó con la cultura punk. Ambas daban forma a
los anhelos anticonsumistas, antimonopolistas y antielitistas. Ambas
representaban una apuesta por la cultura del DIY, las formas
cooperativas, las prácticas de garaje y la innovación maker. Hace ya
cinco décadas que su presencia no deja de contagiar el mundo de los
negocios, la política y la ciencia. Las nociones de software libre, open
access y creative commons son tan conocidas como el navegador Firefox y
el milagro de Wikipedia. Y es que las culturas hacker adoptan muchas
formas, desde las que se concentran en la tarea de hacer accesible el
conocimiento a las que luchan por liberarlo y, entre medias, todos las
actitudes que se resisten a creer que las cosas son lo que son y nada
más. {[}\ldots{}{]}
\end{quote}
\begin{quote}
Pero la categoría es mucho más amplia: Son hackers quienes desmontan un
coche para tunearlo o quienes hacer una remezcla de sonidos que busca
otras armonías y diferentes maneras de compartirlas; también pertenecen
a esta plural tribu quienes comparten el coche para ir a trabajo, luchan
a favor de la agricultura de proximidad, niegan el derecho a la
propiedad intelectual sobre tests genéticos diferenciales y no le hacen
ascos a la cultura del remiendo, el reuso, la reparación y el reciclado.
En sus formas más blandas los hackers disfrutan haciendo las cosas con
sus propias manos, mientras que su rostro más duro se manifiesta cuando
hacen públicos documentos que prueban que necesitamos otras formas de
gobernanza menos cínicas y mayor transparencia en la vida pública y
empresarial.
\end{quote}
Grafoscopio se relaciona críticamente con los movimientos de la ciencia de garage y ciudadana,
pues precisamente ha ocurrido en el Hackerspace de Bogotá, HackBo, a propósito de dinámicas
relacionadas con otras maneras de apropiar la tecnología y la ciencia y participar desde dicha
apropiación de la vida social y pública.
Acá se piensa la ciencia ciudadana y de garage como aquella que usa los métodos de la ciencia
para diversificar las voces que participan en ella, y que se preocupa, particularmente por
la reproductibilidad verificabilidad y construcción sobre lo dicho, incluso más allá de las
prácticas de publicación actuales.
Grafoscopio procura brindar un amplificador de voces locales, que apela a lo textual, los datos
y la visualización (y los alfabetismos relacionados con ellos) para dicha amplificación.
Vemos que lo que se comparte en las diferentes iniciativas ICACG es la búsqueda de apertura,
transparencia y horizontalidad, pero las preguntas, metodologías y artefactos pueden ser muy
diversos y con posturas que tienen distintos niveles de diálogo y contrapeso a las dinámicas
más hegemónicas de la investigación y la ciencia tradicionales institucionalizadas.
Sin embargo, estos artefactos comparten el hecho de estar descentrados del texto y mediados
por las tecnologías y representaciones digitales, además de permitir las búsquedas mencionadas.
Lo anterior permite enmarcar el prototipo e indagación abordada en este capítulo dentro de
la pregunta por un artefacto que, construido desde lo local y considerando las necesidades
particulares de lugares en el Sur Global, pueda ser usado para prácticas de ICACG y la
exploración y construcción de objetos de investigación y activistas que faciliten los
diálogos críticos y los cruces en los discursos y prácticas antes mencionadas.
\section{Autorreferencialidad}
\emph{Los primeros borradores del capítulo que el lector tiene ante sí, fueron escritas en el
prototipo que acá se describe}.
Es decir que se usó una dinámica de \emph{bootstrapping} (véase figura
\ref{fig:realimentacion-artefacto-escritura}), en la cual un sistema mínimo es usado
para jalonar instancias más complejas del mismo sistema, que luego reemplazan al sistema original.
En este caso, para descentranos del texto como ejercicio académico por excelencia, se inició
escribiendo, de manera emergente y no lineal (siguiendo la jerarquía de clases y métodos de Pharo),
en cambio, un artefacto digital para la escritura académica no lineal, lo que luego nos permitió
escribir el texto desde y sobre dicho artefacto (véase figura \ref{fig:versiones-grafoscopio}),
potenciando otras maneras de trabajar, descentradas del texto.
\emph{La escritura no lineal de código, permitió crear un artefacto digital para escritura
académica no lineal, que a su vez permite reflexionar sobre la misma y visibilizar aquellos
objetos de investigación que la escritura académica usualmente oculta, incluyendo su propia
historia y artefactos conexos, como aquel con el que se inicio este proceso}.
\emph{Este artefacto original es luego extendido en otros contextos y prácticas no académicas,
de visualización y narrativas de datos, de manera que va coevolucionando con dichas prácticas
y las comunidades y personas en ellas que las desarrollan.}
\begin{figure}[th]
\includegraphics[width=\linewidth]{./Parte2/realimentacion-artefacto-escritura.png}%
\caption[Realimentación entre escritura y artefacto en Grafoscopio]
{Realimentación entre escritura y artefacto en Grafoscopio:
Grafoscopio, como prototipo para escritura, se hizo desde una dinámica de \emph{bootstrapping}.
Se creó un artefacto para escribir y luego se escribió con él sobre el artefacto mismo.
Este ejercicio de escritura realimentó el diseño del artefacto.
Se tiene pensado escribir próximamente, ya no sobre el artefacto, sino sobre investigación y ciencia abierta ciudadana y de garage, emplearlo
en talleres transmedia y otras temáticas de modo que esos escenarios venideros aumenten la versatilidad del artefacto y su adecuación
a esos contextos.}%
\label{fig:realimentacion-artefacto-escritura}%
\end{figure}
Acá la idea de autorreferencialidad de la que se ocupa el diseño,
esbozada en la primera parte, toma cuerpo en este artefacto digital y las prácticas con éste
de dos maneras:
\begin{itemize}
\item
Es un artefacto hecho para escribir, en particular sobre el artefacto mismo,
lo cual genera ciclos de realimentación que cambian tanto el artefacto,
como el proceso de escritura (veáse figura \ref{fig:realimentacion-artefacto-escritura})
\item
Las tecnología principal con las que está hecho Grafoscopio, Pharo, es un
metasistema (\cite{denker_perfection_2016}), es decir un sistema tecnológico hecho en sí
mismo, con lo cual permite mayor simplicidad y extensibilidad.
\end{itemize}
Estas dos maneras se combinan en una idea fuerza:
\emph{
Al escribir en Grafoscopio documentos interactivos, que requieren el desarrollo
de competencias computacionales, para modelar y hablar de fenómenos complejos mediados por datos
y sus visualizaciones, el autor de tales documentos aprenderá no sólo el lenguaje y entorno para
su problema/prototipo, sino aquel con el que está hecho todo el sistema.
Es decir, en el camino de hablar sobre un fenómeno mediado por simulación, modelación,
datos y visualización, aprenderá a cambiar la herramienta que le permite establecer dicho diálogo.
Así, {\bfseries la herramienta que cambia sus maneras de pensar, percibir y expresar un problema,
usando documentos interactivos y visualizaciones, puede ser cambiada de vuelta por el autor/lector,
de tales documentos y visualizaciones}}.
\cite{rushkoff_program_2010} habla de una barrera entre los usuarios
y hacedores de artefactos digitales, medida por la programación,
que ilustra particularmente con el software para escribir:
\begin{quote}
[...]Pero la capacidad subyacente de la era de la computación
es de hecho la programación ---la cual casi ninguno de nosotros
sabe como hacer.
Simplemente usamos los programas que han sido hechos para nosotros,
y entramos nuestro texto en la caja apropiada en la pantalla.
Le enseñamos a los niños cómo usar el software para escribir, pero
no cómo escribir el software.
\end{quote}
en ese sentido, Grafoscopio usa la escritura de historias
soportadas/orientadas por datos para tender un puente entre el
``software para escribir'' y ``escribir el software''.
La siguiente parte introduce las condiciones mínimas que debería tener el artefacto para
dar cuenta de otras maneras de escribir, la experiencia de aprendizaje dentro de la comunidad
de práctica que creó la infraestructura para esta solución
%y, siguiendo en la dinámica
%autorreferencial, muestra algunas retratos del proceso y el software,
%hechos desde el software mismo (le he llamado \emph{selfies} del
%prototipo), para finalmente dar cuenta de las conclusiones y
%posibilidades futuras de este ejercicio de prototipado y primera
%aproximación investigativa al problema.
\section{\emph{Bootstrapping}: condiciones mínimas para jalonar la complejidad}\label{bootstrapping-condiciones-muxednimas-para-jalonar-la-complejidad}
Estas fueron las condiciones mínimas que se prefijaron, antes de que el
ejercicio de escritura académica se diera:
\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
Interface gráfica arborea:
\item
Modelo de persistencia de información.
\item
Exportación a formatos externos: Markdown y PDF.
\item
Soporte de históricos y colaboración sobre los textos exportados vía
el control distribuido de versiones de código.
\end{enumerate}
%PENDIENTE: Mover a comunidad?
%Debido a lo breve del prototipado y el hecho del que se trataba también
%de explorar dinámicas de enculturación (Wenger 1999) dentro de
%comunidades de práctica de tecnologías digitales, la mayor parte del
%tiempo estuvo enfocada en aprender el entorno de desarrollo de la
%aplicación (lenguaje de desarrollo, librerías de manejo de archivos y
%construcción de interfaces, herramientas para gestión de código fuente)
%y en lograr las características anteriores, y debido al requerimiento de
%escritura académica como manera de comunicación/validación de estas
%prácticas y artefactos, una muy pequeña parte estuvo dedidaca a la
%organización como escrito académico de tal experiencia.
Una vez se cumplieron con las condiciones mínimas 1 a 3, se inició la
escritura del texto borrador de este capítulo y la exportación a formatos PDF,
para desde allí afinar la funcionalidad requerida de modo que la exportación fuera
más completa: (meta)datos para el escrito de autor y título, soporte a
referencias bibliográficas, y recorridos particulares del árbol del documento que
permitían tomar cierta información para la producción del escrito final,
a la vez que ocultaran otra que era empleada para metadatos,
comentarios, estructuración o para la exportación a diferentes formatos
y/o la publicación de la historia en repositorios de código.
Es decir que las condiciones 1 a 3 fueron prerrequisitos para iniciar con la
exploración de la condición 4 y una vez esta se tuvo se itero sobre las
condiciones anteriores: las condiciones mínimas del prototipo permitían
ejercicios de escritura que a su vez servían como base para mirar qué
había que cambiar en el prototipo, de modo que el proceso de escritura
entre el prototipo y el artículo final se fuese realimentando, afinando
y mejorando.
El entorno Pharo/Smalltalk propicia el \emph{bootstrapping}, pues integra dentro de sí un
lenguaje de programación mininalista, un poderoso ambiente integrado de desarrollo y una
interface gráfica.
La experiencia de usuario inicial es sólo descargar, decomprimir y usar, sin ningún tipo de
privilegio particular (a diferencia de Leo, que es difícil de instalar en plataformas no
Gnu/Linux, y puede requierir de permisos de administrador en la máquina).
En Pharo se pudo recrear mucha de la experiencia de escritura arbórea básica con Leo,
mencionada en la sección \ref{indie-web-science} y se delegó el resto de la misma, en
particular la creación de PDF, a plataformas completas instaladas localmente, específicamente
Pandoc y \LaTeX, el cual tiene una amplia tradición en la creación de PDF de alta calidad
(el Manual de Periodismo de Datos y el Manual de Grafoscopio, en el capítulo \ref{prototipos},
son muestras de cómo esta combinación entre Grafoscopio, Pandoc y \LaTeX es usada en la creación
de documentos).
También se avisoró la posibilidad de delegar en servicios ubicados en Internet dicha producción de PDF.
\section{Bifurcación y recombinación}\label{auto-bifur}
En la primera parte se mencionó como la estrategia de diseño para nuevos
artefactos, desde Jonas, tenía que ver con el estudio de los puntos de bifurcación
de artefactos previos y las posibilidades de diálogo entre tales bifurcaciones,
ahora con el beneficio de la retrospectiva histórica.
Hacia el final de la misma también se dijo que las epistemologías del diseño requieren de
nuevos artefactos que permitan explorarlas y comunicarlas.
Ellos deberían dar cuenta de sus ingredientes e historia, para mostrar que los metabolismos
cognitivos, como diría Bonsiepe, propios del diseño no son sólo anabólicos (de juntura, simplifcación y
recombinación, que son en los que Bonsiepe se centra) sino catabólicos (de liberación de energía y
componentes para futuras recombinaciones).
A continuación se mencionará como Grafoscopio da cuenta de dichos puentes entre tradiciones
y bifurcaciones y de los componentes que permiten la recombinación y el metabolismo cognitivo
a partir de los mismos.
Las subsecciones abordarán en detalle cuáles son los alcances de Grafoscopio y dónde este
se ubica en un ecosistema de aplicaciones similares, relacionadas con temas de investigación
y publicación reproducibles, así como narrativas y visualización de datos.
La idea de los metasistemas y la autorreferencialidad, se esbozaba desde el 2010 y comienzos
del 2011, en una conversación cara a cara con Wolfgang Jonas y se retomó y mostró en el examen de candidatura de 2014 (véase figura XY) %NOTA: Jonas scroll?.
Se hablaba de dos ``mantras'' de la computación en paradigmas distintos, que marcaron puntos
de bifurcación a comienzos de la misma.
Por un lado estaba la tradición y el mantra de ``todo es un archivo'' y la Smalltalk y el mantra de
``todo es un objeto''.
A su vez se tienen implementaciones de metasistemas en dichas tradiciones:
Con Leo teníamos un (meta)archivo (arbóreo) que integraba y hablaba de otros archivos
(usualmente externos a Leo) y con Pharo/Smalltalk teníamos un entorno de (meta)objetos
que que integraba y hablaba de otros objetos (usualmente internos a Pharo/Smalltalk).
Dichas tradiciones a su vez fortalecieron caminos paraleos: en de los archivos y las
aplicaciones, propio de la tradición Unix y sus derivados (incluidos Windows, Mac y Gnu/Linux)
y el de las simulaciones y las meta-herramientas, propio de Smalltalk.
Mientras el primero estaba orientado a ``usuarios finales'', que usan aplicaciones para crear
documentos, el segundo estaba orientado a programadores que usan meta-herramientas para crear
otras herramientas o aplicaciones y ``software educativo'', para jóvenes y niños que usan la
simulación para expresar y desarrollar el pensamiento.
Estos, por supuesto, son ``acentos'' de dichas tradiciones y no factores exclusivos de las mismas.
Sin embargo desde ellos se puede ver una proliferación de herramientas en la cultura de dichas
tradiciones: Los sistemas operativos tienen una miriada de aplicaciones para crear documentos,
sin mayores énfasis en la modificabilidad y programación y los sistemas Smalltalk tienen
meta-herramientas para programadores y jóvenes y niños, sin aplicaciones populares o ampliamente
conocidas fuera de tales nichos.
\begin{figure}[tbh]
\centering
\includegraphics[width=0.6\linewidth]{./Parte2/leo-smalltalk.png}
\caption[Vinculos posibles entre Leo y Smalltalk]
{Detalle sobre uno de los primeros dibujos (de 2011) acerca de cómo explorar la relación
con tecnologías digitales auto-referenciales, combinando ideas del metaeditor
Leo y de Smalltalk.
A pesar de su caracter de intuición temprana, dicha idea cristalizaría 3 años después
(y tras una primera pausa de año y medio en el doctorado) en Grafoscopio.
Para la gráfica completa ver \ref{fig:pendiente}}
\label{fig:nombre}
\end{figure}
Grafoscopio une estas dos tradiciones al ofrecer herramienta para documentar, simular y visualizar,
que son ``internas'' del entorno Smalltalk, pero que pueden producir documentos ``externos'' al mismo
y con un público objetivo que no se centra en niños, jóvenes o programadores profesionales,
sino que incluye activistas, periodistas, comunicadores, filósofos, investigadores académicos,
químicos farmacéuticos, microbiólogos, bibliotecarios, entre otros (considerados a partir de la
población que ha asistido a los talleres del \emph{Data Week}, como se detalla en el capítulo \ref{dataweek}).
Grafoscopio también explicita las propuestas de integración respecto a una escritura que fuera
arbórea/emergente e interactiva, con una experiencia similar a la que se buscó con la integración
de Leo e IPython, pero considerando tecnologías mucho más uniformes y simples, y por tanto
empoderantes, en el sentido de que permite expresar en prototipos más fluidamente las ideas.
Recrea así mucha de la experiencia de escritura arborea de Leo en Pharo/Smalltalk, que no
estaba disponible dentro de éste, con la valiosa ayuda del Glamorous Toolkit
(\cite{girba_glamorous_2014}).
%NOTA: luna iceberg.
Se ha procurado un balance, que sin reducir todo a tecnologías desarrolladas exclusivamente
en Smalltalk, tampoco sea excesivamente diverso y complicado.
Como se dice en su repositorio de código (\cite{luna_cardenas_grafoscopio_2014}):
\begin{quotation}
Grafoscopio trata de ser una herramienta simple, comprensible, amoldable, versátil y flexible,
gracias al poder el ecosistema de Pharo Smalltalk y la combinación con frameworks y herramientas maduras externas e internas. Usa:
\begin{itemize}
\item Internas:
\begin{itemize}
\item GT Tools y Spec para los playgrounds embebibles, los nodos interactivos y la Interface \item Gráfica de Usuario (GUI).
\item Roassal para visualización de datos.
\item STON para un ligero almacenamiento de datos y formato de documentos.
\item Fuel: para almacenamiento medio y serialización de objetos.
\item Monticello para el control de código fuente del software.
\end{itemize}
\item Externas:
\begin{itemize}
\item Fossil SCM para colaboración y trazabilibildad de los documentos
\item Pandoc para exportación a formatos PDF/impreso y HTML/web.
\item SQLite para almacenamiento y manipulación de datos tabulares.
\end{itemize}
\end{itemize}
\end{quotation}
\begin{figure*}[tbh]
\centering
\subfloat[]{
\includegraphics[width=0.4\linewidth]{./Parte2/doing-with-images.jpg}
\label{subfig:doing-with-images}}
\quad
\subfloat[]{
\includegraphics[width=0.5\linewidth]{./Parte2/modes-of-understanding.png}
\label{subfig:understanding-modes}}
\caption[Medios digitales multimodales]
{\ref{subfig:doing-with-images} \cite{kay_alan_1997} (\url{https://is.gd/AVTJLg})
y \ref{subfig:understanding-modes} \cite{victor_humane_2014} aluden a cómo los medios
dinámicos, potenciados por tecnologías digitales pueden favorecer la exploración,
comprensión de un mundo de maneras multimodades, donde las diferentes formas de
comprensión al alcance del ser humano entren en diálogo.
Esta búsqueda de hace 40 años, continua hoy y se proyecta varías décadas y siglos en el
futuro.
Grafoscopio aborda esta comprensión multimodal de una manera particular, al vincular código,
texto, datos y visualizaciones para explorar y expresar problemas desde comunidades de base,
pero con una preocupación por los puentes entre el futuro y el presente y el
\emph{bootstrapping} desde esas comunidades de base de los futuros deseables.}
\label{fig:multimodal-dinamico}
\end{figure*}
Grafoscopio dialoga con ideas de \cite{victor_humane_2014} y
Kay(\cite{maxwell_tracing_2006}), respecto a medio dinámicos que habiliten formas de
pensar de manera multimodal un problema, para entenderlo y expresarlo mejor.
Sin embargo, a diferencia de los proyectos de estos autores, no está preocupado con lo que
puede ocurrir 40 años en el futuro, como el proyecto de Kay en Xerox de los 70's o el Victor
de hoy, en Dynamicland\footnote{\url{https://dynamicland.org/}}, sino con los puentes entre ese
futuro y las prácticas presentes.
Esencialmente, porque, como la historia nos ha mostrado, el puente entre el presente donde se
exploran aquellas visiones utópicas y el futuro al que pretenden llegar décadas después, no es
automático y de hecho, agregaría que suele ser ocupado por la distopia, con frecuencia.
La investigación \emph{Tracing the Dynabook} (\cite{maxwell_tracing_2006}),
muestra la diferencia entre el mundo que Kay y su equipo buscaban hace décadas y el que tenemos
hoy en día, lleno de ``usuarios finales'', apps para el consumo de contenidos y no para su
creación y distante del pensamiento crítico empoderado por el computador.
Kay mismo se ha quejado innumerables veces sobre dicha distancia, (por ejemplo
en \emph{The computer revolution hasnt happened yet})
y \cite{victor_humane_2014} dice que el intenta proveer provocaciones sobre caminos posibles,
pero no certidumbres ().
Por ello, entre otras, la preocupación por el presente y los contextos locales es el foco de
Grafoscopio, en estos actos de bifurcación y recombinación en línea con la idea de construir un
mundo plural y humano, enunciado al final de la primera parte.
\begin{figure}[tbh]
\centering
\includegraphics[width=0.7\linewidth]{./Parte2/recombinacion.png}
\caption[Recombinación de tradiciones]
{Detalle del mapa mental, usado en los Data Weeks, donde se muestran distintas tradiciones que
Grafoscopio recombina y reinterpreta: la tradición Unix (de Ritchie y Thompson), la del
Dynabook (Kay), la del Software Libre (Stallman) y la de herramientas para pensar
lo impensable de (Vitor), entre otras.
El mapa se hizo en inglés para facilitar exponerlo a públicos en eventos internacionales,
y se usaba en los eventos locales aprovechando que se podía narrarlo en español.
El mapa completo puede ser visto y descargado en distintos formatos desde la página de
Grafoscopio en \url{http://mutabit.com/grafoscopio/\#aprende}.}
\label{fig:recombinacion}
\end{figure}
%\begin{figure*}[th]
% \centering
% \includegraphics[width=\linewidth]{./Parte2/grafoscopio-place.png}
% \caption[Grafoscopio: Lugar en el ecosistema]
% {Captura de la página del Manual de Usuario de Grafoscopio que describe su lugar en el ecosistema
% de software, los parecidos con otro software en el mismo dominio, las fuentes de inspiración
% y las apuestas diferenciales.}
% \label{fig:grafoscopio-place}
%\end{figure*}
Grafoscopio resuena con otras preocupaciones del presente, respecto a narrativas
computacionales, que toman cuerpo en artefactos como IPython notebook,
Jupyter\footnote{\url{http://jupyter.org/}}, Zeppeling\footnote{\url{https://zeppelin.apache.org/}},
Beaker\footnote{\url{http://beakernotebook.com/}}, The Gamma\footnote{\url{https://thegamma.net/}},
TeXmacs\footnote{\url{http://texmacs.org/}}, Leo, Org Mode\footnote{\url{http://orgmode.org/}},
Pollen\footnote{\url{http://docs.racket-lang.org/pollen/}}, así como motores y cajas de
herramientas (\emph{toolkits}) para visualización como D3.js\footnote{\url{https://d3js.org/}},
Raphael\footnote{\url{https://dmitrybaranovskiy.github.io/raphael/}},
Processing\footnote{\url{https://processing.org/}} o Flare\footnote{\url{http://flare.prefuse.org/}},
pues al igual que muchos de ellos combina y provee funcionalidades para la prosa y el código con
visualizaciones, en libretas y documentos interactivas.
Sin embargo, se distancia de estos al desarrollarse en un entorno continuo de computo, que no
separa en capas disyuntas, lenguaje de programación, entorno integrado de desarrollo (IDE, por
sus siglas en inglés), los gestores de código, la aplicación y el documento, facilitando difuminar
la distinción entre usuario y hacedor (problema central de esta investigación) y usa representaciones
simbólicas (código) y gráficas (visualizaciones) para abordar un problema.
El Manual de Usuario de Grafoscopio (\cite{luna_cardenas_grafoscopio_2017}) muestra en detalle
el lugar de este software en medio de las otros similares, las ideas de las cuales se inspira y
las apuestas de valor agregado del mismo.
Otra tradición importante que Grafoscopio recoge es la mirada tecnopolítica del Software Libre,
pues se acoge a una de las licencias que lo cobijan (la MIT) y explicita en muchos de los
talleres que se hicieron la idea de la tecnología digital como una manera de hacer viable (o no)
la idea del conocimiento como bien común.
Es precisamente en los problemas que se abordan y los prototipos que se crean donde se pueden
explicitar estos puentes entre tradiciones y bifurcaciones, tratados anteriormente.
El capítulo \ref{prototipos} detalla varios de los constructos creados con Grafoscopio que
cristalizan dichos puentes.
%PENDIENTE: Conclusiones
% infraestructuras de bolsillo como forma de decolonizar la infraestructura.
\subsection{Una aproximación artesanal y sus alcances}\label{grafoscopio-alcances}
Grafoscopio se desarrolló durante casi tres años y medio hacia el término de esta tesis y
todo parece indicar que se continuará desarrollando después, debido a los usos actuales y
potenciales del mismo, no sólo en los contextos locales, sino internacionales (en ese sentido
ya se superó la idea de una ``tesis de anaquel'', mencionada en el Prefacio).
El desarrollo de este software no es cercano a practicas ingenieriles tradicionales,
sino que se enmarca en la idea de aprendizaje como un acto de enculturación en una comunidad
de práctica (\cite{wenger_communities_1999}), en este caso la de las comunidades alrededor de
Pharo, de la que se hablará más adelante y del software como artesanía \cite{blackwell_craft_2015},
de la que nos ocuparemos acá.
Desde dicha aproximación, el software embebe y encarna conocimiento crítico de su autor y es un
``material recalcitrante'' (\cite{blackwell_craft_2015}), con el que dialogamos y que nos permite
investigar a través del la práctica reflexiva, muy en línea con las perspectivas, explicitadas en
la primera parte, de los saberes diseñísticos y sus metodologías, así como aquella del investigador
en diseño como sujeto político, los objetos activistas y la transparencia como forma de rigor
investigativo, en lugar de la supuesta neutralidad o reproductibilidad para todo contexto.
Se trata más bien de tener una reproductibilidad contextual abierta a la reinterpretación constante,
facilitada no sólo gracias al acceso al código fuente, sino a las prácticas educativas comunitarias
permanentes, donde este se apropia y se cambia.
La materialidad del software, mencionada por \cite{blackwell_craft_2015}, permitiría establecer
diálogos y prioridades, dejando que el material nos guíe, específicamente en la relación de
dichas materialidades y las comunidades alrededor de ellas.
Según tales autores (p, 2-3):
\begin{quote}
Las herramientas prácticas artesanales han `evolucionado' para adecuarse a la mano
experta a través de generaciones de uso --- de hecho, `co-evolucionaron'jporque el
entrenamiento artesanal procede junto con las prácticas reflexivas de hacer y adaptar
las herramientas propias.
Podría entoncees esperarse que la artesanía del software estaría parcialmente `encarnada'
en las herramientas de programación que codifican las prácticas expertas volucionadas, tales
como el prototipado, la modelación y el \emph{refactoring}.
[...]
La comprensión del software como materialidad inicialmente parece contraintuitiva, por el
hecho de que el software es por supuesto inmaterial.
Sin embargo, podemos usar la comprensión de la materialidad en la interacción (Gros et al 2013)
para observar que el código es usualmente un medio recalcitrante, que ofrece resistencia
a la manipulación por el programador, en la misma panera que lo hacen los materiales mediales
de la práctica artística.
\end{quote}
\begin{figure*}[tbhp]
\centering
\includegraphics[width=\linewidth]{./Parte2/software-as-craft.png}
\caption[El software como artesanía]
{El software como artesanía. Trozo del mapa mental empleado en el Data Week en el que se
habla del software como artensanía que embebe saberes de sus creadores y usuarios,
respecto a herramientas previas que han servidor como inspiración, respecto al conocimiento
como un derecho y la tecnología como una forma de encarnarlo y las búsquedas conceptuales
respecto a lso computadores como artefactos cognitivos, como medio expresivos y las metáforas
subyacentes detrás de la informática.}
\label{fig:software-artesania}
\end{figure*}
Fue así como durante el desarrollo de Grafoscopio se tuvieron momentos frenéticos con exploración
intensiva de las posibilidades y prioridades (particularmente al comienzo) y también ritmos
más sosegados, logrados gracias a la interacción con la naciente comunidad de Grafoscopio.
El prototipo, avanzó como decimos en dicha comunidad, ``sin prisa, pero sin pausa'' y no buscó
una experiencia absolutamente fluida y limpia, sino que se entregó un prototipo
funional básico que satisfaciera las condiciones mínimas enunciadas en la sección
\ref{bootstrapping-condiciones-muxednimas-para-jalonar-la-complejidad}, para que fuera la
interacción entre prototipo y comunidad la que dictara las prioridades siguientes, en
concordancia del prototipo como hipótesis y los ciclos de realimentación de la investigación
en diseño, teorizados por \cite{teemu_leinonen_software_2008}, referidos al final de la
primera parte.
Como se ha comentando previamente, ya había una experiencia preliminar del autor con algoritmos,
lenguajes de \emph{scripting}, programación y e incluso modelación computacional, empleando
la variante Squeak de Smalltalk.
Sin embargo Grafoscopio fue el primer prototipo desarrollado (por el autor) en la variante Pharo
de Smalltalk y de hecho la primera aplicación de usuario, que brindaba desafíos distintos de
las experiencias previas, debido a que sus demandas iban más allá de ejecutar un sencillo
programa guardado en un archivo de texto, desarrollar un sitio web o una interfaz gráfica
monopropósito para ejecutar un modelo computacional específico.
Las demandas nuevas requerían una aproximación que fuera ágil y debido a la inexperiencia
y desconocimiento sobre metodologías más formales de desarrollo de software, se procedió
de una manera amateur aprendiendo durante la marcha y aumentando la formalidad en la medida
que fuera necesario.
Incluso, el caracter informal y de auto-formación asociado al desarrollo, que implicó el empezar
desde el problema y no desde algún formalismo de software y requerimientos preestablecidos,
conllevó a ``huecos'' en los saberes, que fueron llenados o no, de acuerdo a su necesidad más
práctica.
En la medida en que se iba aprendiendo, algunas partes del prototipo eran rehechas, en
un proceso que en desarrollo de software se conoce como \emph{refactoring}.
Y allí Pharo mostró otra de sus ventajas, pues no cobraba caro las decisiones tempranas
propias de mi ignorancia como programador, sino que le permitía a mi yo más experto,
revaluar las decisiones que había tomado mi yo más novato y rehacerlas sin mayor dificultad.
Aún así, hay decisiones tempranas que aún se encuentran en el software y que deben ser
cambiadas desde el conocimiento actual y futuro.
La parte escritural provee una interfaz básica y no hubo esfuerzos por brindar mayor ergonomía
en funcionalidades como cambiar el tamaño de las fuentes, resaltado de errores ortográficos y
gramaticales e íconos para invocar ciertos elementos de formateo de texto, sino que se apeló
al lenguaje de etiquetamiento ligero Markdown para dichos elementos de formato y se confió en
que esa interface sencilla, unida al valor diferencial del software como otra manera de organizar
el texto y vincularlo con visualizaciones, fuera suficientemente llamativa para los miembros
de la comunidad que quisiera continuar usando el software.
Los lenguajes de domino específico (DSL, por sus siglas en inglés) para el procesamiento de
texto y la visualización de datos también fueron surgiendo de manera emergente de acuerdo a
la necesidad y se espera que continuen afinándose en eventos locales e internacionales en los
que son requeridos.
La escritura, el desarrollo y compresión explícita de los DSL es parte de las intensiones de
uso detrás de Grafoscopio y no se espera proveer metáforas visuales que los oculten o hagan
que los usuarios no se enfrenten a este aspecto del código.
Sin embargo, si se espera mejorar la Interfaz Gráfica de Usuario (GUI, por sus siglas en inglés),
de modo que el trabajo con toda la funcionalidad de Grafoscopio, incluidos los DSL sea más
fluida.
La integración el y jalonamiento desde Pharo de otras herramientas (Fossil, \LaTeX, Pandoc)
es parcial, pero cada vez mejor; no se aborda su uso como servicios en Internet; y muchos
de los elementos restantes para producir el PDF deben ser instalados localmente en la máquina
donde se trabaja el documento y para dar cuenta de su historia vía Internet la configuración
en línea se hizo manualmente, gracias a repositorios en Fossil, además se desarrollo una
funcionalidad puente entre Fossil y Grafoscopio.
En ese sentido no está dentro de los alcances del prototipo el ser complemente portable,
ni multiplataforma, y por lo pronto permite de modo autónomo sólo la escritura,
(re)organización del texto en la interface gráfica y su exportación al formato ligero Markdown,
mientras que apela al software externo Pandoc para la conversión a HTML y junto con \LaTeX
se puede realizar la exportación a PDF.
Se espera que futuras versiones del software integren los elementos faltantes y puedan
jalonarlos de maneras progresivas, de acuerdo a las necesidades de la comunidad y los recursos
para ello, siguiendo con la idea de poner a circular e iterar prototipos mínimos y funcionales
desde los cuales detonar dichas experiencias futuras y reevaluar las elecciones de diseño
del pasado.
\subsection{Software con otras interfaces escriturales}\label{software-con-otras-interfaces-escriturales}
Para elaborar un estado del arte, se consideró otro software que se aleja de las metáforas
usuales de los procesadores de palabra populares (MS Word o LibreOffice Writer).
En esencia se trata de pasar de las metáforas \emph{Lo Que Ves Es Lo Que Obtienes} o WYSIWYG
(por las siglas en inglés para \emph{What You See Is What You Get}) a metáforas de
``escritura tipo \emph{iceberg}'' donde \emph{Lo Que Ves Es Sólo La Superficie De Lo Que Tienes}.
Estas otras formas escriturales podrían dar cuenta de elementos cómo las narrativas de datos,
que agregan distintos niveles de lectura en la medida en que se refieren con gran nivel de
detalles tanto a los procedimientos (algoritmos), como los datos (entradas) y los resultados
(análisis y visualizaciones) integradas a un sólo documento para faclitar la trazabilidad,
así como sistemas que a través de otras interfaces alejadas de representar en pantalla lo
que veríamos en papel pueden dar cuenta de las complejidades de lo escritural.
Se inició por mirar otros sistemas de escritura estructurada, centrados en las palabras y
el texto y ausentes de decoraciones, como:
Scrivener\footnote{\url{http://www.literatureandlatte.com/scrivener.php}},
Ulises\footnote{\url{http://www.ulyssesapp.com/}},
Substance\footnote{\url{http://substance.io/composer/}} e
IPython Notebook\footnote{\url{http://ipython.org/notebook.html}}
Scrivener y Ulysses son software privativo, por lo tanto su código fuente no puede ser usado
libremente como base para la construcción de nuevo software.
Sin embargo, la metáfora del corcho para pegar ideas u otras diferentes formas de ver un mismo
escrito, del primero son interesantes, así como la idea de hacer que puedan aparecer metadatos
o imágenes en determinadas partes, por solicitud del usuario, del segundo.
Substance brinda una interesante forma de publicación a dos columnas, usando la primera para
presentar el texto y la segunda para el contexto (gráficas, referencias bibliográficas, etc)
y es software libre.
\begin{figure*}[tbh]%
\centering
\subfloat[Ulysses]{
\includegraphics[width=0.45\linewidth]{Parte2/ulysses-image-preview.png}
\label{subfig:ulysses}}
\quad
\subfloat[Scrivener]{
\includegraphics[width=0.45\linewidth]{Parte2/scrivener.jpg}
\label{subfig:scrivener}}
\\
\subfloat[IPython notebook, código fuente]{
\includegraphics[width=0.45\linewidth]{Parte2/ipython-markdown.png}
\label{subfig:ipython-markdown}}
\quad
\subfloat[IPython notebook, vista previa]{
\includegraphics[width=0.45\linewidth]{Parte2/ipython-vista-previa.png}
\label{subfig:ipython-preview}}
\caption[Tres interfaces alternativas para escritura]
{Tres interfaces alternativas para escritura.
\ref{subfig:ulysses} Ulysses, con su interface centrada en el texto y algunas utilidades
como previsualización de imágenes.
\ref{subfig:scrivener} Scrivener y los corchos y el árbol para organizar la escritura.
\ref{subfig:ipython-markdown} IPython notebook y su experiencia de escritura basada
en un lenguaje de etiquetamiento ligero.
\ref{subfig:ipython-preview} el resultado de pasar de dicha escritura al modo de
previsualización (el cambio entre modos ocurre simplemente al presionar la combinación
de techas \emph{Shift} + \emph{Enter}).}
\label{otras-interfaces-escriturales}%
\end{figure*}
IPython Notebook es software libre y permite la escritura de documentos interactivos y
estructurados, pero para mediados del 2014 era difícil de instalar y la creación de documentos
de cierto nivel de complejidad era dispendiosa, como mostró un documento exploratorio,
hecho para uno de los subproyectos de PIAMED (Proyecto de Información Abierta para el
Acceso a Medicamentos)\footnote{Trozos del informe para el proyecto PIAMED, escritos
también por el autor de este texto han sido integrados a esta subsección, así
como a la parte referida a visualización de infraestructuras.},
referido a la narrativa de datos para el Uso Racional de Medicamentos (\cite{gil_rojas_narrativas_2014}).
Dicho documento computacional e interactivo usaba la tecnología del IPython \emph{notebook}
integrando procedimientos, algortimos y resultados haciéndolos trazables y auditables.
El problema es que su extensión lo hacía de difícil manejo después o sus partes deben ser
disgregadas y editadas para varios públicos, perdiendo la unicidad que es parte de su encanto
(poder pasar de los resultados a los datos y procedimientos que los producen).
El documento extenso integrado se puede ver en la figura \ref{fig:narrativas-ipython-notebook}
Esta escritura en varios niveles y la tensión entre unicidad y orientación para lectores
distintos, también se presentan en los informes más cotidianos y mundanos.
Para producir los informes, usualmente se apela a un conjunto de soportes, autores, archivos
e insumos, que quedan por fuera del documento que apeló a los mismos para existir.
Dichas conexiones quedan ocultas bajo el texto, en la cabeza de sus autores, las carpetas
y referencias bibliográficas integradas por ellos.
Se puede tener un texto sucinto y de fácil lectura, pero que oculta las complejidades que
lo construyen, lo cual dificulta la participación y transparencia posterior, propia de los
procesos de Innovación Abierta y Comunitaria, (como los que alentaba PIAMED) o bien un texto
completo y complejo, que al mostrar sus diversas capas en simultáneo, se enfrenta a la misma
dificultad.
\begin{figure*}[tb]
\centering
\includegraphics[height={\textwidth}]{./Parte2/narrativa-zooms.png}
\caption[Narrativas de datos integradas usando el IPython \emph{notebook}]
{Narrativas de datos integradas usando el IPython \emph{notebook} (\cite{gil_rojas_narrativas_2014}).
En la mitad está todo el documento con la narrativa completa y a los lados dos
\emph{zooms} de unos trozos del mismo.
Los trapecios cyan indican qué parte central es ampliada en el zoom.
Como se puede ver, un documento único se hace de dificil manejo de todos
los niveles que integra la narrativa (descripciones textuales, algoritmos, datos
y visualizaciones).
La opción de separarlo en distintos subdocumentos, no es muy amigable, si en ellos
se trabajan los mismos datos y hay que cargarlos una y otra vez, o si a partir de
los mismos se crean varios productos derivados dirigidos a públicos distintos, como
suele ocurrir.
La alternativa propuesta es usar la escritura interactiva por capas o arbórea.}
\label{fig:narrativas-ipython-notebook}
\end{figure*}
Además el \emph{IPython Notebook} está hecho en varios lenguajes: Python, C, Javascript
y HTML, con lo cual la curva de aprendizaje para la intervención de la interface misma se
hace complicada.
Por tanto, no era muy adecuado como base para explorar la idea de un sistema de escritura
donde lo arboreo permita lidiar con la complejidad y el caracter emergente de la misma.
Una descripción detallada de las dificultades de lidiar con dicha complejidad incidental,
que toma la forma de diversas tecnologías, lenguajes, \emph{frameworks}, modelos conceptuales
para expresar documentos interactivos arbóreos, fue hecha a modo de entrada a blog en el texto
\emph{Grafoscopio: Iceberg metaphor and first steps} (\cite{luna_cardenas_grafoscopio:_2015}).
El IPython \emph{notebook} también evolucionó desde el 2014, dando lugar al
Jupyter\footnote{\url{https://jupyter.org/}} \emph{notebook} y este al JupyterLab,
que intenta brindar funcionalidades de Entorno Interactivo de Desarrollo\footnote{
\cite{granger_jupyterlab:_2016} (5:28) dice que la ``I'', usualmente empleada para
denotar ``Integrado'' en la sigue IDE (por el inglés para \emph{Integrated Development Environment}
se usaría para denotar ``Interactivo'' en el caso de Jupyter Lab). }
a IPython y otros lenguajes, yendo más allá de la funcionalidad de libreta interactiva.
Jupyter y Grafoscopio han evolucionado en direcciones distintas y complementarias: el primero
partiendo de libretas interactivas y yendo hacia un Entorno Interactivo de Desarrollo, el
segundo partiendo desde el Entorno Interactivo de Desarrollo provisto por Pharo y brindando
funcionalidades de libreta interactiva dentro de este y debido a esta diferencias de trayectos,
se puede decir que Jupyter y Grafoscopio sirven, de algún modo, cada uno como exploración del
futuro del otro.
Esta es una muestra interesante de cómo Grafoscopio madura a buen ritmo, sin ser subsumido
o desactualizado por proyectos con mucho más recursos, desarrolladores, apoyo y visibilidad
y que sigue aportando valor diferencial y lugares de interlocución desde los márgenes.
La figura \ref{fig:grafoscopio-jupyter} muestra cómo tanto Grafoscopio como Jupyter Lab
permiten la integración de distintos elementos de un Entorno Interactivo de Desarrollo,
yendo más allá de la sóla libreta interactiva.
\begin{figure*}[th]%
\centering
\subfloat[Trozo mapa del Data Week sobre la relación entre Jupyter y Grafoscopio]{
\includegraphics[width=0.7\linewidth]{Parte2/jupyter-grafoscopio.png}
\label{subfig:jupyter-grafoscopio}}
\\
\subfloat[Grafoscopio: Panamá Papers]{
\includegraphics[width=0.45\linewidth]{Parte2/data-environment-full.png}
\label{subfig:data-environment}}
\subfloat[JupyterLab]{
\includegraphics[width=0.45\linewidth]{Parte2/jupyterlab.png}
\label{subfig:jupyterlab}}
\quad
\caption[Sobre las relaciones entre Grafoscopio y Jupyter]
{Sobre las relaciones entre Grafoscopio y Jupyter.
\ref{subfig:jupyter-grafoscopio} Detalle del mapa en la explicación sobre las relaciones
entre Jupyter y Grafoscopio, que ofrecemos durante el Data Week.
\ref{subfig:data-environment} Captura del Entorno Interactivo de Desarrollo de Grafoscopio,
tomada del los Panama Papers en \url{http://is.gd/panama_papers_e}.
\ref{subfig:ipython-markdown} Captura del Entorno Interactivo de Desarrollo de JupyterLab,
tomada de \emph{JupyterLab: Ready for Users} en \url{https://is.gd/JRmGNY}.}
\label{fig:grafoscopio-jupyter}%
\end{figure*}
Para los prototipos de Grafoscopio se preservó la idea de una experiencia de escritura arbórea
centrada en estructura y palabras con una interface sin adornos de Leo, así como la de un
sistema de escritura interactiva, que soportara la recolección y visualización de datos en
concordancia con lo que permite el IPython \emph{notebook}.
Se consideraron otros lenguajes con la característica de auto-referencialidad e introspección,
es decir, el hecho de que el código fuente pueda usarse como datos, de modo que, a su vez, se
pueda usar una parte del código fuente para reprogramar el sistema, en particular su interfaz
y sistema de escritura.
Dentro de las opciones estaba el editor de código LightTable\footnote{\url{http://lighttable.com/}},
que está hecho en ClojureScript\footnote{\url{https://clojurescript.org/}} (un descendiente
con ideas del lenguaje funcional Lisp\footnote{\url{https://es.wikipedia.org/wiki/Lisp}},
desarrollado sobre JavaScript\footnote{\url{https://es.wikipedia.org/wiki/JavaScript}}).
Pero la indagación preliminar en la comunidad (\cite{luna_cardenas_outliner_2014}) mostró
que el desarrollo y la modificación de la interface gráfica podía ser difícil para un novato,
en comparación con la manera como se podía hacer en Pharo/Smalltalk, que disponía de \emph{toolkits}
para el desarrollo de navegadores de información y la presentación y navegación específica para
estructuras arbóreas de información (\cite{girba_glamour_2013}), el soporte para
programación y exploración de datos interactiva, como se podía ver en los videos
\emph{Pharo: Playing with Live Objects} (\cite{girba_pharo:_2014}) y particularmente en
\emph{Software as a Graph} (\cite{bergel_software_2014}),
que cristalizaban la idea de diálogo con el software como material, antes explicitada y la
potenciaban a través de la experiencia de \emph{Live Coding} o Programación en
Vivo\footnote{El \emph{Live Coding} ha tenido una amplia tradición en
las artes musicales performáticas, si bien su uso se extiende más allá de ellas,
en lo que otros han denominado programación interactiva.
Lo esencial de dicha aproximación es la idea de cambiar un programa que se está ejecutando
mientras se cambia, en oposición a modos más indirectos de abordar dicho cambio.
Esta técnica está ampliamente relacionada con la experiencia desarrollada en HackBo,
pues íbamos cambiando Grafoscopio en la medida en que lo usábamos, partícularmente
durante los Data Weeks y Data Rodas.},
en la que dicho diálogo era mucho más directo e interactivo, contando con materialidades mas
fluidas y adaptables véase figura \ref{fig:software-as-graph}.
Además Pharo provee un entorno homogéneo donde el mismo paradigma y herramientas son usados
consistentemente a lo largo y ancho del entorno, lo cual permitía un aprendizaje y desarrollo
rápido en el tiempo provisto para el desarrollo del prototipo.
Lo anterior reforzó la elección de Pharo/Smalltalk como entorno para el prototipado de
Grafoscopio.
La siguiente sección habla de esos detalles que permitieron su existencia y evolución,
desde la perspectiva de la apropiación de los saberes comunitarios sobre este entorno
de prototipado.
\begin{figure*}[th]%
\centering
\subfloat[]{
\includegraphics[width=0.45\linewidth]{Parte2/software-as-graph-1.jpg}
\label{subfig:software-graph-1}}
\quad
\subfloat[]{
\includegraphics[width=0.45\linewidth]{Parte2/software-as-graph-2.jpg}
\label{subfig:software-graph-2}}
\caption[El software como grafo]
{El software como grafo.
Capturas de pantalla del vídeo \emph{Software as a Graph} (\cite{bergel_software_2014})
con tan sólo algunos segundos de diferencia, que representan dos formas distintas de ver
el mismo sistema de información.
En cada ventana, el código mostrado en el panel a la izquierda produce la visualización
de datos en el panel 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 esta tesis es visto como un acto de enculturación
desde la perspectiva de \cite{wenger_communities_1999}.
Se trata de ir adquiriendo los repertorios simbólicos y materiales compartidos por una comunidad
de práctica, en este caso la comunidades de Pharo/Smalltalk.
Prototipar, entonces, es explorar y apropiar ese repertorio en la medida en que se interactua
con la comunidad.
En esta sección se dará cuenta del proceso de construcción del mismo y los hitos
y aprendizajes más importantes durante su desarrollo, como manera de contar aquello que
el código fuente no dice por sí mismo\footnote{
Si bien no se establecerán correlatos directos con los repositorios de código fuente
del escrito o del prototipo, si creo que es posible rastrear los trozos de esta narrativa
en tales repositorios.}
y dar cuenta, con relativo detalle, de cómo se fue adquiriendo el repositorio simbólico y material
de la comunidad de Pharo, empezando precisamente desde las materialidades.
%PENDIENTE: Mover a la parte de análisis de repositorios
%Grafoscopio fue el nombre público que se usó a lo largo del
%proyecto\footnote{Ubakye fue el nombre código que se escogió para el
% software de escritura arborea, durante casi todo su primer desarrollo.
% (\emph{uba}, significa semilla y \emph{kye} árbol , en lengua chibcha,
% una población aborigen ubicada en Colombia).}.
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,
presentadas en este libro.
[...]
La visualización ágil esta hecha para científicos de datos, periodistas,
científicos cmoputacionales e ingenieros de software. Tan pronto usted
necesita procesar datos, numéricos o no, la visualización ágil lo guiará
paso a paso para fertilizar sus datos
\end{quote}
\end{itemize}
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*}[tbh]%
\centering
\includegraphics[width=0.45\linewidth]{Parte2/interface-nodos-recursivos.jpg}
\quad
\includegraphics[width=0.45\linewidth]{Parte2/nodos-ubicaciones-especificas.jpg}
\caption[Primeros resultados de la interface]
{Primeros resultados de la interface. Izquierda, nodos que se despliegan recursivamente una
y otra vez debido a una invocación recursiva accidental.
Derecha, funcionalidad para agregar nodos en lugares arbitrarios y primeras mezclas de nodos
de texto y código.
Ambas imágenes fueron compartidas por \emph{twitter} y las url de tales publicaciones hacen parte de los nodos invisibles en el árbol original de este escrito.}%
\label{ui-primeros-resultados}%
\end{figure*}
Respecto a Moose ha habido un viraje de ser una herramienta para análisis de software a una
herramienta para análisis de datos y ahora el énfasis ha cambiado también hacia la construcción
rápida de herramientas a la medida para analizar y visualizar distintos datos.
Grafoscopio es un ejemplo de ello: una herramienta construida a la medida a partir de Moose, en
primera instancia, y luego con el GT toolkit provisto por el mismo, integrado a Pharo, en un
tiempo corto incluyendo en aprendizaje del lenguaje y otras herramientas de Pharo.
Glamorous está orientada a la construcción de sistemas para navegar
información pre-existente, pero no tanto para su modificación directa.
En diálogos con su autor, éste dijo que ciertos usos pensados para este proyecto
excedían el diseño original y que si bien serían características deseables, aún no
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, pues no se cuenta con un continuo entre
la interfaz gráfica, el lenguaje de programación, el sistema de gestión de código fuente.
En ese sentido, las demoras que pueden haber al elegir aprender una tecnología
no tan popular, como Pharo, son compensadas por la integración del entorno
y la uniformidad del lenguaje y el paradigma, ya que prototipar 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*}[th]%
\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 propio y los documentos en él se guardaban dentro de la imagen).
La imagen también habilita el tener entornos portables y perdurables de computo y estar en
condiciones de leer y retomar lo que se ha almacenado en ellas en distintas máquinas incluso
décadas después, lo cual ofrece ventajas diferenciales prácticas e importantes en los contextos
de investigación reproducible y perdurable desde los cuales se enmarca
(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, (\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 documento arbóreo 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, que representan las libretas interactivas
de Grafoscopio, fueron mapeados en archivos de texto plano, para 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 inquietudes principales 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 de STON, permitió un formato altamente eficiente
y amigable para la producción de documentos estructurados en este esquema arbóreo\footnote{
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, y 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
Más detalles en el capítulo \ref{prototipos}.}.
Las preguntas sobre este formato y sus optimizaciones fueron surgiendo de a pocos, primero garantizando
la posibilidad de guardado y recarga de documentos y luego, su uso eficiente, varios meses despues,
logrando comprensiones de casi 150 veces el tamaño de los primeros archivos.
%PENDIENTE: Referencias a los manuales dentro de este documento.
\begin{figure*}[tbh]%
\centering
\subfloat[Explicación de la simulación]{
\includegraphics[width=0.45\linewidth]{Parte2/multiagentes-2.jpg}
\label{subfig:multiagentes-2}}
\quad
\subfloat[Ejecución de la simulació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, lo cual es importante en investigación reproducible y perdurable.
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{https://is.gd/maestria_luna_2007}.
Es de suponer que, esas otras formas de perdurabilidad y reproducibilidad estarán
disponibles para esta investigación que se adelanta en este doctorado y sus artefactos
digitales asociados, décadas después.}
\label{fig:persistencia-imagen}%
\end{figure*}
Gracias a STON, la persistencia fue muy fluida y sólo tomo cerca de una decena 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*}[th]%
\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 y otras abstracciones provistas por Pharo y su ecosistema.}%
\label{persistencia}%
\end{figure*}
La última característica a implementar, antes de empezar la escritura de documentos, 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 la mejor y más elegante, a juicio del
autor, es la definición recursiva del recorrido en preorden, en la recorrer un árbol en
preorden consiste en visitar un nodo raíz y luego visitar, en preorden, los subárboles restantes,
primero a izquierda y luego a derecha, hasta que se llegue a una hoja, es decir a un nodo que
es el final de una rama, pues no tiene más nodos hijos.
\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.
Este árbol, recorrido en preorden produce $[F,B,A,D,C,E,G,I,H]$, que es
la forma lineal de esta estructura jerárquica y que, para el caso de
Grafoscopio, representa las diferentes secciones, subsecciones y demás
partes de un documento.
(Imagen tomada de la Wikipedia: \url{http://ur1.ca/igfow})}
\label{fig:arbol-preorden}
}
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 de Pharo, por el contrario, sólo permite el hecho de que sean
los mensajes entre objetos los que implementen la recursión, además impone y el hecho de que
las variables pertenezcan a los objetos del dominio o problema que se está modelando y que sus
métodos y no sean externas a los mismos.
Pensar desde este enfoque purista implicó revisar la literatura (\cite{beck_object-oriented_1996})
y volver a los fundamentos, reimplementando parte de los ejercicios clásicos como las Torres de Hanoi
(\cite{kaehler_taste_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
sencilla y se inicio la escritura como tal del artículo, que sería el borrador para este
capítulo y habilitó la de otros documentos, como los manuales y tutoriales interactivos,
desarrollados a lo largo de la investigación (véase figuras \ref{fig:versiones-grafoscopio},
\ref{fig:joss-grafoscopio} y capítulos \ref{prototipos} y \ref{materialidades}).
La escritura de tales documentos y visualizaciones permitió afinar la funcionalidad de
Grafoscopio, 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.
\afterpage{
\begin{figure*}[tbh]
\centering
\subfloat[]{
\includegraphics[width=0.6\linewidth]{Parte2/interface-grafoscopio.png}
\label{subfig:grafoscopio-articulo-fuente}}
\\
\subfloat[]{
\includegraphics[width=0.6\linewidth]{Parte2/articulo-pdf.png}
\label{subfig:grafoscopio-articulo-pdf}}
\\
\subfloat[]{
\includegraphics[width=0.8\linewidth]{./Parte2/side-by-side.png}
\label{subfig:grafoscopio-manual}}
\caption[Realimentacion artefacto escritura]
{ Gracias a los múltiples prototipos hechos desde momentos tempranos, el artefacto
fue cambiando en la media en que se usaba, tanto para escribir sobre el artefacto
mismo, como sobre otros temas.
La figura \ref{subfig:grafoscopio-articulo-fuente}, muestra una de las primeras
interfaces funcionales de Grafoscopio de mediados de 2014, donde se escribió
buena parte del borrador de este capítulo.
La figura \ref{subfig:grafoscopio-articulo-pdf} muestra ese texto exportado como artículo en PDF.
La figura \ref{subfig:grafoscopio-manual}, muestra, a la izquiera, una de las interfaces más
maduras y recientes, que se ha mantenido estables desde el 2017, y a derecha el Manual de
Usuario de Grafoscopio, que fue escrito dentro del mismo Grafoscopio, haciendo uso de las
funcionalidades mostradas en tal interfaz.}
\label{fig:versiones-grafoscopio}
\end{figure*}
\clearpage
}
La integración experimental 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
(\cite{zotplus_better_nodate}).
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.), (\cite{amanda_morton_intro_nodate}), (``Zotero Web API Documentation V. 3''
n.d.), (``Zotero with LaTeX and BibTeX - Zotero at MIT - Research
Guides at MIT Libraries'' n.d.)), fue claro que era más fácil lograr
la funcionalidad que se quería directamente a partir de
Pharo/Smalltalk mediante el uso de Citezen (\cite{pollet_citezen_2009}),
(\cite{pollet_citezen_nodate}) (\cite{barreau_citezen_2010}).}
Este fue un prototipo que no avanzó mucho después de las exploraciones preliminares, pero
sirvió para probar la integración con herramientas externas y flujos de escritura demandantes,
como aquellos que requieren permanente y rigurosas prácticas de citación y si bien el texto
final de esta tesis fue escrito en \LaTeX, usando el excelente y amigable editor
TeXstudio\footnote{\url{https://www.texstudio.org/}}, los prototipos tempranos de dicho flujo,
que integra Grafoscopio y un soporte robusto para referencias bibliográficas permitieron ver
los alcances y posibilidades al respecto para este software e incluso se preservaron
partes del mismo para el trabajo con TeXstudio, como la integración con Zotero vía BibTeX.
A su vez, probar TeXstudio y usarlo extensivamente permitirá realimentar Grafoscopio con
ideas de uso e interfaz a futuro.
\begin{figure*}[tb]%
\centering
\subfloat[Zotero integrado en Firefox]{
\includegraphics[width=0.8\linewidth]{Parte2/zotero-firefox.png}
\label{subfig:zotero-firefox}}
\\
\subfloat[Depurando bibliografías de Zotero en Pharo]{
\includegraphics[width=0.8\linewidth]{Parte2/zotero-pharo-debug.jpg}
\label{subfig:zotero-pharo-debug}}
\\
\subfloat[La colección de Zotero creada para el doctorado y la maestría con casi 3500 items.]{
\includegraphics[width=0.6\linewidth]{Parte2/zotero-phd-master.png}
\label{subfig:zotero-phd-master}}
\caption[Integración preliminar con Zotero]{
Integración preliminar entre Grafoscopio y el gestor bibliográfico Zotero.
\ref{subfig:zotero-firefox} Zotero utilizado como plugin del navegador Firefox
al comienzo de la escritura de este capítulo.
\ref{subfig:zotero-pharo-debug} Inicio de la depuración en Pharo de la bibliografía
para soporte de llaves bibliográficas personalizadas.
\ref{subfig:zotero-phd-master} Colección/grupo de Zotero creada para el doctorado y la
maestría, al final del artículo con cerca de 240 items y del doctorado con 3495 items.
Ver \url{https://is.gd/zoterophd}.}%
\label{integracion-zotero}%
\end{figure*}
La colección de literatura recopilada para este escrito alcanzó a tener
cerca de 240 item, si bien se citó sólo una fracción de los mismos.
La colección en este caso es diversa y cubre temas de ciencia abierta y
reproducible, programación en Smalltalk, visualización de datos y luego se
extendió a otros temas y se abrió tempranamente para la participación de otros
estudiantes de postgrado en Diseño de la Universidad de Caldas, tanto de maestría
como de doctorado, pues en algunas de las reuniones de línea de investigación en 2014,
se hablaba de la importancia de compartir literatura.
Sin embargo el uso de Zotero no fue socializado amplia o explícitamente en otras prácticas
del autor o al interior de los postgrados y, a pesar de tener un grupo en Zotero con decenas
de inscritos, la mayoría de títulos colocados en ella, completando casi 3500 items, fueron
puestos por una sola persona.
Esto muestra otro aspecto invisivilizado de la escritura tradicional y es que
en la indagación preliminar pueden haber vistazos panorámicos a varios
títulos relacionados con una temática y base para otra investigaciones,
motivo por el cual los gestores públicos de colecciones bibliográficas
como Mendeley y Zotero se están haciendo cada vez más populares, pues
además de facilitar el trabajo grupal, permiten encontrar información
agrupada y comentada durante el desarrollo de una investigación, ya sea
que esta alcance o no a llegar a la citación final.
El capítulo \ref{dataviz-infra} explicita varios de esos aspectos invisibles
de la infraestructura.
Para afinar la manera en que las figuras se referencian y se disponen, se pasó del código
Markdown soportado por Pandoc, a imágenes definidas en el más rico y complicado lenguaje
de etiquetamiento \LaTeX \footnote{Se espera que exista a futuro también un tipo de nodo
especial \texttt{\%figura} que contenga los metadatos de la misma en STON y se pueda
exportar a distintos formatos (HTML y \LaTeX).}.
En paralelo se montó, desde mediados de 2014, un primer repositorio de código
fuente\footnote{\url{http://mutabit.com/repos.fossil/grafoscopio/}} que contiene las versiones
históricas de la documentación sobre Grafoscopio como manuales, tutoriales, artículos etc., en
distintos formatos: STON con metadatos, etiquetas ligeras Markdown/Pandoc o PDF.
También se incluye en dicho repositorio otro material integrado al mismo, como gráficas y
figuras y archivos de citación bibliográfica, que permiten rastrear la historia de las
tales recursos y cómo se vinculan entre sí.
De este modo, los textos allí hospedados son consistentes con los principios de trazabilidad
y reproducibilidad de la ICACG, acá mencionados, permiten la participación desde dinámicas
comunitarias y facilitan un puente entre estas y otras prácticas académicas de frontera respecto
a artículos de software que se pudieran someter a revisión de pares y publicación.
Por ejemplo, el sitio web de
Grafoscopio\cite{luna_cardenas_grafoscopio_2014-1}\footnote{\url{http://mutabit.com/grafoscopio/}}
(véase figura \ref{fig:grafoscopio-web}) surgió como una página web de bienvenida, que brindara
una primera información importante y panorámica sobre el mismo.
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,
desde una memoria USB, una rasberry-Pi, un servidor modesto y cualquier otra infraestructura intermedia o más potente.
\end{quote}
allí además se encuentran los enlaces a manuales, documentación, muestras de lo que es posible
y canales de comunicación, soporte y vinculación comunitarios.
\begin{figure*}[!h]
\includegraphics[width=0.7\linewidth]{./Parte2/grafoscopio-web.png}%
\caption[Parte de la página Web Grafoscopio]
{Parte de la página Web Grafoscopio en \url{http://mutabit.com/grafoscopio/}.
Dicha página tiene también una versión en inglés en \url{https://is.gd/grafoscopio_e}.
Sin embargo, las versiones más actualizadas se hacen primero en español,
suguiendo una apuesta por priorizar lo local.
Tomado de \cite{luna_cardenas_grafoscopio_2014-1}.}%
\label{fig:grafoscopio-web}%
\end{figure*}
%PENDIENTE > Conclusiones: Priorizar lo local
Por otro lado la publicación del artículo indexado titulado
\emph{Grafoscopio: A moldable tool for literate computing and reproducible research},
publicado en el \emph{Journal of Open Source Software} (JOSS), fue escrito pensando en dinámicas
académicas innovadoras que vayan más allá del artículo indexado ``clásico'' y empiecen a mostrar
otros objetos no hegenónicos de conocimiento, para los cuales la descripción en palabras, no
sólo es insuficiente, sino incompleta e inadecuada comparada con otras formas de publicación
disponibles, como las del software mismo.
Como se dijo al comienzo del capítulo, es una muestra de que las prácticas ad-hoc referidas
al objeto de investigación y la investigación reproducible, en particular de indexación e
identidad, pueden cristalizar, a través de Grafoscopio, en objetos más formales que hacen
parte de los ciclos de publicación internacionales y las prácticas de frontera emergentes
en dichos ámbitos.
\begin{figure}[tbh]
\centering
\includegraphics[width=0.65\linewidth]{./Parte2/joss-grafoscopio.png}
\caption[Artículo en el JOSS sobre Grafoscopio]
{Grafoscopio tiene prácticas \emph{ad-hoc} para abordar los principios de identidad, agregación
y anotación del Objeto de Investigación.
Sin embargo, también soporta la creación de objetos de investigación más tradicionales,
identificados con DOI, como el artículo indexado de acceso y código abierto donde se
presenta Grafoscopio, realizado para el \emph{Journal of Open Source Software} y que se
puede leer en: \url{http://is.gd/joss_g}.}
\label{fig:joss-grafoscopio}
\end{figure}
El Manual de Usuario de Grafoscopio (\cite{luna_cardenas_grafoscopio_2017}), desarrollado,
frenéticamente en abril de 2017, surgió a partir de ese primer artículo para el JOSS y
sirvió así como un puente entre documentación académica y la comunitaria\footnote{
Otro tanto se puede decir del artículo
\emph{Dataviz: A package of domain specific visualizations and languages for the
Pharo live coding environment}, que se basa en las mismas prácticas y se
encuentra sometido a aprobación para el momento de escritura de esta tesis.}.
En el mismo se documentan, en inglés, para acceder a un público internacional,
(véase figura \ref{fig:grafoscopio-manual}) las características más importantes del software,
su lugar en el ecosistema de Pharo y de otras herramientas que se mueven en contextos similares,
sus formas de instalación y uso, las maneras de interactuar con la comunidad, e incluso los errores
aún presentes en el mismo (llamados \emph{bugs} en la jerga informática).
Tanto el Manual de Usuario, como los artículos y otros documentos han sido escritos usando Grafoscopio,
como muestra de las capacidades auto-referenciales antes enunciadas: se crea un software para escribir,
se escribe en el mismo y se adapta el software a procesos de escritura futura, intentando un ciclo
virtuoso, anunciado en la figura \ref{fig:realimentacion-artefacto-escritura}: al escribir el software
para escritura, se piensa en cómo describir en código informático procesos escriturales, y al usar la
escritura para reflexionar sobre el software u otros temas, haciendo manuales y artículos, se repiensan
las maneras en que el software da cuenta de dichos procesos y cómo puede describirlos de maneras más
versátiles y potentes.
La sección ``Diálogo de Materialidades'' da cuenta de maneras más detalladas de este fenómeno, que es
una de las bases del proceso de \emph{boostrapping} que permite hacer puentes, de doble vía,
entre la escritura de prosa y la de código.
%PENDIENTE: Diálogo de materialidades.
\begin{figure*}[tbh]
\includegraphics[width=\linewidth]{./Parte2/grafoscopio-user-manual.png}%
\caption[Parte del manual de Grafoscopio]
{Parte del Manual de Usuario Grafoscopio, hecho dentro de Grafoscopio mismo.
Disponible en \url{https://is.gd/grafoscopio_m1}.
Tomado de \cite{luna_cardenas_grafoscopio_2017}.}%
\label{fig:grafoscopio-manual}%
\end{figure*}
La escogencia de idiomas para el material presente el en repositorio, pasaba del
español al inglés dependiendo de los públicos y participantes objetivo para dicho
material, elegiendo español para públicos y eventos locales e inglés para los internacionales.
Sin embargo, se dio prioridad a lo local en general, produciendo y actualizando el
material en español y luego haciendo traducciones al inglés (salvo en aquellos que
fueron escritos originalmente en inglés, pues sus públicos eran internacionales).
Sitio web, manual de usuario, y artículos académicos, hacen parte del mismo repositorio
de código fuente, lo cual permite a la comunidad, ver las distintas caras y artefactos
relacionados con Grafoscopio y su carácter polisémico.
Incluso a futuro, gracias al soporte que está brindando la comunidad de Pharo para integrar
el código fuente del software en repositorios convencionales en lugar de especializados,
sería posible integrar este repositorio de documentación con el de
software\footnote{\url{http://smalltalkhub.com/\#!/\~Offray/Grafoscopio}}, brindando
una mirada aún más integrada, comprensiva y diversa de los distintos elementos que
conforman este esfuerzo, incluidos otros repositorios conexos, como el del paquete
de visualización de Datos, Dataviz, el Manual de Periodismo de Datos, el Data Week
o el de esta misma tesis.
Se hablará con mayor de ese y otros repositorios en el capítulo \ref{dataviz-infra}.
%PENDIENTE: Playgrounds interactivos?
A partir de esta funcionalidad básica (desarrollada a mediados de 2014), se empezaron a
dictar talleres y a propiciar espacios y momentos de encuentro, tanto en eventos cara a cara,
como en sistemas virtuales que los extendían y complementaban (desde mediados de 2015).
Esto permitió que los saberes comunitarios apropiados dentro de la comunidad de Pharo,
y sus materialidades, descritas en relativo detalle hasta acá, pudieran colocarse en
diálogo con las comunidades locales del hackerspace y ayudar a consolidarlas.
Dichas actividades comunitarias, realizadas a partir de un prototipo mínimo funcional,
permitieron afinar el prototipo y mejorarlo a lo largo de este tiempo, brindaron un
sentido de ritmo e importancia sobre lo que era fácil o díficil, adecuado, aplazable y
venidero en términos de las modificaciones del prototipo y conectaron acciones y comunidades
locales con globales, gracias a la participación en eventos y comunidades nacionales e
internacionales.
Hemos visto como una pregunta llevó a un acto de apropiación cultural dentro de una comunidad
de práctica (la de Pharo y Smalltalk), que permitió explorar y expresar búsquedas sobre lo
escritural, sobre las relaciones entre artefactos digitales y conocimiento, sobre los datos
y la forma de contar historias, sobre las infraestructuras que permiten participar o no en
dichas posibilidades.
Estas exploraciones ocurrieron primero a nivel personal, apropiando las materialidades y
rituales propios de dichas comunidades, y luego se pensaron en maneras de tejer puentes, de
doble vía entre preocupaciones locales que podrían ser expresadas por artefactos como Grasfoscopio,
y formas comunitarias de hacer y aprender.
Esas dinámicas humanas alrededor de los artefactos, serán el motivo del siguiente
capítulo.