Maciej Rząsa
Senior Software Engineer at Chattermill
Rzeszów, Poland
Actions
Software engineer with 10 years of experience. He started applications from scratch, dealt with legacy, and extracted services from a monolith and led teams. Strong proponent of diving deep into black boxes, he focuses on distributed systems and database internals. Has a strange hobby of writing regular expressions by hand and discussing their performance. Knowledge-sharing advocate: after work, he's a university instructor, public speaker and meetup organiser.
Bookworm, hiker and history buff (ask him about Napoleon!).
Area of Expertise
Topics
Magical journey through regex engine internals
How does computer know that `^\w+\d$` should match "java8" but not "jvm15"? There must be some magic that allows a computer to recognise that certain strings match the pattern, right? Yes and we, geeks, love learning how such magic works!
Join me on a highly technical journey through the internals of regex engines. First, we will analyse ancient scripts explaining the theory - finite automata and regular languages. Then we will hack through thickets of various regex flavours to arrive at the cave of regular expression engine where we'll explore deep recesses of performance corner-cases. To add a bit of an adventure we'll intentionally fall into a trap of exponentially slow patterns and crash a real app. Finally, we'll read inscriptions left by the survivors of Stackoverflow and Cloudflare outages, both caused by regular expressions.
It's a geeky talk and you'll learn geeky stuff: how a small and neat language of regular expression is implemented and interpreted. But it's not all in vain: you'll be able to optimise the performance of regular expressions and prevent your app from being killed by a badly-crafted regex.
Full text search inside-out
Many developers treat full text search engines as black boxes. You can put data there and run complex queries. You don't want to think about how they work inside, because their complexity are not for mere mortals. However, the algorithms used to implement the search are not that difficult to understand.
In this talk I will show you how the full text search indexes work using short code snippets. I will guide you through text analysis, index building and querying to show you what makes for speed and precision of search engines.
After the talk you'll not only know how the index works, but also how to use it for non-trivial applications.
Make Yourself Immune to the Flaky Test Syndrome
Are you slowed down by rerunning tests failing randomly at CI? Or maybe you see a green test on your machine and your teammate claims it's red on their computer? I have bad news: you may have caught the Flaky Test Syndrome!
Treat this talk as a way to boost your developer immune system against the illness of unpredictable tests. We'll write and analyse seemingly innocent tests that hide the ugly germ of flakiness. From global state through date and time issues to OS-specific differences, we'll cover various cases that make a test non-deterministic.
After this talk you'll be able to write a flaky test (yay!), but more than that. You'll understand what makes a test non-deterministic, how to detect them and what to do to avoid creating them.
Debug Like a Scientist!
Debugging: being wrong, chasing your own tail, venting off. You know it, right?
Don't despair. We can leverage centuries-old practices used by scientists. Observation, hypothesis, experiment - rinse and repeat. This method worked for me in real cases. I'll tell about a non-deterministic test, a nasty production issue, and malfunctioning CI infrastructure.
This talk will show you how to debug without frustration. You'll see practices hardening you for a fight against complex bugs. Finally, you'll know how to scale debugging to the entire team.
API Optimization Tale: Monitor, Fix and Deploy (on Friday)
I saw a green build on a Friday afternoon. I knew should push it to production before the weekend. My gut told me it was a trap. It wasn't a mere superstition about deploys, Fridays, and kittens. I had already stayed late to revert a broken deploy. I knew the risk.
We were extracting a service from a monolithic Rails platform. The initial REST-based internal API crashed even with a fraction of the traffic. We decided to replace it with GraphQL and optimize API usage. This radical change happened in a series of safe, incremental steps. Along the way, we noticed patterns of a performant, robust, and predictable GraphQL API consumer.
Why was it crucial to deploy so late? What gave me the confidence to deploy on Friday? How did we measure the effects of the optimization? And finally, why did I even think of testing on production? To answer, I'll tell you a tale of incremental changes, monitoring, and good old patterns in a new setting. Hope, despair, and broken production included ;-).
Copenhagen Developers Festival 2024 Sessionize Event
Build Stuff 2022 Lithuania Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top