Johnny Winn
Host of the Elixir Fountain podcast
The renaissance man from Jacksonville, Johnny embarked on his computing curiosity during the eighties on a Commodore 64. However the road leading toward software craftsmanship has diverged down many paths. From musician to electrical engineer, chef to software developer, rugby player to local politician, the twist and turns have provided a wide range of experiences that have helped to shape him.
Johnny Winn hosts and runs the popular Elixir Fountain podcast.
Past Activities
Code Elixir LDN
14.25 - 14.45
Hold My State: The Problems of Process State
OTP processes are a powerful ally when constructing your applications but like all good friends they can convince us to do some crazy things. How we implement our processes and the roles they play can have a dramatic effect on the life of our applications. What impact will the choices we make have? How much state is too much? Can our processes get in over their heads? Hold my state and we'll see!
OBJECTIVES
Examine the good, bad, and ugly ways processes can behave and look at the tools available to us to better diagnose problems.
AUDIENCE
Anyone building OTP applications.
Code BEAM SF 2020
14.35 - 15.20
LiveView of Evolution
It's alive! Well, a simulation of life at least but how will we keep our eyes on the process? What happens as our processes feed and reproduce? What genetic algorithms & instincts drive our population? What happens when we introduce a virus? Too soon? It's all apart of the evolutionary process as we watch our processes feed and reproduce right before us. This talk will cover Phoenix LiveView, genetic algorithms, and how we use OTP to tie it all together so come along and watch as this complex world unfolds live!
THIS TALK IN THREE WORDS
Cool
Process
Tricks
OBJECTIVES
Introduce LiveView to monitor processes
TARGET AUDIENCE
Everyone interested in LiveView & simulation with processes
Code BEAM STO 2019
14.40 - 15.25
Just Delete It
Are we creating big balls of mud within our applications?
Is an abstraction necessary or is it going to couple the code to the implementation?
Can I achieve code isolation without overcomplicating?
The challenge is to reach the nirvana of simple code isolation verse complex code abstraction. But is it realistically obtainable? The challenge is set: implement patterns that will allow us to just delete & rewrite code in days instead of weeks, weeks instead of months, and months instead of ... version 2.
OBJECTIVES
- Cover abstraction patterns that over-complicate code
- Apply isolation patterns that will isolate code and functionality
- Demonstrate how we can consistently find "red flags" and stop the complexity before it starts
TARGET AUDIENCE
This talk will appeal to all levels.
The "ball of mud" issues seem to appear at every level.
Johnny recently said that "all code is perfect at the first commit." The trick is how to prevent major rewrites with the subsequent commits.