Software has become increasingly complex as it is constructed from a multitude of software components. In many cases the identification of these components are hidden as they are included through implicit dependencies. Without fully understanding the dependencies of your product it is not possible to understand the current vulnerability status of your software product or system.
In the past 12 months, there has been an increasing focus on the use Software Bill of Materials (SBOMs) as a key artefact to be delivered with a software product; it will be mandated for all software products in some markets later in 2022. SBOMs which were initially developed to capture the inter-dependencies between components (the focus was on capturing the different types of open source licences used within a product) but with the latest evolution, tracking of vulnerabilities within a product can now be performed.

This talk will introduce the SBOM concept and show how Python and its ecosystem can be used to create, manage and use SBOMs as part of your development pipeline.

How python is supporting the growing need for Software Bill of Materials

Anthony Harrison

Using Python to  manage Software Bill of Materials

If real life was a superhero movie, we’d have all the ingredients needed for a hero’s rescue. So many “AI” algorithms are being applied to EU education, employment, and public safety systems that you might wonder if the TV series “Black Mirror” is fiction or a blueprint for nefarious actors. Luckily, there are codes to keep dystopia at bay, whether from the fictional Justice League or from real-life courts of justice. This talk discusses both, and is aimed at software engineers, architects, designers, testers and product/project managers who want to slow the Automation of Everything, but don’t know how.

Ever get the feeling we're living in an episode of Black Mirror? You're not alone! Dr Nakeema Stefflbauer will explore the "Automation of Everything" and the importance of keeping Black Mirror safely in the land of fiction.

Dr. Nakeema Stefflbauer

Dodging AI Dystopia: you can't save the world alone

Come _hear_ about how to play with audio in only a couple lines of Python!

Python can do (nearly) anything, but using Python to work with audio has always been a complicated and messy affair. In this talk, we'll be going through how digital audio works, how Python can be used to play with audio data, and how a new library - Pedalboard - can help. Pedalboard is a simple, fast, and performant library for doing common audio tasks in Python, including applying effects, using VSTs and audio plugins, and encoding/decoding various audio formats.

Ever wanted to play with audio in Python? Come check out Pedalboard, a library that brings the power of a digital audio workstation into your Python code.

Digital audio has been around for 40 years, but working with audio data can still be complicated, especially in Python. In this talk, we'll talk about how digital audio works from the ground up (from sounds, to bytes, to files), how you can use Python to do a bunch of really neat things with audio, and how a new Python library - Pedalboard - helps make working with audio much easier.

Ever used a digital audio workstation (DAW) like GarageBand, Ableton Live, Logic, or Pro Tools? Today's musicians use DAWs as instruments in themselves. But what if you want to combine the power of a DAW with the flexibility of writing your own code?

Pedalboard was built to fill this niche: to pull the power of a DAW into your Python code. Pedalboard makes it easy to build and apply audio effects, read and write audio files, and load audio plug-ins ("VSTs") without any complicated dependencies or frameworks. Just `import pedalboard` and go!

Peter Sobot

Working with Audio in Python (feat. Pedalboard)

Have you ever found yourself coding variations of a loop construct where fragments of the loop code were exactly the same between the variations? Or, in an attempt to factor out these common parts, you ended up with a loop construct containing a lot of conditional code for varying start, stop, or selection criteria?

You might have felt that the end result just didn't look right. Because of the duplicated parts in your code, you noticed that the code didn't conform to the DRY (_Don't Repeat Yourself_) principle. Or, after an attempt to combine the variations into a single loop, with consequently a lot of conditional code, your inner voice told you that the resulting code had become too complex and difficult to maintain.

This talk will show you a way out of this situation. It demonstrates how you can create a **generator function** that implements only the common parts of your loop construct. Subsequently you will learn how you can combine this generator function with distinct hand-crafted functions or building blocks from the standard library `itertools` module or the `more-itertools` package.

As an example, imagine you'd need to implement some varying functionality based on the Fibonacci sequence. This talk shows you how it would look like before and after you've refactored it into a **pipeline of generators**.

After having seen this pattern, you will recognize more quickly when this kind of refactoring helps you to create more maintainable and more Pythonic code.

Have you ever found yourself coding variations of a loop construct without knowing how to cleanly factor out the common parts? This talk will show you a way out: refactor into generator functions!

Jan-Hein Bührman

When to refactor your code into generators and how

Function-as-a-Service (FaaS) platforms are one of the key service offerings for any cloud provider. To provide strong isolation, the functions are run inside heavy-weight virtual machines (and within containers inside those for orchestration reasons). Consequently, such instances take too long to boot and so are kept on all the time, even though the functions only receive requests intermittently. The end result is that current FaaS platforms are much less efficient than they could be.

We will introduce a radically novel way to build FaaS platforms based on Python and the Unikraft Linux Foundation open source project (www.unikraft.org). Unikraft is a toolkit for building fully specialized, cloud-ready virtual machines called unikernels targeting a single application . Using Unikraft we can construct extremely specialized, Python-based unikernels that use only a few MBs to run a boot in 10s of milliseconds, allowing us to bring VMs up as a request to a function comes in, and to shut it down (or suspend it) afterwards. The result: a Python-based FaaS platform that is significantly more efficient and cheaper to operate than existing offerings.

In the talk we will provide an introduction to Unikraft, how Python is built on top of it, a full description of the FaaS platform and a short demo.

Building an Extremely Efficient, Just-in-Time, Python FaaS Platform with Unikraft

Unikraft [1] is a unikernel (specialized virtual machine) project. Unikraft is able to target a specific application (e.g., a web server such as NGINX) and transparently build an entire software stack, from the operating system all the way up to systems libraries, that includes only the parts that the application needs and nothing more. Such specialization results in extremely short boot times (a few milliseconds compared to hundreds or thousands for Linux VMs), small image sizes and memory consumption (e.g., a few MBs vs. hundreds of MBs) and a minimal attack surface, to name a few benefits. The short boot times also allow us to bring Unikraft VMs up just-in-time, as a request for a service arrives, and to bring the instance back down (or suspend it) when the request is over, allowing for even greater efficiency.

In addition, Unikraft images are single address space: in cloud environments strong isolation is provided by the hypervisor, so for single application/single tenant VMs it does not make sense to have a kernel/user-space divide. The end result is higher efficiency in performance, with Unikraft yielding noticeably higher throughout than Linux [2].

Regarding application support, we have put great effort towards making Unikraft as POSIX compatible as possible. Unikraft provides a syscall shim-layer and support for the musl libc, allowing us to run unmodified versions of Python. 

In terms of orchestration, we have integrated Unikraft with major frameworks such as Kubernetes and Prometheus. This, along with extensive debugging facilities should make Unikraft easy to both use and develop for.

[1] https://unikraft.org/
[2] https://dl.acm.org/doi/10.1145/3447786.3456248 (best paper award)

Felipe Huici

Alexander Jung

Building a Just-in-Time Python FaaS Platform with Unikraft

Writing automated tests takes time. As developers, we are constantly pressed by management to deliver early, which means we are tempted to skip writing some of the tests. Of course, in the long term, the time needed to write tests is paid off.

But how much of our time do we spend in order to write tests? Is it half? Is it three-quarters? This can be difficult to measure, particularly if we are using test-driven development, because in that case writing tests is integrated in the process of writing code.

While I like test-driven development, I can only practice it when I have a good idea of what code I want to write. But sometimes my idea of how to approach the problem at hand is quite vague and I experiment a lot. In these cases, I write the code first and the tests after that. 

In one such case I first finished the functionality I was developing and proclaimed it "beta". I then went on to write the unit tests for it. As a result, I have a clear idea how much time I spent writing documentation and main code, and how much I spent writing tests. In this talk I examine the implications of all this.

I measured the time spent on writing tests vs. the time I spent on everything else for a part of an ongoing project. Here are the results and the implications.

Antonis Christofides

How much time does it take to write tests? A case study

A playful exploration of the similarities and differences between music and code. What could coders learn from musicians, especially when it comes to learning, training and mentoring? (A personal perspective from someone who has been a professional musician, a professional teacher, and a professional coder.)

Music and Code - a playful performance pondering programming.

Learning to code requires a long term investment of time and effort to acquire a set of skills, theory, knowledge and experience in order to effectively make software. Learning to play an instrument requires a long term investment of time and effort to acquire a set of skills, theory, knowledge and experience in order to effectively make music.

I will compare and contrast certain aspects of the worlds of code and music and will explore questions such as: what would music lessons look like if we taught music like we teach coding (and vice versa)? Who are the virtuoso coders we should celebrate as role models? (And why?) How do musicians and coders sustain AND develop their cultures across generations? Is coding an art? Is music a science? What could folks do to cultivate their practice of music and code? How can we tell if someone is an "expert", and should we trust their advice?

Most of all, it'll be practical, fun and thoughtful.

I hope to make a space for some interesting and stimulating ideas. Then we can all explore them together in the corridor track.

Using Python to manage Software Bill of Materials

Abstract

The speaker