Zach Daniel
VP of Engineering @ Remedy Meds, Creator of Ash Framework
Greensboro, North Carolina, United States
Actions
Zach is a software engineer and leader with ~13 years of experience with production Elixir applications, building large and ambitious software, and scaling software teams. He is the creator of Ash Framework, a resource-oriented declarative design framework for Elixir, and VP of Engineering at Remedy Meds. He has a passion for declarative design, functional programming, and contributing to the open source community. When not programming, he enjoys spending time with his wonderful wife, pets, friends and family.
Area of Expertise
Building on Bedrock: Elixir's Fundamental Design Advantage
I've been writing Elixir for over 10 years, and have consistently seen teams deliver software to a higher degree of quality, at a higher rate of speed, and at significantly lower cost to build and to operate than with any other toolchain. Elixir is still a "niche" language, and lacks the centralized corporate backing that many other ecosystems have. Without the same community mass and financial backing, how is it possible for Elixir to be so productive and effective?
As a framework author, I often deal with high level abstractions and business logic. In this talk, however, we will peel back the covers to illustrate the small design choices underpinning the Elixir programming language that manifest in exponentially more efficient and understandable applications. Together, we will see how the core design choices in any system are multiplied and magnified when we build on top of them.
Most importantly, we will come to understand the fundamental reason that Elixir manages to be so productive and effective: We aren't building on sand.
Model the work: Real Life workloads with Ash & Oban
At small scale, you can get away with using `schedule_at` with. When you have a large team, millions of jobs per day, hundreds of complex workflows, that approach breaks down.
In this talk, we look at real production workloads: webhook ingestion and delivery, reminders and notifications, appointment scheduling, order shipment, and fulfillment. These are long-lived, time-based workflows that need to behave predictably across retries, deploys, crashes, and changing requirements.
The core idea is simple: your jobs table is not a domain model. If a piece of work matters, it should exist as application state. A reminder isn’t an Oban job, but a Reminder that moves from unsent to sent. A shipment isn’t a background task, it’s a Shipment with a lifecycle.
We’ll walk through how we model this kind of work using Ash resources, AshStateMachine, and AshOban. This approach comes with huge benefits, as well as a few sharp edges & foot guns that we'll learn to sidestep.
Along the way, we’ll look at how this approach makes systems easier to reason about, safer to retry, and dramatically easier to refactor as requirements evolve, without losing the operational reliability you need at scale.
Ash Framework: The Power of Declarative Design
Modern applications are complex. They get messy and resistant to change quickly. As programmers, one of our most important and difficult charters is taming those complexities. Declarative Design offers a philosophy to help us do exactly that.
We begin by looking at a hypothetical future, where applications are understandable, with powerful and flexible layers derived and configured directly from our model. Next, we dive into the philosophy of Declarative Design, illustrating how it can be leveraged to improve our current patterns.
We tie it all together by showing how Ash Framework brings this philosophy to the forefront and how we are well down the path of bringing about the future we discussed at the outset. We show how Ash leverages the philosophy of Declarative Design to provide consistency, flexibility and power.
Finally, we talk about what the future holds for Ash, and how it will continue to grow to provide a solid foundation for any Elixir application.
Ash: The Story of a Function
Imperative code imposes artificial constraints. Once you see this in action, you can't unsee it. This is one of the fundamental ideas behind Ash Framework.
In this talk, we explore how a function evolves over time, and the kinds of issues that you face as you add behavior to your applications. In Phoenix, this most commonly presents as writing "contexts", which contain the functions required for building your application and business logic. Ultimately, Phoenix contexts do not have opinions on how you structure your application, instead delegating responsibility for designing and organizing your application to the developer.
This is where Ash comes in. Ash provides the structures for building, organizing and evolving your application over time to avoid the common pitfalls faced by developers every day. In this way, Ash acts as the missing domain layer for your Phoenix application (or any application). We'll go over these structures and how they address the issues inherent in composing applications out of imperative code.
Finally, we'll end with an update on the status of the project, what's new and what's coming. We've got lots in store, and can't wait for everyone to see it!
A Letter From Ourselves
Elixir has a storied past—but what does its future hold? In this session, we won’t be unveiling new features or delivering a roadmap. And yet, somehow, the future makes an appearance.
Expect familiar ideas in unfamiliar contexts, surprise guests, and a few predictions that may or may not be from your timeline. It’s part retrospective, part speculative fiction, and all Elixir. Buckle up.
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