Paul Manstetten
Senior Scientist Dipl.-Ing.(FH) Dr.techn.
Publications

Biography

Paul Manstetten was born in Berlin, Germany. He studied Mechatronics at the University of Applied Sciences Regensburg (Dipl.-Ing.) and Computational Engineering at the University of Erlangen-Nuremberg (MSc). After three years as an application engineer for optical simulations at OSRAM Opto Semiconductors in Regensburg, he joined the Institute for Microelectronics in 2015 as a project assistant. He finished his PhD studies (Dr.techn.) in 2018 and was employed as a postdoctoral researcher on high performance computing methods for semiconductor process simulations until 2022. Starting 2019, his activities include teaching assignments with a focus on C/C++ and numerical methods for scientific computing. Currently, his main focus is supporting the restructuring and expansion of the bachelor's program Electrical Engineering and Information Technology w.r.t. the programming lectures lead by the Institute for Microelectronics.

Git-based Programming Exercises

The revision control tool *git* is the de facto standard used to track changes and orchestrate software project development. In its pure form, it has a straightforward command line interface to manage local status repositories and interact with remote repositories. The widespread adoption of Git has led to an enormous centralization around two big players offering back-ends (storing repositories) combined with a web-browser front-end (for browsing and managing repository contents), namely *GitHub* and *GitLab*.

Starting from the winter term of 2023, our institute's programming lectures (Python/C++/C) utilize Git thoroughly by providing all the materials (lectures, lab assignments, and exercise handouts) via git-repositories on our student git server. Additionally, also the exercise hand-in and feedback are organized via git-repositories. Each student submits the solution to each test-based exercise by creating a private git repository on our student git server. After submission, the exercises are tested, and feedback is provided directly via a branch in the submitted exercise repository.

The process described above (test-based exercise submissions, testing/grading using a defined back-end environment, feedback provided in the front-end) is close to what platforms like GitHub or GitLab provide in the scope of so-called *CI/CD pipelines*: Running a sequence of predefined actions for a project (e.g., configure/build/test/deploy) in predefined environments/back-ends and on a regular schedule or based on defined triggers.

Directly adapting such CI/CD pipelines in our educational setting seems attractive but has some downsides:

- 300+ students require non-negligible back-end resources, which implies either self-hosting rather complex projects (GitLab) or signing in for a professional account (GitLab/GitHub)

- communicating adaptions/changes in the workflows to students requires a certain level of understanding of the mechanisms the toolset in use

- it requires the lecturing team to be operationally proficient with the selected toolset or to be dependent on external team members

- it may drag the attention of the lecturing team and the students (more than desired) towards the tools, away from the actual lecture topics

- detecting common issues in the handouts and common patterns in the submissions would require implementing centralized custom reporting and analysis

Utilizing the general git-related infrastructure an institution/university may provide is not feasible due to the noise a large ensemble of repositories owned by a group of potentially inexperienced git users contributes, combined with the need for admin-level privileges for the whole lecture team.

For the reasons mentioned above, we settled with a self-hosted *gitea* instance with a user federation accomplished by a self-hosted *keycloak* instance, which is connected to the user database of our computer lab. The collection/feedback/grading steps are triggered manually and include centralized reporting and analysis routines.


Fig. 1: Illustration of the centralized process of collecting the submission repositories (red), testing the submission based on the references files/tests (green), and producing the final results and feedback (blue).