search

gobstones / gobstones-web

[GobstonesWeb] The Gobstones Web IDE
http://gobstones.github.io/gobstones-web
GNU General Public License v3.0
14 stars 12 forks source link

Usar el standard Mumuki para nombrar los archivos dentro de un gbp #159

Closed faloi closed 7 years ago

faloi commented 7 years ago

Debería ser:

Nombre de archivo Uso
content.gbs y/o content.gbk Código del estudiante (texto y bloques)
backpack.gbs y/o backpack.gbk Biblioteca del estudiante (texto y bloques)
extra.gbs Biblioteca del docente
meta.yml Configuración del proyecto
*.gbb Tablero
assets/attires/{nombre}/config.yml Asociaciones de la vestimenta {nombre}
assets/attires/{nombre}/*.{png-jpg} Imagenes de la vestimenta {nombre}
description.md o description.pdf Consigna

@flbulgarelli, por favor opiná acá.

flbulgarelli commented 7 years ago

Totalmente de acuerdo.

Algunos comentarios y cosas para discutir:

  1. En lugar de llamarlo library, lo llamaría directamente backpack (mochila). De esa forma queda la siguiente metáfora: la biblioteca la provee el docente, mientras que la mochila la llena el estudiante.
  2. Nosotros utilizamos el archivo extra tanto para código oculto (hidden code) como para la biblioteca en sí (library), dado que por limitaciones de la plataforma hoy no soportamos tener ambos al mismo tiempo. Si están pensando dar soporte a una combinación de ambas, entonces quizás deban hacer lo que nosotros no hicimos: tener dos archivos extra.gbs y library.gbs.
  3. ¿Por qué no YAML en lugar de JSON para el meta? Es mucho más fácil de leer y escribir por un humano.
  4. Mas allá de lo anterior, recomiendo también dar un vistazo al contenido del meta: https://github.com/MumukiProject/mumuki-guia-ruby-metaprogramacion-el-modelo-de-clases/blob/master/meta.yml
  5. Al directorio de vestimentas, en lugar de llamarlo attires, lo llamaría simplemente assets, no sólo por compatibilidad con nosotros sino también para facilitar agregar otros recursos en el futuro. O al menos, anidarlo dentro de assets
flbulgarelli commented 7 years ago

Mirar https://github.com/mumuki/mumuki.github.io/blob/old-master/_posts/2015-07-10-escribiendo-guias.markdown

faloi commented 7 years ago
  1. En lugar de llamarlo library, lo llamaría directamente backpack (mochila). De esa forma queda la siguiente metáfora: la biblioteca la provee el docente, mientras que la mochila la llena el estudiante.
  2. Nosotros utilizamos el archivo extra tanto para código oculto (hidden code) como para la biblioteca en sí (library), dado que por limitaciones de la plataforma hoy no soportamos tener ambos al mismo tiempo. Si están pensando dar soporte a una combinación de ambas, entonces quizás deban hacer lo que nosotros no hicimos: tener dos archivos extra.gbs y library.gbs.

Tendríamos 3 lugares donde poner código: el content, el backpack (siempre editable) y el extra (siempre invisible).

  1. ¿Por qué no YAML en lugar de JSON para el meta? Es mucho más fácil de leer y escribir por un humano.

Porque JSON es a JS lo que YAML es a Ruby. :wink: Lo podemos cambiar.

  1. Mas allá de lo anterior, recomiendo también dar un vistazo al contenido del meta: https://github.com/MumukiProject/mumuki-guia-ruby-metaprogramacion-el-modelo-de-clases/blob/master/meta.yml

Ojo que ahí me pasás un meta de guía, debería ser análogo al de ejercicio (ejemplo: https://github.com/MumukiProject/mumuki-guia-ruby-metaprogramacion-el-modelo-de-clases/blob/master/00001_%C2%A1Hola%20Mundo!/meta.yml).

En ese punto no me parece que vaya a haber convergencia, porque son cosas muy específicas de cada herramienta: nosotros ahí ponemos cuestiones de configuración de la interfaz como el tablero seleccionado, la vestimenta activa o la velocidad de ejecución.

¿Por ahí vale la pena tener dos distintos?

  1. Al directorio de vestimentas, en lugar de llamarlo attires, lo llamaría simplemente assets, no sólo por compatibilidad con nosotros sino también para facilitar agregar otros recursos en el futuro. O al menos, anidarlo dentro de assets

Ok a anidarlo.

faloi commented 7 years ago

@flbulgarelli vuelvo sobre esto. Pensando en el código extra, se me ocurre que en el "nuevo estándar" podríamos directamente llamarlo library, y así quedaría:

¿Cierra?

@rodri042, fijate si ves algún problema con la implementación.

afska commented 7 years ago

Quedaría entonces:

Nombre de archivo Uso
content.gbs y/o content.gbk Código del estudiante (texto y bloques)
backpack.gbs y/o backpack.gbk Biblioteca del estudiante (texto y bloques)
library.gbs Biblioteca del docente
meta.json Configuración del proyecto
*.gbb Tablero
assets/attires/{nombre}/config.json Asociaciones de la vestimenta {nombre}
assets/attires/{nombre}/*.{png-jpg} Imagenes de la vestimenta {nombre}
description.md o description.pdf Consigna

Sí, se puede hacer. Tengo entendido que ya hay varios proyectos armados igual, habría que hacer algo para migrarlos.

faloi commented 7 years ago

De la migración me encargo yo, no te hagas drama.

Esperemos a ver qué dice Franco, a mí me parece bien así. Editá la descripción de la issue así ya queda bien ahí también.

Cuando lo tengamos, sería bueno hacer al menos una entrada en una wiki explicando el formato, así queda...

fidel-ml commented 7 years ago

Es "backpack.gbs y backpack.gbk"? O está bien que una vez diga "backpack" y la segunda "library"?

Sobre la migración, Fede dijo que haría un script... :) FF

2017-06-02 15:10 GMT-03:00 Rodrigo Alfonso notifications@github.com:

Quedaría entonces: Nombre de archivo Uso content.gbs y/o content.gbk Código del estudiante (texto y bloques) backpack.gbs y/o library.gbk Biblioteca del estudiante (texto y bloques) library.gbs Biblioteca del docente meta.json Configuración del proyecto .gbb Tablero assets/attires/{nombre}/config.json Asociaciones de la vestimenta {nombre} assets/attires/{nombre}/.{png-jpg} Imagenes de la vestimenta {nombre} description.md o description.pdf Consigna

Sí, se puede hacer. Tengo entendido que ya hay varios proyectos armados igual, habría que hacer algo para migrarlos.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gobstones/gobstones-web/issues/159#issuecomment-305869581, or mute the thread https://github.com/notifications/unsubscribe-auth/AIaqtkdGE5Ao0ZohpUJ9wxR8Pij0ObGWks5sAFApgaJpZM4NkBNY .[image: Web Bug from https://github.com/notifications/beacon/AIaqtqLkj6RbUfihwUrb7t1ELM6wDD8lks5sAFApgaJpZM4NkBNY.gif] {"api_version":"1.0","publisher":{"api_key":" 05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity": {"external_key":"github/gobstones/gobstones-web"," title":"gobstones/gobstones-web","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/ 143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png"," avatar_image_url":"https://cloud.githubusercontent.com/ assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png ","action":{"name":"Open in GitHub","url":"https://github. com/gobstones/gobstones-web"}},"updates":{"snippets":[{" icon":"PERSON","message":"@rodri042 in #159: Quedaría entonces:\r\n\r\n|Nombre de archivo|Uso|\r\n|------------- -------------|-----|\r\n|content.gbs y/o content.gbk|Código del estudiante (texto y bloques)|\r\n|backpack.gbs y/o library.gbk|Biblioteca del estudiante (texto y bloques)|\r\n|library.gbs|Biblioteca del docente|\r\n|meta.json|Configuración del proyecto|\r\n|*.gbb|Tablero| \r\n|assets/attires/{nombre}/config.json|Asociaciones de la vestimenta {nombre}|\r\n|assets/attires/{nombre}/*.{png-jpg}|Imagenes de la vestimenta {nombre}|\r\n|description.md o description.pdf|Consigna|\r\n\r\nSí, se puede hacer. Tengo entendido que ya hay varios proyectos armados igual, habría que hacer algo para migrarlos."}],"action":{"name":"View Issue","url":"https://github. com/gobstones/gobstones-web/issues/159#issuecomment-305869581"}}}

-- Este mensaje ha sido analizado por el servidor antispam1.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

faloi commented 7 years ago

Y una más, ¿pasamos los JSON a YAML? No tengo una postura fuerte al respecto.

fidel-ml commented 7 years ago

¿Ahora que aprendí JSON? :( JAJA Tampoco tengo una postura fuerte, especialmente porque no tengo ni idea de qué formato es YAML. FF

2017-06-02 15:20 GMT-03:00 Federico Aloi notifications@github.com:

Y una más, ¿pasamos los JSON a YAML? No tengo una postura fuerte al respecto.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gobstones/gobstones-web/issues/159#issuecomment-305871926, or mute the thread https://github.com/notifications/unsubscribe-auth/AIaqtoSQDsRPmIHUeIMkr_df4hs2lh4Xks5sAFJWgaJpZM4NkBNY . {"api_version":"1.0","publisher":{"api_key":" 05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity": {"external_key":"github/gobstones/gobstones-web"," title":"gobstones/gobstones-web","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/ 143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png"," avatar_image_url":"https://cloud.githubusercontent.com/ assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png ","action":{"name":"Open in GitHub","url":"https://github. com/gobstones/gobstones-web"}},"updates":{"snippets":[{" icon":"PERSON","message":"@faloi in #159: Y una más, ¿pasamos los JSON a YAML? No tengo una postura fuerte al respecto."}],"action":{"name":"View Issue","url":"https://github.com/gobstones/gobstones-web/ issues/159#issuecomment-305871926"}}}

-- Este mensaje ha sido analizado por el servidor antispam1.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

afska commented 7 years ago

Es "backpack.gbs y backpack.gbk"? O está bien que una vez diga "backpack" y la segunda "library"?

Eso fue un error que edité rápido jaja

Y una más, ¿pasamos los JSON a YAML? No tengo una postura fuerte al respecto.

Hmm, a mí me hace ruido meter algo más para parsear YAML teniendo JSON gratis. Y me es más humano el JSON, pero eso ya es personal :stuck_out_tongue:

flbulgarelli commented 7 years ago

library la biblioteca que arma el/a docente para un ejercicio, y que en el caso de Gobstones no se puede ver, mientras que en Mumuki es configurable.

Si no vas a separar las semánticas de hidden vs library, entonces yo no cambiaría el nombre, porque nadie gana nada con eso, y lo mantendría como extra. Además así Mumuki no tendría que cambiar nada.

Todo lo demás, ok.

Sobre la discusión json vs yaml, aclaro que Yaml es un un superconjunto de JSON, pero más legible para personas no técnicas - o sea, @rodri042 no es un buen parámetro :stuck_out_tongue: -.

Después la decisión va por si la intereporabilidad es teórica (es decir, buscando que sean formatos conceptualmente parecidos), o si realmente queremos que el contenido generado en Gobstones Jr se pueda integrar en Mumuki. Si queremos que realmente uno pueda consumir al otro (personalmente, yo voto por esto), entonces no veo otra opción que adoptar YAML.

Si no, JSON puede andar, a expensas de perder la posibilidad de integrar ambas herramientas en el corto plazo.

faloi commented 7 years ago

Si no vas a separar las semánticas de hidden vs library, entonces yo no cambiaría el nombre, porque nadie gana nada con eso, y lo mantendría como extra. Además así Mumuki no tendría que cambiar nada.

Acá me estás haciendo trampa, veamos cada cosa por separado.

Si no vas a separar las semánticas de hidden vs library, entonces yo no cambiaría el nombre

En verdad hoy ya tenemos esa diferencia, aunque lo resolvimos con un hack:

porque nadie gana nada con eso, y lo mantendría como extra

De todas formas, aunque no se usara, yo creo que sí ganamos. Fijate que la diferencia entre vista y modelo genera inconsistencias: https://github.com/mumuki/mumuki-platform/issues/266.

Ok, hay que modificar el "estándar". Pero dado que recién tiene sentido hablar de un estándar cuando somos varios que lo usamos, me parece que el momento para corregirlo es ahora.

Además así Mumuki no tendría que cambiar nada.

Bueno, eso no es argumento che, por acá también hay que cambiar unas cuantas cosas para favorecer la interoperabilidad. :stuck_out_tongue:

flbulgarelli commented 7 years ago

En verdad hoy ya tenemos esa diferencia, aunque lo resolvimos con un hack

Pero esa diferencia la estás resolviendo de una forma muy diferente, mediante la firma - o mañana lo podrías hacer mediante un comentario especial, o parándote en algo que haga mulang. No diría que es un hack, diría que es otra forma posible, que hoy Mumuki no tiene y que vale le pena analizar :smile:.

Con más motivo, desde mi punto de vista tu archivo library no es tal, es código adicional (extra_code): tiene funciones de biblioteca más código oculto. Con lo cual yo veo que llamarlo library y después tenga código oculto (es decir, es una biblioteca pero no se puede consultar :scream:), a mí sí me hace mucho ruido semántico. Y esto me lleva al siguiente ítem.

De todas formas, aunque no se usara, yo creo que sí ganamos. Fijate que la diferencia entre vista y modelo genera inconsistencias: mumuki/mumuki-platform#266.

Lo estuve pensando bastante y estoy bastante convencido de que ese issue no es tal cosa. La respuesta evidente es que esa aparente inconsistencia nunca ha traído problemas entre los usuarios (editores), pero sé que este argumento no es suficientemente fuerte: los editores podrían haberse acostumbrado a la inconsistencia, o bien quizás yo no nunca me enteré :stuck_out_tongue:.

Pero para lo que yo veo es que sí hay un modelo consistente detrás: todo ejercicio tiene código adicional, que puede ser (o puede cumplir el rol de):

Por eso pienso, e insisto: si la idea es separar ambas ideas en archivos diferentes y permitir que convivan, yo propondría separar en dos archivos: hidden y library. Si no, mantendría la semántica actual del archivo extra, y el flag de rol biblioteca | codigo oculto en el meta.yml.

Yo tengo un motivo extra por esta idea: no estoy convencido de que la separación en dos secciones privadas y públicas sea suficiente o buena, sino quizás sea mejor un camino basado en firmas o metadatos en la sección de código extra, que permita separar lo que va a la biblioteca de lo que se queda en el arcón (?) con un grano más fino. Hoy no puedo decir qué es lo que hay que hacer, porque las herramientas son limitadas (justo recién tengo una primera versión del análisis de firmas en mulang, que sería una iteración 0 de algo que no sé a dónde me va a llevar). Separar tempranamente en hidden y library me parece problemático, prefiero que sea todo lo mismo y pero poder cambiar su rol. Keep it simple.

(esto te lo iba a comentar en el otro issue, pero ya que estamos, matamos dos pájaros de un tiro acá)

Además así Mumuki no tendría que cambiar nada.

No es menor, si vos me proponés un cambio del que no estamos super convencidos, del que no veo un beneficio (salvo lo de la consistencia del modelo, y como ves eso es discutible), que implica una migración de datos, que no mueve el dial del lado de los ejercicios de gobstones (porque de todas formas igual ibas a migrarlos), no tener que cambiar algo en otro lado ES un valor.

En fin, te leo.

fidel-ml commented 7 years ago

Yo me estoy perdiendo algo en esta discusión... Pero dado que la idea de "biblioteca del docente" es mía, la voy a defender. Empecemos por una parte: NO es código oculto. Es código abstracto. O sea, la biblioteca del docente ofrece operaciones abstractas, de las que solo se vé la "firma" (prefiero "signatura"... :)). Entonces, llamarlo "oculto" confunde. Es cierto que no se puede ver cómo está implementado; pero esa es, precisamente, la idea de la abstracción: la implementación no importa, solo la funcionalidad. Por esa razón también es que durante la ejecución paso a paso toma cada una de esas acciones como atómicas: son abstractas. Y por eso no estoy nada de acuerdo con llamar "hidden" a este archivo, ni marcarlo como "código oculto" en las configuraciones. Prefiero "biblioteca de procedimientos primitivos", "biblioteca del docente", "código abstracto", o algo que apunte a su naturaleza. Siendo abstracta, el estudiante no puede meter mano, ni agregar o cambiar cosas.

Con respecto a la biblioteca del estudiante, tengo mis dudas. Originalmente fue ideada para ser una pieza de código que sirviese de manera única entre distintas actividades. Pero no logramos dar con una interfaz que favoreciese esa visión, y degeneró a ser simplemente un archivo donde poner algunas cosas. De hecho, en el manual de secundaria no la usamos para nada. Yo estoy dándole vueltas a la idea de reemplazar la biblioteca del estudiante con "páginas" de código. O sea, está el programa principal, y sus páginas, y cada página tiene lo que se te antoje. Ahí el estudiante tiene libertad de usarlas como quiera, y puede tener tantas páginas como quiera... Pero es una idea que aún no discutimos, y solamente da vueltas en mi cabeza. Por ahora. Lo que quiero decir es que la biblioteca como la imaginamos no es sólida conceptualmente, y tenemos que revisarla antes de decidir su nombre... FF

2017-06-06 9:40 GMT-03:00 Franco Leonardo Bulgarelli < notifications@github.com>:

En verdad hoy ya tenemos esa diferencia, aunque lo resolvimos con un hack

Pero esa diferencia la estás resolviendo de una forma muy diferente, mediante la firma - o mañana lo podrías hacer mediante un comentario especial, o parándote en algo que haga mulang. No diría que es un hack, diría que es otra forma posible, que hoy Mumuki no tiene y que vale le pena analizar 😄.

Con más motivo, desde mi punto de vista tu archivo library no es tal, es código adicional (extra_code): tiene funciones de biblioteca más código oculto. Con lo cual yo veo que llamarlo library y después tenga código oculto (es decir, es una biblioteca pero no se puede consultar 😱), a mí sí me hace mucho ruido semántico. Y esto me lleva al siguiente ítem.

De todas formas, aunque no se usara, yo creo que sí ganamos. Fijate que la diferencia entre vista y modelo genera inconsistencias: mumuki/mumuki-platform#266 https://github.com/mumuki/mumuki-platform/issues/266.

Lo estuve pensando bastante y estoy bastante convencido de que ese issue no es tal cosa. La respuesta evidente es que esa aparente inconsistencia nunca ha traído problemas entre los usuarios (editores), pero sé que este argumento no es suficientemente fuerte: los editores podrían haberse acostumbrado a la inconsistencia, o bien quizás yo no nunca me enteré 😛.

Pero para lo que yo veo es que sí hay un modelo consistente detrás: todo ejercicio tiene código adicional, que puede ser (o puede cumplir el rol de):

  • una biblioteca, si está disponible para que el estudiante lo use directamente y vea, ya sea su implementación o sólo sus firmas.
  • código oculto (o código privado, o busquemos un mejor nombre), si está disponible sólo para permitir que el ejercicio (ya sea un problema o área de juego) funcione, pero el estudiante NO debería verlo ni utilizarlo.

Por eso pienso, e insisto: si la idea es separar ambas ideas en archivos diferentes y permitir que convivan, yo propondría separar en dos archivos: hidden y library. Si no, mantendría la semántica actual del archivo extra, y el flag de rol biblioteca | codigo oculto en el meta.yml.

Yo tengo un motivo extra por esta idea: no estoy convencido de que la separación en dos secciones privadas y públicas sea suficiente o buena, sino quizás sea mejor un camino basado en firmas o metadatos en la sección de código extra, que permita separar lo que va a la biblioteca de lo que se queda en el arcón (?) con un grano más fino. Hoy no puedo decir qué es lo que hay que hacer, porque las herramientas son limitadas (justo recién tengo una primera versión del análisis de firmas en mulang, que sería una iteración 0 de algo que no sé a dónde me va a llevar). Separar tempranamente en hidden y library me parece problemático, prefiero que sea todo lo mismo y pero poder cambiar su rol. Keep it simple.

(esto te lo iba a comentar en el otro issue, pero ya que estamos, matamos dos pájaros de un tiro acá)

Además así Mumuki no tendría que cambiar nada.

No es menor, si vos me proponés un cambio del que no estamos super convencidos, del que no veo un beneficio (salvo lo de la consistencia del modelo, y como ves eso es discutible), que implica una migración de datos, que no mueve el dial del lado de los ejercicios de gobstones (porque de todas formas igual ibas a migrarlos), no tener que cambiar algo en otro lado ES un valor.

En fin, te leo.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gobstones/gobstones-web/issues/159#issuecomment-306473695, or mute the thread https://github.com/notifications/unsubscribe-auth/AIaqto059nlKEDaQ1OP693PCgzef4GsNks5sBUipgaJpZM4NkBNY .[image: Web Bug from https://github.com/notifications/beacon/AIaqtgdsQP91BNG3Jo0HWIf-Oku4h5UVks5sBUipgaJpZM4NkBNY.gif] {"api_version":"1.0","publisher":{"apikey":"05dde50f1d1a384 dd78767c55493e4bb","name":"GitHub"},"entity":{"external key":"github/gobstones/gobstones-web","title":"gobstones/gobstones-web","subtitle":"GitHub repository","main_image_url":"https://cloud.githubuserconten t.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png ","avatar_image_url":"https://cloud.githubusercontent.com/assets/ 143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/gobstones/gobstones-web"}} ,"updates":{"snippets":[{"icon":"PERSON","message":"@flbulgarelli in

159: \u003e En verdad hoy ya tenemos esa diferencia, aunque lo resolvimos

con un hack\r\n\r\nPero esa diferencia la estás resolviendo de una forma muy diferente, mediante la firma - o mañana lo podrías hacer mediante un comentario especial, o parándote en algo que haga mulang. No diría que es un hack, diría que es otra forma posible, que hoy Mumuki no tiene y que vale le pena analizar :smile:.\r\n\r\nCon más motivo, desde mi punto de vista tu archivo library no es tal, es código adicional (extra_code): tiene funciones de biblioteca más código oculto. Con lo cual yo veo que llamarlo library y después tenga código oculto (es decir, es una biblioteca pero no se puede consultar :scream:), a mí sí me hace mucho ruido semántico. Y esto me lleva al siguiente ítem. \r\n\r\n\u003e De todas formas, aunque no se usara, yo creo que sí ganamos. Fijate que la diferencia entre vista y modelo genera inconsistencias: mumuki/mumuki-platform#266.\r\n\r\nLo estuve pensando bastante y estoy bastante convencido de que ese issue no es tal cosa. La respuesta evidente es que esa aparente inconsistencia nunca ha traído problemas entre los usuarios (editores), pero sé que este argumento no es suficientemente fuerte: los editores podrían haberse acostumbrado a la inconsistencia, o bien quizás yo no nunca me enteré :stuck_out_tongue:.\r\n\r\nPero para lo que yo veo es que sí hay un modelo consistente detrás: todo ejercicio tiene código adicional, que puede ser (o puede cumplir el rol de): \r\n una biblioteca, si está disponible para que el estudiante lo use directamente y vea, ya sea su implementación o sólo sus firmas. \r\n código oculto (o código privado, o busquemos un mejor nombre), si está disponible sólo para permitir que el ejercicio (ya sea un problema o área de juego) funcione, pero el estudiante NO debería verlo ni utilizarlo. \r\n\r\nPor eso pienso, e insisto: si la idea es separar ambas ideas en archivos diferentes y permitir que convivan, yo propondría separar en dos archivos: hidden y library. Si no, mantendría la semántica actual del archivo extra, y el flag de rol biblioteca | codigo oculto en el meta.yml. \r\n\r\nYo tengo un motivo extra por esta idea: no estoy convencido de que la separación en dos secciones privadas y públicas sea suficiente o buena, sino quizás sea mejor un camino basado en firmas o metadatos en la sección de código extra, que permita separar lo que va a la biblioteca de lo que se queda en el arcón (?) con un grano más fino. Hoy no puedo decir qué es lo que hay que hacer, porque las herramientas son limitadas (justo recién tengo una primera versión del análisis de firmas en mulang, que sería una iteración 0 de algo que no sé a dónde me va a llevar). Separar tempranamente en hidden y library me parece problemático, prefiero que sea todo lo mismo y pero poder cambiar su rol. Keep it simple. \r\n\r\n(esto te lo iba a comentar en el otro issue, pero ya que estamos, matamos dos pájaros de un tiro acá)\r\n\r\n \u003e Además así Mumuki no tendría que cambiar nada.\r\n\r\nNo es menor, si vos me proponés un cambio del que no estamos super convencidos, del que no veo un beneficio (salvo lo de la consistencia del modelo, y como ves eso es discutible), que implica una migración de datos, que no mueve el dial del lado de los ejercicios de gobstones (porque de todas formas igual ibas a migrarlos), no tener que cambiar algo en otro lado ES un valor. \r\n\r\nEn fin, te leo. \r\n\r\n"}],"action":{"name":"View Issue","url":"https://github.c om/gobstones/gobstones-web/issues/159#issuecomment-306473695"}}}

Este mensaje ha sido analizado por el servidor antispam2.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

faloi commented 7 years ago

Bueno @flbulgarelli, voy a acordar con vos. Chequeá si ves algo raro así lo podemos hacer:

Nombre de archivo Uso
content.gbs y/o content.gbk Código del estudiante (texto y bloques)
backpack.gbs y/o backpack.gbk Biblioteca del estudiante (texto y bloques)
extra.gbs Biblioteca del docente
meta.yml Configuración del proyecto
*.gbb Tablero
assets/attires/{nombre}/config.yml Asociaciones de la vestimenta {nombre}
assets/attires/{nombre}/*.{png-jpg} Imagenes de la vestimenta {nombre}
description.md o description.pdf Consigna
flbulgarelli commented 7 years ago

Dale para adelante. Por mí está ok.

faloi commented 7 years ago

@rodri042, ya podés avanzar con esto.

afska commented 7 years ago

Hecho en https://github.com/gobstones/gobstones-web/pull/191