The birth of the enough-stack developer

Do you remember when people called themselves "webmaster"? Then, the great upgrade arrived: "I'm a full-stack developer". But can we, today, still call ourselves "full-stack"? How much of a stack can we actually fill? In this light talk I try to bring some knowledge about what I call the "enough-stack developer", a new way of thinking about a non-vertical role without becoming a one-man band.

How Asynchronous Batching could save your marriage

It’s late in the evening, you are dressing for a fine dinner with your wife when the phone rings. It’s your boss telling you the application went down and your business is losing money and you need to solve the problem. NOW!

Your monitoring system tells you the CPU load is very high and you soon discover you forgot to put an expensive operation in cache.
“Fixed!“, you say to yourself just before noticing the application went down AGAIN!

Well, my friend, welcome to the Cache Stampede problem!

Since I care about your marriage, I'm going to support you and explain how you can solve this problem leveraging Asynchronous Batching.

Only disclaimer: if I ACTUALLY save your marriage, I decline every responsibility from the troubles this may cause.

Leveraging the Event Loop for Blazing-Fast Applications!

Can the Microtask Queue help you improve your performances by 100x? It turns out, it can!

Some time ago I made my own implementation of signals, capable of updating 300k times the DOM in circa 600ms. Leveraging the Microtask Queue, I was able to bring that number down to 6ms, effectively improving performances by 100x. I wanna share how the Microtask Queue works and how you can leverage the Event Loop to improve performances.

Some time ago I made my own implementation of signals, capable of updating 300k times the DOM in circa 600ms. Leveraging the Microtask Queue, I was able to bring that number down to 6ms, effectively improving performances by 100x. I wanna share how the Microtask Queue works and how you can leverage the Event Loop to improve performances.

How Redis broke our application

A tale about how relying on abstractions broke an application serving thousands of customers every day without us noticing it at all before it was too late.

Semigration

Whenever we are approaching migrations in a system or a software project we usually have an ideal representation of the future aspect of our application in mind.

As soon as we start migrating the system, however, business necessities, technical challenges and changes in already-made decisions make our idealized future further away.

With this mind-provoking talk, I want to talk about a concept I call "semigration", explainable as: a chance to change some migration decisions, converting them into best practices and flows we can add to our daily job, taking opportunities whenever they arise to reduce migration complexity but achieving many of the expected results following the Pareto Principle.

I will provide an example case history of a monolith migrating to a micro-services architecture, stopping some months in the process and moving to a service-based approach, test-oriented development and CI/CD.

How we tested all our APIs without writing a single test.

What do cats and APIs have in common? Apparently, a lot.

Traditionally, Contract Testing involves a meticulous manual effort to identify APIs, document their intricacies, and draft individual contracts before reaping the benefits. Iterative Contract Testing, however, flips the script by leveraging API responses as the cornerstone for generating contracts.

Follow me in this journey about API testing, JSON schemas and many, many cats!

Target audience is everyone working with some legacy code having a hard time testing APIs. Session duration is circa 30-40 minutes.

I partecipated in 9 events (Conferences + Meetups).