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
Debugging: Better Habits, Less Frustrations
Some bugs haunt the team for weeks. Recurring, hard-to-track, embarrassing. They ruin the road maps, kill morale and undermine stakeholders' trust. If you ever seen them, you know the nightmare.
Don't despair - I've found a way to deal with them efficiently. A mix of methods and habits used by scientists is the way out of debugging horror. It's a loop of observation, hypotheses and experiments, enhanced with practices used by scholars. It makes debugging more predictable, less frustrating and much faster. I'll share how they helped me in three case studies: fixing a non-deterministic test, stabilising CI infrastructure and resolving a recurring production downtime.
This talk will enhance your programming toolbox for the hardest bugs. Not only this - but you'll see how to scale effective debugging to the entire team. Last but not least - you'll know a set of habits to share with your fellow engineers and help them step up the debugging game.
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.
Debugging without frustration
Debugging: hours without visible progress, team chasing their own tail, people venting off. You've been there, right?
Don't despair, there is a cure for that. The methods used by scientists for ages can make debugging manageable. Observation, hypothesis, experiment - rinse and repeat. I'll show you how we used them in real cases: a non-deterministic test, a nasty production failure and a malfunctioning CI infrastructure.
This talk will show you an effective debugging method that scales to the whole team. Not only that - you'll see practices that will harden your team for fights against the toughest bugs and make debugging a frustration-free activity.
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 Upcoming
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