Nelson Vides
Self-taught programmer
Programador autodidacta
Kraków, Poland
Actions
Nelson is a child of a multicultural journey. Born in Venezuela to a family of engineers and economists, he grew up in Spain to study pure maths in university and moved to Poland to become a self-taught programmer. After a few years as a C developer in security/telecommunication domains, he's now a BEAM evangelist with an emphasis on performance and security. In his free time he's a sports addict, practising yoga and callisthenics, and also a history fanboy, devouring books every night.
Nelson llega desde un entorno multicultural que en gran medida le define. Nacido en Venezuela en una familia de ingenieros y economistas, crece en España y estudia matemáticas puras, para acabar dejando la carrera, mudándose a Polonia, y aprender a programar de forma autodidacta. Después de unos años como programador en C en campos de seguridad y telecomunicaciones, ahora es un evangelista de Erlang, con un énfasis profesional en seguridad y eficiencia. En su tiempo libre es un adicto a la historia, su hobby por el que no le pagan, y al deporte, su gran lección de disciplina y trabajo duro.
Area of Expertise
Topics
The Actor Model as a Load Testing Framework
Scalability under load. The holy grail of much of a developer's life is that our software survives its beginning. The system went live. Made it to production. Got its first user. But surely, the true test of good software is how it lives up to expectation over its lifetime? After all, you wouldn't say a bridge or building was successful just because the first 100 cars made it across safely. In other forms of engineering, things are load tested under demand either by weight, shocks or overload. As a software developer we should be ensuring SLAs or exploring error conditions under extreme load. But what is “load” in the context of software? And how do we test its many different definitions? In this talk, I will present a relationship made in heaven, the relationship between the actor model and the answer to these questions. I will also introduce you to a library that applies all this knowledge in a ready-to-use dependency.
Building blocks and how to use them: a MongooseIM case study
This is a talk about open source and the community, with MongooseIM as its backbone. MongooseIM is Erlang Solutions’ robust, scalable and customisable messaging server, and using it as a “case study”, I want to tell the story of the evolution of a big and old open source project. I’ll start presenting common Erlang design patterns for a server – the supervision trees, the many processes, the NIFs when they are needed, and most importantly, the ways to preserve a big project manageable and continuously evolving.
I also want to present the libraries that branched off from MongooseIM. In the evolution of a big project, often times you find pieces of code that are not an integral part of the business logic but actually can be generalised and reused for projects potentially very different from your own. I want to present what we found and how, what we extracted, and what we prepared for other people to reuse.
Reimplementing Technical Debt with State Machines
An extensible protocol implementation means that its core code has to be extensible, right? But it also means the core is the first piece of code ever written for this project, and which everything else will depend on, which means, well, highly likely future technical debt. Fast-forward over a decade, and this code might have become not just intractable, but also impossible to understand. What’s next? Incremental improvements, top-bottom or bottom-up, a full rewrite and replug, experiment with a mysterious and not fully tested spaghetti? In our chat’s backend service, we kept coming back to this topic, until one day that looked like it’d be just a boring day, we came up with a prototype for a remorseless full rewrite that immediately looked promising. Based on the OTP’s gen_statem behaviour, we wrote a new core set of extensible rules where everything can gracefully plug in. Let’s solve the quagmire putting together old code, RFCs, state machines and a telemetry-like event mechanism.
gen_statem Unveiled: A Theoretical Exploration of State Machines
Come with me on a journey through the realms of state machines, with the practical brilliance of Erlang’s gen_statem behaviour as our light beam. Building on state machines as a model to reimplement technical debt, we will traverse the intersection of gen_statem practical implementation and the theoretical foundations of state machines. Using real-world application examples, we will go over from the industry beast to the theoretical abyss, revealing the mathematical elegance inherent in state machines and its more powerful automata siblings. Bridging this gap, we will empower Erlang developers to architect solutions that go beyond conventional patterns, with concrete examples and plenty of code to read, providing the attendees with a comprehensive vision to harness the full potential of gen_statem.
A Murder of Crows: actors, instrumentation, and load-testing as part of the TDD cycle
A system performing under load is the holy grail of developers and stakeholders alike, but how do we know our software does actually perform under heavy stress? Come with me on a quick journey through the realms of load testing. I will present you eye-opening ideas about the different kinds of load testing there are and their purposes, how load can be modelled in programming, an extensible tool that can be instrumented to your needs, and most importantly, why –and how!– load test should be part of your TDD cycle.
The limits of my language mean the limits of my world: structures and patterns.
To write good code has no rules set in stone: it’s a mix of art and intuition and a lot of learning. And learning calls for abstractions, for giving names to all the things. Design patterns have given a language and a meaning to many techniques that make our code cleaner, more reusable, and last but not least, more comprehensible.
In the realm of functional programming, abstractions and idioms can seem not only intimidating but maybe even unnecessary, so often in terms of lambda calculus or category theory. Why does a function need to be called a morphism? Why is folding over a list really just a catamorphism? Why do we so often talk about monads when chaining functions? And most importantly: do all these things even help you write better code?
The answer is yes, and if you don’t believe it, this talk is for you.
Code BEAM Europe 2025 Sessionize Event Upcoming
Lambda Days 2023 Sessionize Event
Code BEAM America 2022 Sessionize Event
Nelson Vides
Self-taught programmer
Kraków, Poland
Actions
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