Chapter 1
Se diseñó una página web con el propósito de integrarla al repositorio alojado en Chiselapp, buscando ofrecer una interfaz clara, funcional y visualmente atractiva. Esta página cumple el objetivo de presentar de manera ordenada y accesible la información relevante del proyecto, permitiendo a los usuarios navegar y comprender su contenido con facilidad. El diseño fue elaborado considerando principios de usabilidad y coherencia visual, alineándose con los requerimientos del repositorio y las buenas prácticas de desarrollo web.
Microdocumentación y publicación (parte 2)
- Primera clase Presentación de la materia
- Segunda clase Diseño de la caja de herramientas Powershell Freeplane Flameshot
- Tercera clase Markdown y tutorial de Markdown
- Cuarta clase Estrategias metacognitivas
- Quinta clase Internet Archive, presentación del mapa mental
- Sexta clase Estrategias metacognitivas Exponer los mapas
- Septima clase Dimensiones icónicas, enactivas y simbólicas de la computación
- Octava clase Micrositios de documentación y publicación Litle XL
- Novena clase Uso de Litle XL
- Decima clase Poblar la tabla de contenido de mdBook
- Onceava clase Repositorios de Fossil y Chiselapp
- Doceava clase Sincronización de repositorios
- Clase 15 Entornos de publicación Parte 1
- Clase 16 Entornos de publicación Parte 2
- Clase 17 Lectura hipertextual
- clase 18 Live coding
- Clase 19
- Clase 20
- Clase 21
- Clase 22
- clase 23
- Clase 24
- Clase 25
Ejercicio de Markdown
Tutorial de Markdown (Thomas Martínez Sánchez)
Primera parte
Cursivas
Para poner cursivas se señala con el símbolo _ Al inicio y al final de los términos
¡Escribir en Markdown no es difícil!
No es dificil
Negrilla
Se utilizan los símbolos ** al inicio y al final de los términos que queramos resaltar en negrilla.
convierta la palabra "Completaré" en negrita.
¡Completaré estas lecciones!
Cursivas y negrillas
Se pueden usar ambos comandos dentro de la siguiente oración:
"Por supuesto", susurró ella. Entonces, gritó: "Todo lo que necesito es un poco de moxie!"
En el recuadro inferior, haga que las palabras "Por supuesto" estén en cursiva y las palabras "un poco de moxie" en negrita
Por supuesto Un poco de moxie
combinados
También se pueden usar los comandos antes mencionados al mismo tiempo en un mismo término u oración (El orden en el que se pongan ambos comandos no importa)
Si está pensando, Esto es increible, probablemente está en lo correcto.
Parte 2
Encabezados
Los encabezados en Markdown cuentan con uno o varios (#) antes del término o la frase
Por ejemplo:
No puede hacer que el encabezado este en negrita, pero sí se puede poner en cursiva ciertas palabras. En el recuadro inferior, convierta la primera línea en un encabezado de nivel cuatro, y ponga en cursiva el nombre del libro:
Cien años...
Parte 3
Enlaces
tiene 2 tipos de anexo a los enlaces
Enlaces de tipo 1
Enlace en línea
Se encierra entre corchetes ([]) en los que se anota el texto y junto a este se ponen los paréntesis (()) donde se pone el enlace
énfasis en los enlaces
Se puede subrrayar con negrilla un punto determinado en el texto que contiene el enlace. Por ejemplo:
Enlaces dentro de encabezados
Dentro de los mismos encabezados también se pueden colocar enlaces. Por ejemplo:
Podemos poner en un encabezado de tipo 3 el siguiente enlace
Enlaces de tipo 2
Se le conoce como Enlace de referencia es mas común utilizar los corchetes por ejemplo:
Quiero visitar Scoop ahora mismo. Porque este espacio es muy interesante para utilizar contenido.
Parte 4
Imágenes
Primera forma
Al igual que los enlaces las imágenes tienen dos estilos de implementación en código.
El primero se le conoce como enlace en línea a una imagen. Se refiere a que por medio de un enlace similar a los anteriores ejemplos se puede anexar una imagen. Ejemplo:
Si quiero ver una imagen de
Ahora, en dado caso se puede usar la metodología de Enlace de referencia para poder anexar mas imágenes. Por ejemplo:
puedo dar click aquí O si lo prefiero, también puedo dar click en esta imagen.
Parte 5
Citas
Para realizar una cita es importante colocar el símbolo > "Mayor que" antes de la frase que se va a citar.
Por ejemplo:
si se ha de herir a un hombre se debe ser tan severo que no se pueda temer su venganza
También es posible realizar citas a varios párrafos.
Por ejemplo:
Allá en otros tiempos (y bien buenos tiempos que eran), había una vez una vaquita (¡mu!) que iba por un caminito. Y esta vaquita que iba por un caminito se encontró un niñín muy guapín, al cual le llamaban el nene de la casa...
Este era el cuento que le contaba su padre. Su padre le miraba a través de un cristal: tenía la cara peluda.
El era el nene de la casa. La vaquita venía por el caminito donde vivía Betty Byrne: Betty Byrne vendía trenzas de azúcar al limón.
Citas con cursivas
En medio de la cita se puede colocar la letra cursiva, esto para resaltar algunos aspectos clave dentro de la misma.
ejemplo:
Se apartó bruscamente de ella, temeroso de que de la familiaridad pasase a las burlas y deseando desaparecer antes de verle ofrecer su mercancía a otra persona, a un turista inglés o a un estudiante de Trinity. La calle por donde caminaba, Grafton Street, prolongaba aquella sensación de desalentada pobreza. Al extremo de la calle había una placa dedicada a la memoria de Wolfe Tone. Le vino a la memoria el haber asistido con su padre a la colocación de ella. Y evocaba con amargura el oropel chillón de la ceremonia. Había cuatro delegados franceses subidos en una camioneta y uno de ellos, un joven rollizo y sonriente, sostenía un palo, al extremo del cual había un cartel con este letrero: VIVE L'IRLANDE!
Parte 6
Listas
Para la creación de listas en Markdown es importante tener presente los elementos a enmarcar. Primero se debe colocar el símbolo de asterisco antes de cada término.
Por ejemplo:
- Huevos
- Harina
- Queso
- Tomates
También tenemos la opción de enmarcar los términos con números, lo cual le puede brindar un orden a las listas. Para lograr esto simplemente debemos poner el número en vez del asterisco.
Ejemplo:
- cortar el queso
- pelar los tomates
- rebozar los tomates en harina
Resaltar listas
En Markdown también se puede resaltar listas, ya sea con negrilla o Cursiva o también agragando un enlace.
Ejemplo:
- Azalea (Ericaceae Rhododendron)
- Crisantemo (Anthemideae Chrysanthemum)
- Dalia (Coreopsideae Dahlia)
listar sobre listas
Dentro de las propias listas también podemos subcategorizar contenidos que hay dentro de cada término enlistado. Con esto cabe resaltar que esta posibilidad facilita a gran escala la caracterización en algún tema en específico.
Por ejemplo:
- Silvestre Tornasol
- Profesor
- No tiene pelo
- Suele vestir de verde
- Castafiore
- Cantante de ópera
- Tiene el pelo blanco
- Puede que no este muy bien de la cabeza
Mapa mental de AlexNet
Estrategias metacognitivas
¿cómo sabemos qué sabemos/entendemos de ese tema?
Puedo darme cuenta que comprendo un tema y en específico uno de los componentes de Markdown cuando puedo dar una explicación de lo que es, sobre lo aprendido puedo argumentar y relacionar los distintos comandos que se puede aplicar de esto.
El ejemplo mas claro puede llegar a ser el siguiente:
- El manejo de carácteres como Enmarcar asteriscos
- La capacidad de poner enlaces que nos redirijan a cualquier sitio web, y en este caso de redirigirnos a una imagen
Se puede mencionar que cuando la información que uno aprende la apropia se va convirtiendo en conocimiento de dominio propio, el cual puede transmitir de manera mas sencilla a otras personas.
¿Cómo sabemos qué ignoramos del mismo?
Dificultades en el entorno
En muchas ocasiones nos damos cuenta de un vacio que tenemos como personas en cuanto estamos comenzando a aprender algo nuevo. Y en muchas ocasiones por presión social decidimos no reafirmar lo que podemos llegar a conocer. Se puede decir que estamos hablando mas de un caracter socio-cultural.
Propongo el siguiente ejemplo:
-
Cuando estamos en clase y queremos preguntar sobre un comando de Markdown (o sobre otro tema, no tiene que ser Markdown), pero dudamos en hacerlo por miedo a que otros piensen que es una pregunta obvia.
-
Si intentamos escribir una lista anidada y no logramos que se vea correctamente, pero asumimos que algo está mal en vez de buscar el error o preguntar.
Si bien no es el único motivo por el cual una persona desconoce de un tema en específico, es un exponente por el cual una persona no se arriesga a cuestionar lo que está aprendiendo.
Investigación de la falla
En otra intancia y ya profundizando en el campo de cuando lo sabemos, es claro el punto de investigación que uno realiza a la hora de conocer sobre un tema en específico. En el momento que llega algún punto que una persona no entiende se busca algún medio para poder comprender donde está la falla y como solucionarla. Mayormente se utilizan tutoriales en Youtube y/o los chatbot los cuales últimamente han tenido una gran popularidad entre la sociedad.
¿Cómo disminuimos lo que ignoramos para aumentar/afianzar lo que sabemos?
Para solucionar nuestras dudas, es clave adoptar una mentalidad activa de aprendizaje. En lugar de ignorar los vacíos, podemos buscar respuestas a través de diferentes métodos, como la experimentación, la consulta de documentación oficial o el intercambio con otros que dominen el tema.
Ejemplo de cómo hacerlo en Markdown:
- Si no entendemos cómo hacer una tabla correctamente, podemos revisar la documentación de Markdown o probar diferentes estructuras hasta que funcione.
- O si un comando no genera el formato esperado, podemos preguntar en foros o comunidades especializadas como Stack Overflow o GitHub Discussions.
Resolver estas dudas no solo nos ayuda a mejorar en el tema, sino que también fortalece nuestra capacidad de aprender de forma autónoma y con mayor efectividad.
Podrá el código abierto cambiar la democracia
Mapa mental de como podrá el código abierto cambiar la democracia
Impresiones de Live coding
Impresiones
Para ser honesto, al explorar y analizar los contenidos de las plataformas Hedgedoc y Grafoscopía, sentí que el live coding representa una práctica profundamente innovadora y, al mismo tiempo, experimental. No se trata simplemente de una manera distinta de programar, sino de una propuesta que rompe los moldes tradicionales de la codificación, llevándola a un espacio de inmediatez, creatividad y, sobre todo, de interacción en tiempo real.
El live coding consiste en escribir código en vivo, generalmente con el propósito de producir resultados inmediatos, ya sea música, visuales, textos, o inclusive presentaciones artísticas interactivas. Esto lo convierte en un modelo que no solo aprovecha las capacidades del código ASCII y de los lenguajes de programación, sino que también fomenta una fusión entre la técnica y la expresión artística.
Al revisar estas plataformas, me llamó especialmente la atención cómo se abren nuevas posibilidades: el uso del código no únicamente como un medio técnico, sino como un lenguaje creativo en sí mismo. Las actividades de live coding pueden abarcar desde la creación de música algorítmica, escrita y modificada en tiempo real, hasta la producción colaborativa de documentos y obras literarias, como ocurre en las plataformas mencionadas.
Considero que este tipo de modelos pueden ser enormemente útiles para optimizar las ideas de los usuarios, ya que permiten materializar pensamientos, conceptos y experimentos de manera rápida, flexible y pública. El live coding rompe con la rigidez que tradicionalmente se le asocia a la programación, dándole un cariz más libre, espontáneo e incluso emocional.
Además, me pareció importante destacar la relación estrecha que existe entre el live coding y las comunidades colaborativas. Eventos como las Data Rodas y las Data Weeks son ejemplos claros de cómo estas prácticas fomentan entornos de aprendizaje colectivo, donde los conocimientos no se monopolizan, sino que se socializan, se construyen en conjunto y se democratizan. Este tipo de dinámicas también invita a repensar las formas tradicionales de enseñanza y de creación de conocimiento, privilegiando la horizontalidad y la accesibilidad.
El énfasis en el uso de herramientas específicas como FoxDot —un entorno para hacer música algorítmica en tiempo real usando Python—, o en lenguajes de programación como Smalltalk, muestra que el live coding no busca ser una práctica exclusiva de expertos, sino una actividad abierta a diferentes niveles de experiencia. Personas con poca o mucha trayectoria en programación pueden encontrar un espacio de participación y de experimentación, lo cual es sumamente valioso en un contexto donde a menudo el conocimiento técnico puede resultar intimidante.
Por otro lado, también me pareció interesante reflexionar sobre el carácter efímero pero documentable del live coding. Aunque lo que ocurre sucede en vivo, las plataformas como Hedgedoc permiten conservar una memoria colectiva de lo que se produce, lo que a su vez habilita nuevas formas de documentación viva, flexible y en constante evolución.
En resumen, el live coding me parece una práctica que dinamiza la relación entre programación, arte y comunidad, ofreciendo un abanico de posibilidades que van mucho más allá de la mera escritura de código para un producto final. Implica un cambio en la concepción misma de lo que significa crear, compartir y aprender en la era digital.
Inquietudes
A pesar de las múltiples ventajas que vislumbro en el live coding, también surgen algunas inquietudes al respecto. Una de las principales preguntas que me planteo tiene que ver con las dinámicas de colaboración: dado que el live coding se desarrolla en tiempo real, ¿sería posible que múltiples usuarios trabajen de manera simultánea sobre un mismo flujo de código?
En otras palabras, ¿podría llevarse a cabo una edición verdaderamente colaborativa, donde varios participantes estén conectados a un mismo sistema y modifiquen en vivo el contenido, sin perder la coherencia ni comprometer el desempeño del proceso? Esta posibilidad abriría escenarios aún más ricos en términos de interacción social, creación colectiva y aprendizaje compartido.
Relacionada con esta pregunta, también me surge la duda de cómo se gestionaría el control de cambios en un entorno así de dinámico. ¿Sería necesario implementar sistemas de control de versiones adaptados a la inmediatez del live coding? ¿O se buscarían otros mecanismos de resolución de conflictos y coordinación entre participantes?
Finalmente, otra inquietud importante sería el manejo de errores en tiempo real. Dado que el código se escribe en vivo y muchas veces bajo presión, es inevitable que surjan fallos, errores de sintaxis o problemas lógicos. ¿Cómo se maneja el error en un contexto de live coding? ¿Se considera parte del proceso creativo o se intenta minimizar a toda costa?
Challenge Yourself
Challenge Yourself
Ejercicios tomados del libro: Challenge yourself
Los ejercicios que se trabajaron fueron tomados del libro Challenge Yourself, que es básicamente la fuente base para esta parte del proceso. Todo esto también se puede ver reflejado en la página que publiqué usando Toolkit, donde está más claro visualmente cómo quedó lo que se hizo.
A continuación se anexará la página en donde se puede evidenciar la página donde se realizó el ejercicio:
Mapa mental, paradigmas de programación
Mapa mental paradigmas de programación
Lectura anotada pharo
Lectura anotada de Pharo
Representando y procesando datos en Pharo
"en el capítulo 1: ¿todo en Pharo es objeto? ¿hasta los números? ¿y los errores existenciales también son objetos o qué?"
"--- Números ---" 3 + 4. "en el capítulo 1: esto da 7. Ok, sí, pero... ¿por qué parece que 3 le está mandando una carta al 4? ¿esto es OOP en esteroides?"
10 - 2. "en el capítulo 1: resta normal, cero emoción." 5 * 2. "en el capítulo 1: esto da 10. matemáticas básicas funcionando como siempre." 20 / 4. "en el capítulo 1: da 5.0. ¿por qué no 5 a secas? Ah, porque ya están metiendo floats sin permiso..."
"--- Strings ---" 'Hola mundo'. "en el capítulo 2: ¿comillas simples para los strings? raro, pero bueno."
'Hola' , ' mundo'. "en el capítulo 2: ¿coma para concatenar? Qué poético."
'Pharo' class. "en el capítulo 2: esto devuelve 'String'. obvio, pero igual necesitaba comprobarlo porque uno nunca sabe..."
"--- Colecciones ---"
(1 2 3). "en el capítulo 3: esto es un array fijo. ¿pa’ qué me sirve si no lo puedo cambiar?"
Array with: 1 with: 2 with: 3. "en el capítulo 3: ahora sí, esto es más usable. gracias."
(1 2 3) at: 2. "en el capítulo 3: esto da 2. Pero... ¿por qué los índices empiezan en 1? ¿¡quién decidió esto!?"
"--- Diccionario ---" dict := Dictionary new. "en el capítulo 4: ok, diccionario creado. listo pa' chismear."
dict at: 'nombre' put: 'Thomas'. "en el capítulo 4: agregué 'nombre'. soy yo." dict at: 'edad' put: 24. "y obvio, la edad también. bastante autorreferencial este ejercicio."
dict at: 'nombre'. "en el capítulo 4: esto devuelve 'Thomas'. si no, algo explotó."
"--- Clases ---" "en el capítulo 5: hora de sentirme poderoso. vamos a crear una clase llamada Persona."
Object subclass: #Persona instanceVariableNames: 'nombre edad'. "tiene lo básico para existir: nombre y edad. con eso me basta."
p := Persona new. "en el capítulo 5: creé una persona. básicamente Dios."
p instVarNamed: 'nombre' put: 'Thomas'. "le metí el nombre. igualito a mí." p instVarNamed: 'edad' put: 24. "la edad también. seguimos clonándome."
p inspect. "en el capítulo 5: el inspector me deja ver por dentro a mi creación. medio creepy, medio cool."
json - pokemones
#Proyecto final
A continuación, se presentan los enlaces correspondientes al desarrollo del proyecto final. Por un lado, se encuentra el enlace al proyecto final implementado en GToolkit/Grafoscopio, donde se documenta y ejecuta el código solicitado en la actividad. Por otro lado, también se incluye el enlace a la narrativa original utilizada como base para extender y desarrollar el ejercicio. Ambos recursos están disponibles de forma pública y cumplen con los requerimientos establecidos por el profesor para esta entrega.
-Narrativa original del profesor
-Mi proyecto final basado en la narrativa original