Maciej Kaszubowski
Software Developer at AppUnite, Computer Science student
Past Activities
Code Elixir LDN
10.20 - 10.40
Error-free Elixir
Error handling can greatly increase the complexity of the system. In Elixir, the default way of reducing the error-handling code is to use the "Let it crash!" approach. But there's another way.
In this talk, you'll learn how to eliminate errors by redefining the operation semantics, all supported by real-life examples. By doing so, you'll be able to not only reduce the need for error handling, but also simplify the entire codebase, make it smaller, more testable and easier to understand.
OBJECTIVES
Teach how we can reduce the amount of error-handling code.
AUDIENCE
All Elixir developers - because we're way too used to using error tuples and this should change.
Code BEAM Lite Amsterdam 2018
12.25 - 13.05
The big ball of nouns
All projects tend to get more difficult to maintain with time. Sure, Elixir and Functional Programming can make things much simpler, but after many months, the complexity will creep in anyway. Why is that? The code is just a set of functions, without the complexity associated with Object Oriented languages. So what’s wrong?
You see, the code is not the whole story. Each code has to operate on some data, which tends to introduce a lot of coupling, no matter the paradigm. With real-world examples, I’ll show you how you can reduce this additional complexity by focusing on behaviour, instead of data. You'll learn how to prevent your entities for growing and becoming too coupled. After the talk, I hope you will have concrete ideas on how to make your application more modular, easier to change, test, understand and reason about.
OBJECTIVES
Everybody knows that good boundaries make software easier to work with. In the Elixir community, Phoenix Contexts put a lot of emphasis on this. The problem is finding these boundaries, when everything seems to be so connected together, especially when the project grows.
Maciej wants to show how you can make this boundaries stronger by focusing on behaviour, instead of data/entities. This approach usually leads to much smaller and better isolated parts, which are really fun to work with. To do so, Maciej will show some examples (taken from real-life projects) and describe the mindset he uses when designing the architecture.