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
I can kill your browser with a simple regexp
Regexps are useful, neat and dangerous. We write them, test if they match and push them to production happy that they solved our problems. And that's where the trouble begins. Uncarefully written regular expression may hang both frontend and backend apps severely harming user experience and causing headaches at debugging stage.
In my talk I'll scare you showing how easy it is to write a dangerous regexp. We'll see why a simple change in a regexp can lead to exponential performance degradation. To do that, I'll describe regexp engines' internals to show how regular expressions are interpreted.
After this talk you will know traps to avoid when using regexps in searching and validations. You will also understand how to optimise a regexp. Finally, you will be aware of the limitations of this tool that almost everybody uses.
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