Creación de tracks

Un track consta de muchas partes diferentes.

Metadatos

La configuración y los metadatos del track se especifican en el archivo config.json. En él se listan los ejercicios, los conceptos, la configuración del editor y mucho más del track. Consulta la documentación de config.json.

Conceptos

Todos los ejercicios de concepto y de práctica de un track involucran conceptos. Estos conceptos son entidades independientes por sí mismos. Consulta la documentación para obtener más información.

Los conceptos que se enseñan en los ejercicios de concepto del track forman un temario. El temario se muestra a los estudiantes como un mapa de conceptos. Consulta la documentación del mapa de conceptos para aprender a construir el mapa de conceptos de un temario.

Para obtener más información sobre cómo diseñar un temario, consulta la documentación del temario.

Ejercicios

Los tracks tienen dos tipos de ejercicios:

  • Ejercicios de concepto: están diseñados para enseñarle uno o más conceptos a un estudiante. Consulta la documentación para obtener más información.
  • Ejercicios de práctica: están diseñados para practicar los conceptos aprendidos. Consulta la documentación para obtener más información.

Dig Deeper

Cada ejercicio tiene una sección Dig Deeper opcional que puede contener:

  • Enfoques: distintas formas en las que se puede resolver el ejercicio
  • Artículos: describen aspectos interesantes del ejercicio
  • Videos de la comunidad: videos que muestran el ejercicio, por lo general con alguien que lo resuelve desde cero

Archivos compartidos

Algunos archivos no son específicos de ejercicios individuales, sino que se aplican a todos los ejercicios. Consulta la documentación para obtener más información.

Documentación

Cada track tiene algunos archivos de documentación obligatorios. Consulta la documentación para obtener más información.

Widgets

Algunas partes del track se pueden mostrar en widgets.

Guía de estilo

Todos los documentos deben seguir la guía de estilo. Los documentos de Markdown también deben seguir nuestros estándares de Markdown.

Ejemplo

csharp
├── config
|   ├── exercise_readme.go.tmpl
|   └── maintainers.json
├── docs
|   ├── ABOUT.md
|   ├── INSTALLATION.md
|   ├── LEARNING.md
|   ├── RESOURCES.md
|   └── TESTS.md
├── concepts
|   └── numbers
|       ├── about.md
|       ├── introduction.md
|       └── links.json
└── exercises
|   ├── concept
|   |   └── cars-assemble
|   |       ├── .docs
|   |       |   ├── hints.md
|   |       |   ├── introduction.md
|   |       |   └── instructions.md
|   |       ├── .meta
|   |       |   ├── config.json
|   |       |   ├── design.md
|   |       |   └── Exemplar.cs (track-specific)
|   |       ├── CarsAssemble.cs (track-specific)
|   |       ├── CarsAssemble.csproj (track-specific)
|   |       └── CarsAssembleTests.cs (track-specific)
|   ├── practice
|   |   └── leap
|   |       └── .docs
|   |       |   └── instructions.md
|   |       └── .meta
|   |       |   ├── config.json
|   |       |   └── Example.cs (track-specific)
|   |       ├── Leap.cs (track-specific)
|   |       ├── Leap.csproj (track-specific)
|   |       └── LeapTests.cs (track-specific)
|   └── shared
|       └── .docs
|           ├── debug.md
|           ├── help.md
|           └── tests.md
└── config.json

Mantenimiento

Permisos del repositorio

A cada track se le asigna (automáticamente) una categoría de mantenimiento, que determina los permisos del repositorio de GitHub del mantenedor del track.

Evitar provocar ejecuciones de pruebas innecesarias

Cuando fusionas un PR del track que toca un ejercicio, se activa la repetición de todas las últimas iteraciones publicadas de las soluciones de los estudiantes. En el caso de los ejercicios populares, esta es una operación muy costosa (¡70,000 ejecuciones de pruebas para el Hello World de Python, como caso extremo!).

Te animamos a intentar evitar hacer esto sin necesidad.

Las soluciones no se volverán a probar si el commit fusionado cumple una de estas dos condiciones:

  • solo toca archivos .docs o .meta, u otros archivos con los que los usuarios no interactúan
  • o contiene [no important files changed] en el cuerpo del commit.

Las soluciones sí se volverán a probar si el commit fusionado cumple las dos condiciones siguientes:

  • carece de [no important files changed] en el cuerpo del commit
  • y toca uno de los siguientes archivos de un ejercicio (según se especifica en su archivo .meta/config.json):
    • archivos de pruebas
    • archivos del editor
    • archivos invalidadores

Algunos ejemplos:

  • Python#3423: solo toca la documentación, así que no se ejecutó ninguna prueba
  • Python#3437: se fusionó con [no important files changed] agregado, así que no se ejecutó ninguna prueba
  • Csharp#2138: se eliminaron los espacios en blanco de las pruebas. La palabra clave no se agregó. Las pruebas se volvieron a ejecutar sin necesidad.