Teaching Reactive Programming

One of the new courses at the TU Delft MSc Computer Science in 2012 was on reactive programming. The students loved this course, and I had a great time too. What was so good about it?

The course was taught by Erik Meijer, creator of the .NET reactive extensions framework Rx. Erik works at Microsoft, Redmond, and has a part time appointment at TU Delft. The lectures thus were packed in two weeks, followed by several student presentations over Skype after Erik had returned to Redmond.

Book: Programming Reactive Extensions and LINQ

The course content included big data, asynchronous operations on observable collections, push versus pull, Pip Coburn’s change function, the role of abstraction, monads, LINQ, coSQL, event processing, schedulers, and the reactive extensions architecture. Course material included Programming Reactive Extensions and LINQ by Jesse Liberty and Paul Betts.

Students subsequently used this understanding of reactive programming to build a cloud-based (Windows) phone app, to be put in the market place. Results include one app to keep an eye on your stack overflow account, and two apps focused on train delays. Some helper libraries developed by the students are now on github, such as a proxy for the Dutch Railways API, and ExchangeLINQ, a LINQ query provider for the Stack Exchange API.

The Engineer as Educator
One thing that made this course special was Erik sharing his extensive experience in API design. He explained the actual tradeoffs he and his team made in the design of Rx — for example when deciding that subscribing to an IObservable should return an IDisposable in order to allow the developer to stop the subscription.

In order to explain his design decisions, Erik naturally made use of his background in functional programming. To answer the student’s questions, he used monads, co- and contravariance, category theory, and trampolines, to name a few. Thus, the course demonstrated how a thorough understanding of programming language theory is a prerequisite for good API design. More than anything, this course motivated students to dive into the theory of (functional) programming.

In the final session, the students presented their apps and their reactive programming skills. The IDEs were opened, and the students experienced what it feels like when a senior engineer like Erik reviews your code. The session took place at 6pm over Skype, with students having pizza and beer, while Erik was having his morning coffee in Redmond.

Final Reactive Programming Presentations

Teaching Testing in Year One

Starting 2013/2014, TU Delft will run a revised curriculum for the bachelor computer science. The software testing course that I have been teaching to 2nd and 3rd year CS students will move from to the (end of) the first year.

This is an exciting prospect. It confirms that testing is not an afterthought, but something that should be built into software development right from the start.

But can it be done? What should freshmen coming straight from high school be taught before they can start with testing? And what should a first year testing course contain?

To build up the required knowledge, the TU Delft curriculum anticipates three pre-testing courses.

  1. In the first, students learn about object-oriented programming, covering topics ranging from simple loops to inheritance, polymorphism, and interfaces. They will even learn a bit about the mechanics of testing their code automatically.
  2. Subsequently, they use the acquired programming skills in a simple project. They learn to work in teams, to write software according to requirements provided by others, and to share their (UML) design diagrams with other team members.
  3. As the third step, they learn about data structures such as linked lists or binary search trees, and learn to use recursion. These courses (object-oriented programming, a project, and data structures), are scheduled for the first three quarters of the first year.

Then in the fourth quarter, a dedicated course on software testing comes in. The course should hook students to innovative forms of testing for the rest of their lives. Here’s what I have in mind for that.

The practical basis will include exploratory testing, behavior-driven development, and the use of testable scenarios to specify requirements. With respect to unit testing, the students will learn JUnit, the use of build tools (maven), coverage analysis, and the use of continuous integration tools (Jenkins). I even hope to get them to understand a mocking framework like Mockito. Students will apply these techniques to a small existing applications (JPacman) which they will have to adapt and test.

The more theoretical basis will be provided by the systematic derivation of test cases from models, such as state machines or decision tables. Furthermore, I’ll elaborate on different adequacy models (beyond statement coverage!) as well as combinatorial testing techniques (e.g., pairwise testing).

This being an academic course, it will also include a critical reflection on the tools and techniques covered. We’ll identify strengths and weaknesses, and see how today’s hottest research aims at addressing these weaknesses.

Well, perhaps this is all too ambitious. I will try, and we will see. Luckily, TU Delft is not the first university to move testing to the first year: Eindhoven is a notable other example, and I am sure there are more (although perhaps not many). “Test early, test often” — learn it early, apply it often.