Eric Saxby
Senior software engineer at Geometer LLC
Eric studied molecular biology at university. His career meandered, though, until he finally made his way to programming.
Now he focuses on the intersection of code and process, using processes such as TDD, agile, XP, and devops to build resilient software as a part of cross-functional teams. He finds it most interesting when code fails, and why.
"I’ve failed at a lot of things in my life. One thing I have been incredibly fortunate to succeed at is connecting with wonderful, empathetic, caring people inside and outside of my career."
Past Activities
Code BEAM V America
11.10 - 11.50
Using Elixir to fight Covid-19
“Luck is what happens when preparation meets opportunity.”
I had the opportunity in 2020 to power Covid-19 contact tracing. Tools built in Elixir provided a data backbone that worked faster, was changed easier, and was more resilient than the systems we replaced.
In this story we’ll meet a cast of characters including Phoenix, Broadway, Oban, as well as Lambda, NodeJS, Ruby on Rails. Some worked well. Some were confusing. Some were both.
Some I would use again.
OBJECTIVE:
The big takeaway that I would like people to take away is that Elixir and other BEAM languages provide a solid basis for resilient, critical infrastructure, perhaps more so than tools which might have better traction in enterprise companies.
AUDIENCE:
Software engineers, engineering managers, software architects. This would be better suited for intermediate to advanced practitioners.
Code BEAM America 2021
13.15 - 13.40
It's made of people
When choosing programming languages, “scalable,” “resilient,” and “performant” are often said. Less often heard: “elegant,” “beautiful,” or (my favorite) “human.” In this talk I contend that code is written not for the benefit of computers, but for humans—and that Erlang/Elixir are not only scalable and resilient, but elegant. Join me on a whirlwind tour of tools, frameworks, and practices that make code by _and_ for humans, whether it’s you in 6 months or one of your customers.
OBJECTIVES
- I recently had an unsettling conversation with a friend, who tried to convince me that I shouldn’t be so excited about Elixir—that being overly invested in any particular toolset put me in danger of getting passed by in the future when the next awesome technology makes everything I do now irrelevant.
- I was incredibly bothered.
- I admit that there will be new technologies invented in the future, and those may eventually supplant our current toolchains. If these eventual new technologies are _better_ for humans and bring people _more_ joy, then that would be a great thing. That would only happen if the creation of these theoretical tools bubbled out of real human needs, and was built to solve human problems. Based on my experience throughout my career, I fear that this will not be the case—that new things will be built, replacing the current ecosystem without bothering to understand that ecosystem or its blind spots.
- I want more people to talk about these things, so that the next best shiny programming thing might actually be built to make human lives better.
AUDIENCE:
- Elixir programmers will hopefully find the talk technically useful, if they want to use linters and static analysis tools haven’t successfully made the jump. Maybe they can point unconvinced coworkers at this talk, and help to convince them.
- I really want to provide a compelling message for language and framework developers.
Code BEAM SF 2019
15.20 - 15.45
Casting against type(s)
Coercing and validating user input can lead to painful code. Casting language primitives is done by Ecto, and storage problems that once required thought are solved by convention—time is stored in UTC, money without floating points. Managing our own types often gets ugly, though: standard vs metric; currency conversion; jsonb.
Extending Ecto is simple. With custom types, we can separate casting from formatting and dramatically improve the readability and maintainability of applications.
OBJECTIVES
The audience will come away with concrete examples of how to improve their applications. Specifically, this talk will help people in making their applications less complicated, easier to understand, and easier to test.
Beginners to Elixir, Phoenix, and Ecto will come away more able to dive into Ecto internals, thinking about principles of code isolation and separation of view concerns from data persistence concerns.
TARGET AUDIENCE
This would be best suited to people who already have experience with both Phoenix and Ecto. It may also appeal to developers experienced with other web frameworks and languages, who are evaluating Phoenix.