Magda Stożek's Speaker Profile @ Sessionize

Get more clarity with opaque types and Iron in Scala 3

Types are a programmer's best friend. In the pursuit of a perfect world, we try to model our domains in such a way that the type system makes incorrect data impossible. In Scala 2, we have tools like type aliases, value classes or Refined Types. In Scala 3, there's something new for this purpose - opaque type aliases. What do they bring to the table? Will they make our life easier? Do they have any drawbacks? Join this live demo session to learn all that and add this new tool to your modelling toolbox! As a bonus, we'll also talk about the state of ecosystem for accurate domain modelling, and see how to go even further with the Iron (https://github.com/Iltotore/iron) library.

Get more clarity with opaque types in Scala 3

Types are a programmer's best friend. In the pursuit of a perfect world, we try to model our domains in such a way that the type system makes incorrect data impossible. In Scala 2, we have tools like type aliases, value classes or Refined Types. In Scala 3, there's something new for this purpose - opaque type aliases. What do they bring to the table? Will they make our life easier? Do they have any drawbacks? Join this live demo session to learn all that and add this new tool to your modelling toolbox!

Property-based testing - let your testing library work for you

Don't ask what you can do for your testing library, ask what it can do for you! So what can it do? It turns out that much more than displaying a nice green and red report. What if we make the library generate the test data? And while we're at it, maybe it could also think of the edge cases for which our code is wrong? Oh, and when it finds them, it should simplify them a bit before returning to us, so that we can quickly identify the root cause of the problem. And repeat that a thousand times, just to be sure. Sounds good? That's exactly what property-based testing has to offer. I'll show how to get started with this kind of testing, using jqwik (https://jqwik.net/) as an example. But isn't it all too good to be true, surely there's some fine print? Of course there is. I'll cover that as well.

Property-based testing - let your testing library work for you [lightning talk]

Don't ask what you can do for your testing library, ask what it can do for you! So what can it do? It turns out that much more than displaying a nice green and red report. What if we make the library generate the test data? And while we're at it, maybe it could also think of the edge cases for which our code is wrong? Oh, and when it finds them, it should simplify them a bit before returning to us, so that we can quickly identify the root cause of the problem. And repeat that a thousand times, just to be sure. Sounds good? That's exactly what property-based testing has to offer. I'll show how to get started with this kind of testing, using jqwik (https://jqwik.net/) as an example. But isn't it all too good to be true, surely there's some fine print? Of course there is. I'll cover that as well.

Say goodbye to implicits - contextual abstractions in Scala 3

Have you ever been confused by implicits in Scala? I most certainly have. I struggled to understand them at the beginning of my Scala journey, and to this day I trip over them regularly. It doesn't help that one keyword can be used for many different things - defining Implicit parameters, implicit conversions, or type class instances. And sometimes it's so frustrating when your code doesn't compile because you can't remember the magical implicit import incantation that is needed (the problem also known as "why does it work fine in that other file, but not here?!").
Scala 3 addresses a lot of the tricky bits in the language to make it clearer and easier to use, and luckily, implicits have also undergone a redesign. Well, to be precise... they're gone. But in their place, we're getting language constructs that do one thing and do it well. Please join me in welcoming the new keywords: "given" and "using", as well as context functions and extension methods. They're the new kids on the block to define our contextual abstractions, and they're here to make our code more expressive and easier to understand. Let's see them in action.

What I wish someone told me 10 years ago - Be loud about what you don't know

If I were to travel back in time and give some advice to my younger self, what would that be? Become friends with your impostor syndrome, because it's part of you and it's not going away ;) But if you learn to listen to it in a different way, it can be your strength - speaking up about what you don't know can actually help you make your team better, no matter how junior or new to the project you are.

Speaker

Magda Stożek

Actions

Links

Area of Expertise

Topics

Sessions