Slide 1 — Daily flow: from the classroom to public documentation

In my modules, I try to connect the classroom with the way technical documentation is used in real IT environments.

The basic flow is simple. I plan the module in Aules, the official learning management system of the Valencian education system, which is based on Moodle. From there, students access the lessons, the tasks and the links to my official notes.

Those notes are not isolated PDF files. They are written in Markdown, stored in GitHub, and published as a website with GitHub Pages and MkDocs Material.

So students see a complete workflow: a task starts in the LMS, connects to technical documentation, lives in a version-controlled repository, and becomes a public documentation website.

Key ideas

• Aules is the formal entry point for planning, communication and task submission.
• Lessons and tasks are linked to technical notes.
• GitHub, Markdown and MkDocs turn class materials into living documentation.

Transition

Let me start with Aules, because it is the official academic space where the learning process is organised.

Slide 2 — Aules as the official LMS

Aules is the official LMS of the Valencian education system. It provides a virtual learning environment for each module and gives students a single, reliable place to check what they have to do.

I use Aules for the calendar, announcements, resources, activities, deadlines and task submissions. It is also where I publish rubrics and where students submit links to their repositories, documentation websites, demos or self-assessments.

For me, Aules gives the formal structure of the course. It keeps the pedagogical part clear: what the activity is, when it must be delivered, how it will be assessed, and which learning outcomes are involved.

Key ideas

• Aules is Moodle-based and institutionally supported.
• It organises tasks, deadlines, communication and assessment.
• Students submit links and evidence through one official platform.

Transition

Once the academic structure is clear, the learning materials themselves are managed in a more technical format: Markdown.

Slide 3 — Markdown and Cursor for teaching materials

Most of my lessons and tasks are written in Markdown, a plain text format that is very common in technical documentation.

Markdown is useful because it keeps the focus on content and structure. It is easy to edit, easy to version, and very close to the way documentation is written in many open-source and DevOps projects.

I also use Cursor to improve these materials. Cursor helps me refine structure, simplify explanations, detect repetition, improve code examples and adapt existing documents to different formats.

But the important point is that Cursor does not replace the teacher. The pedagogical decisions, the technical criteria and the final responsibility remain mine. AI helps me work faster and reuse better documentation, especially when I need to prepare material for Erasmus contexts in English.

Key ideas

• Markdown is simple, technical and versionable.
• Cursor helps improve structure, clarity and code quality.
• AI supports the teacher, but the teacher remains the author.

Transition

Because these materials are plain text, the natural place to manage them is a GitHub repository.

Slide 4 — GitHub as a version-controlled repository

My notes are hosted on GitHub as Markdown documents inside a version-controlled repository.

This gives me a structured knowledge base that can grow over time. Every change is tracked, so I can review the history of the material, recover previous versions, and keep the documentation consistent across updates.

This is also a professional model for students. They see that documentation is not a static file sent once by email. It is a maintained project, with commits, history, structure and continuous improvement.

In the ASIR project, students use the same logic for their own work: code, configuration files, infrastructure files and documentation are all managed together in GitHub.

Key ideas

• GitHub provides version control and traceability.
• Documentation becomes a maintained technical project.
• Students learn workflows used in real IT teams.

Transition

The next step is publishing, because documentation becomes much more meaningful when it is visible and usable as a website.

Slide 5 — GitHub Pages and MkDocs Material

The Markdown notes are published as a static documentation website using GitHub Pages and MkDocs Material.

GitHub Pages hosts the website directly from the repository. MkDocs Material provides the documentation framework: navigation, search, code highlighting, diagrams, admonitions and a clean technical interface.

For students, this changes the perception of their work. A technical report is no longer just a document uploaded at the end. It becomes a professional-looking website that can be reviewed, updated and shared.

This also reinforces an important habit: if the documentation is published, it has to be clear, structured and useful for someone else.

Key ideas

• GitHub Pages publishes the documentation from the repository.
• MkDocs Material gives a professional documentation interface.
• Students learn to write for real readers, not only for the teacher.

Transition

If we put these tools together, we get a complete teaching ecosystem.

Slide 6 — Final overview of the teaching tech ecosystem

This slide summarises the whole ecosystem: Aules, GitHub, Markdown and MkDocs Material.

Each tool has a clear function. Aules gives academic organisation. GitHub gives version control. Markdown gives a simple format for technical writing. MkDocs Material gives web publishing.

What matters is not each tool separately, but the workflow they create together. Students work with documentation, code and infrastructure using the same techniques: plain text, repositories, version control and public publishing.

This is very close to the culture they will find in professional environments, especially in systems administration, DevOps and cloud infrastructure.

Key ideas

• Aules provides academic organisation.
• GitHub provides version control.
• Markdown supports technical writing.
• MkDocs Material publishes the final documentation website.

Transition

The clearest example of this methodology in practice is the ASIR Cross-Module Project.

Slide 7 — Case study · ASIR Cross-Module Project

This final slide shows how the methodology is applied in the ASIR Cross-Module Project.

Students work on a real IT infrastructure throughout the school year. The project combines Project-Based Learning and Challenge-Based Learning, because each stage produces a concrete result that becomes part of the final infrastructure.

The project integrates several ASIR modules: databases, operating systems, web services, networking and security. Depending on the group, students deploy their solution using Docker or AWS, but the goal is the same: to build, operate and explain a complete infrastructure.

The workflow is progressive: planning, development, documentation, publishing and final defence. Documentation is continuous and is published on GitHub Pages, so the technical report grows together with the project.

Students work in cooperative teams of two or three people. They distribute responsibilities, but everyone must understand the whole system, because in the final defence any student can be asked about any part of the project.

For me, this is the main value of the methodology: students do not only learn tools. They learn how to plan, build, document, publish and defend a real technical solution as a team.

Key ideas

• The project follows a clear sequence: planning, development, documentation, publishing and final defence.
• It integrates databases, operating systems, web, networking and security.
• Docker or AWS provide realistic deployment scenarios.
• Continuous documentation and cooperative work are part of the assessment.

Transition

This closes the presentation: the methodology combines a formal LMS, professional documentation tools, project-based learning and responsible use of AI to prepare students for real technical work.