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.

Past Activities

Eric Saxby
Code BEAM V America
10 Mar 2021
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.



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.


Software engineers, engineering managers, software architects. This would be better suited for intermediate to advanced practitioners.

Eric Saxby
Code BEAM SF 2019
01 Mar 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.


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.


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.