This post is the second of two about FOSDEM 2017, a two day conference held in Brussels, Belgium. If you haven't read the first, you can read about it here.

All of the developer rooms (or more of them anyway) were running, which meant more talks and a lot more specialised topics were to be had!

Mutants, testing and zombies

AKA mutation testing with Python and a pinch of Ruby

Alexander Todorov (@atodorov_) - Mr Senko

Todorov introduced mutation testing and discussed the benefits which it can bring. Todorov compared mutation testing to test coverage through unit testing, typically the de facto goal for most projects. If you get your project to 100% coverage then you are golden (its a bit of a fallible ideology) but even at 100% coverage, mutation testing will find bugs in your code.

Mutation testing works by changing the software under test (SUT) to verify the correctness of your test suite. A mutant is create by modifying part of your code (an example could be modifiying if foo == bar:to if foo != bar:). If you tests fail, the mutant is said to have been killed, you successfully caught bad code! If your tests pass, the mutant has slipped by your test suite and is proceeding to eat you and your loved ones… bummer. If your test suite is adequate it should catch all the mutants.

The main idea behind all of this is: KILL THE MUTATNT

Todorov worked on the GTAC library which had acheived 100% coverage but he conintued to discover bugs once he started using mutation testing. Even when the mutation score was 100% there were still bugs in the library. Todorov discovered further bugs running Pylint, which only goes to show that everyone should also be using a linter.

The take away: Mutation testing is cool (but slow), it really improves the quality your testing and in turn the quality of your code. Mutation wont replace unit testing and you still need to have good code coverage and integration testing.

Hacking midi devices with StepPy

A step sequencer in Python

Yann Gravrand (@ygravrand) - Tech Lead/Project Manager at Net-ng

I like programming, I like synths and sequencers, so I felt I had to go to this talk. It was interesting and fun, which is all you can really ask for. After having read about Themaister/libfmsynth I got really excited about buying a synth and trying to make something with it.

Gravrand introduced the topic pretty easily:

  • Synthesizer make sounds
  • Samplers play sound bites (AKA samples)
  • Drum machines make sounds and are step sequencers.

  • Sequencers play a sequence of notes

    • Step sequencers are a special type of sequencer which use subdivisions of time. Many use a 4/4 time signature so will produce 16 steps, which can then play any note or samples in that subdivision.

Gravrand went on to demonstrate the usage of step sequencers in many well know songs and talked through his goals, design and experimentation on this project.

At the end of the talk he performed a few little demos. Woop, woop, music!

What open source and J.K. Rowling have in common

Importance of storytelling in open source projects

Justin W. Flory (@jflory7) - Fedora Project contributor.

Sadly, I missed the majority of this talk. I had wanted to go to another, which had filled up 5 minutes before it was even due to start. I took an early lunch and only then did I realize this one was on.

I need to watch the full version of this talk myself at some point but from where I got in Flory was talking about the importance of letting your community know where to get news about your project from. For large projects it was to aim for a centralized platform for people go to and for smaller projects it is to consolidate: keep things short and sweet. If you are sending an email to a mailing list or when posting a blog. Updating these regularly is important for momentum as well, if people are reading or have subscribed they want to hear the news about the project.

In your project README, you should list where people can find discussions and new updates about the project. Like IRC and blogs.

If you manage a project I recommend watching this talk.


Open Hardware for Your Open Source Software

Arun Thomas - Systems Researcher at BAE Systems R&D ACM?

Thomas gave a tour of RISC-V (pronounced RISC Five)

RISC-V is an open ISA - You create an implementation based on the standard.

Because it is open there are:

  • No fees
  • No contracts
  • No lawyers

The project has a modest goal: "Become standard ISA for all computing devices"

The ISA is designed for Research, education and commercial use. It was designed because reasearchers couldn't really use x86 or ARM to do a research project. Licensing these is costly and takes a long time to get the permission for use. Therefore, several researchers at Berkeley University got together and put together a 3 month project to develop a clean slate ISA. Thus RISC-V

There are different flavor base on included feature sets. For example: RV32I, RV64I, RV128I are the 32 bit, 64 bit, and 128 bit version with Integer mathematics.

SiFive a Berkeley graduated startup designs custom RISC-V chips and currently have two Chips for sale:

  • Freedom Everywhere - 32 micro controller
  • Freedom unleashed - 64 bit general purpose chip (linux)

Asynchronous Python programming with co-routines

A gentle introduction

Ewoud Van Craeynest - Team Lead at Altran Benelux

This talk was a "does what it says on the tin" deal. Van Craeynest discussed why you would want to use asynchronous programming (to avoid threading issues, avoid blocking calls, etc) and a brief history of async programming in python in 3.4 and 3.5.

Van Craeynest went on to talk about some use cases of async and where it can be particularly useful, also on how you can avoid some antipatterns when using async and co-routines.

If you like python and are interested in async programming, I would definitely give it a watch.

Mutation Testing

Leaving the Stone Age

Alex Denisov (1101_debian) - Software Engineer at Backlane

This was another talk about mutation testing but was in the LLVM Toolchain developer room. This had me pretty interested, being able to create mutations in LLVM IR is particularly interesting for my J-O-B job (I'm a Build Engineer at Codeplay, so I'm fairly interested in testing).

Denisov covered some of the history of mutation testing unlike Todorov. Mutation testing came about in the 1970s, Richard Lipton had proposed it as student and Timothy Budd wrote the first known mutation testing tool in 1980.

Denisov went on to talk about the pros and cons of mutation testing before getting onto the meat of the talk; mull.

Denisov created mull a mutation testing tool which operates on LLVM IR, although the only tested target is C++. mull provides smart mutation selection, runtime compilation and is designed to be language agnostic.

There is apparently a lot of work to be done on mull to get it close to prime time: integration with CMake and bash scripts, testing with another language and UX design. If this sounds interesating I'm sure the project would love a helping hand!

End of Day Two

Due to the scheduling I wasn't about to go to all the talks I had wanted to and I left a bit early because there weren't any other talk sI had wanted to go listen to. So I headed off to Bruxelles-Central and grabbed the train to Gent!