I gave my last course of the academic year last week, in the context of a summer school for PhD students (slides are available). A good opportunity to recap and report on my teaching activities. Spoiler alert: almost 300 hours, with a varying audience (from undergraduate students to PhD students, with computer science to data science specialties), different formats (from self-contained 3 hours lessons to the supervision of a running project), and different content (modeling, testing, crafting languages and compilers, mastering variability, etc.).

I started the academic year beginning of september (as it is the norm in France) and it will finish end of august with soutenances/defenses: an exhausting effort with lots of fun and as much as possible relationships with research. So let’s start the journey.

Software development

Since 2012, I have a software development course. The basic goal is to teach skills, methods, and tools for developping software. Instead of delivering some formal courses and then some practical exercices, I used to propose a “running project” where students practice, learn by themselves, and then I help them through intermediate courses (if needs be) and direct interactions. Groups of 4 or 5 students have to realise a software solution on a non-trivial task. This year, the subject was to extract tabular data from Wikipedia (I already blogged about the underlying issues and some solutions). There are three deliverables:

• requirements (after ~1 month): the group has to write a structured document that explains the context, the problem, the envisioned architecture, the testing strategy, the selected technologies (e.g., libraries for parsing Wikipedia), and the planning. The document contains text, figures, and design models: it is a good excuse to practice technical communication, to learn how to interact with a “client” (me) and fuzzy instructions (me again), and to realize that requirements are subject to change (see next points)
• a Github repository (after ~2 months) with code (including tests), a README.md, a screencast: the group has to build a robust software solution. There are common pitfalls:
  • working solution comes too late and there is nothing to show for engaging the discussions and validating the design/technological choices. For instance, a group developed a graphical interface: I didn’t want a GUI!
  • the solution “works” on one or two examples, but fails on other cases.
  • automated tests too late
• an oral presentation with questions: the goal is that students defend their work, clearly explain the problem, their decisions, report on lessons learnt and what skills they have mastered (including soft skills)

What is usually positive with the current format (and this year was not an exception):

• connection with other courses (design patterns, versioning systems, modeling)
• practice of mainstream tools/libraries (JUnit, Maven, logging, git, Github, Trello, etc.)
• the task of justifying the choice of a library
• practice of soft skills
• a good experience showing the difficulty of developing software (very useful for the next courses)
• the running project is actually helpful at the research/innovation level to better understand the difficulties of a problem

What I plan to improve:

• debugging: I under-estimate the importance of this skill. Though I insist a lot on logging and testing, I’m now convinced much effort should be made on explaining the specificity of debugging (which is a bit in-between).
• continuous integration (CI) by default: the idea of testing software is not easy to teach or stated differently: it’s not easy to convince students to test. Besides, some groups used Travis CI, some didn’t – I didn’t force them. It’s certainly a mistake: the activation of a CI is helpful to embrace the testing process and now it’s a common practice after all.
• code review: ideally speaking, I would like more technical discussions on code quality within groups.

Next year, I will change the running project (as usual) and also adapt the organization (e.g., groups may exchange their requirements documents)

Introduction to Software Modeling

The goal is to teach how to “model” in a software context; it’s mainly object-oriented modeling with UML. It’s a difficult yet important course. Modeling is an important skill, perhaps the most important in software engineering.

In this course, I’m “just” supervising practical sessions. There is no computer, except at the very end. We start slowly with basic exercices on UML class/object/use case/sequence diagrams, and then we model a requirement documents written in natural language. We finish with a practical session on the (possible) link between UML, Java, SQL, and even Hibernate: mainly to give the idea of code generation, reverse engineering, and also illustrate the syntax/semantics of UML through a transformation in other languages.

The course is challenging for many reasons:

• only 5 sessions of 2 hours (the theoretical part is only 8 hours and given by Jean-Marc Jézéquel)
• heterogenity in the audience: some students have never been exposed to a modeling language, some students believe they know UML, some students have been exposed to Merise (syntax/semantics differ)
• models are hard to assess: in general quantifying how an (human) abstraction fits a purpose is a hard task. In our context, models are not executable, are not transformed into “something”, and there might well be N solutions (N > 1) to an exercice
• you have to evaluate 150+ students — fortunately I’m not alone, but it’s a time-consuming task

I still think the course is crucial, but it also tends to be frustrating. More space/time is needed to have a more ambitious “module”. How to better explain the relationhsip between models and software (code) is also a general issue. The discussions continue with colleagues (including from other universities) on how to improve this kind of introduction to modeling.

Model-driven Engineering, Software languages, and Variability: A Family of Courses

I’m quite lucky to teach advanced courses that are closely related to my research interests. In fact, I’m teaching this kind of course to different audience; as a researcher in software product line a natural attitude is to reuse and customize material.

First, I’m teaching twice a course about model-driven engineering, spanning software languages, generative programming, and software variability. With Jean-Marc Jézéquel, I’m replicating the course and the audience is composed of students with specialties in either:

• software development (some are working on companies)
• software and management

Their background slightly differ (e.g., no prior knowlege about grammar), but their skills are quite similar. For both courses, we are following the same plan and we’re using the same running project (with some variations in the deliveries): a configurable generator of video variants. Out of a textual specification, a generator produces variants of video (through the assembly of video sequences). We show that we can re-engineer an existing video generator and do much more then. The final outcome is a Web application (e.g., using JHipster).

The course has not changed much since students succeed to master skills like:

• design and creation of a full domain-specific language (with Xtext, Java/Xtend)
• development of interpreters and compilers (thorugh model transformations)
• modeling and management of variability to automatically synthesize custom product
• understanding of contemporary frameworks (e.g., JHipster)

Next year, we will slightly change the content with more emphasis on polyglot programming and better connection with devops tools (e.g., Docker and Kubernetes)

Second, I’m teaching the course to students interested in research (they are typically PhD students or will be in closed future). It is called “The Art Of Domain-Specific Languages: Let’s Hack Our Own Languages!” Here the focus is more about theoretical aspects (e.g., automated reasoning about feature models with SAT solvers) and less technical. Overall, the content is very different.

The running project is also very different. This year the goal of this project was to develop a domain-specific language (DSL) for automatically reasoning about a satisfiability (SAT) formula. Different compilers are to be developed in order to reuse SAT solvers implemented in different languages (e.g., Java, C, Python). Then some advanced topics can be explored (e.g., benchmarking), closed to open research problems/questions.

Language creation and Advanced Programming with Data Scientists

I’m also giving some courses outside University of Rennes 1, in a school mainly devoted to statistics and data analysis/science. Students are in a final year and have a different background — it’s both interesting and challenging.

For the first group, I basically replicated the Wikipedia Matrix challenge. The implementation was a bit different: “only” 4 days of 6 hours, so it was not really a running project but rather a way to make step-by-step progress towards a robust solution. Again, the emphasis was on automatically testing the software solution based on Java. The project also shows the need to extract and clean data in order to make something useful with it — a crucial step in data science.

For the second group, the organization and the objectives were different. Here the goal was to master the creation of a domain-specific language (DSL), including the writing of some compilers. We used Xtext (for the grammar part) and Java (for the implementation of compilers). The theme this year was to design an external DSL for machine learning tasks and compiles into scikit-learn, R, Weka ecosystems. We made, I think, an interesting exercise: several groups have to design the DSL and specify a grammar. We reviewed all solutions (including some discussions and tradeoffs) and I manually “merged” them into an unique and common DSL for the class. Then, the rest of the course consisted in developping different compilers on top of the same DSL. I plan to replay this course in a few months.

Others

“Others” is in fact big:

• I have supervised several students that are part time working (it’s good to keep synchronized with technologies and problems used in industry)
• I have supervised a group of students working on the configurations of the Linux kernel (in the context of the TuxML project that has started two years ago)
• I have supervised groups of students working on a Tux generator, on analysis of chess games, or on video games’ developments
• I’m not talking about some administrative dutties ;-)

Conclusion

I like very much teaching, especially when it’s related to advanced topics and open problems. We are lucky to have this freedom at University of Rennes 1 (and in general in academic I guess). On the negative side, it is clearly too much (almost 300 hours!) and I plan to have a more balanced workload. Next year (read: in 2 months), I want to go a step further with regards to connections of courses with research.

Though I already gave many links, don’t hesitate to contact me if you want some teaching material!