8 posts
Plantronic handled durable SAP imports with Elixir, Oban, Ecto, and its existing PostgreSQL database inside the same application that owned the planning rules.
#elixir · #oban · #plantronic · #integrations · #sap
Why Plantronic's planner and team rules had to constrain data access below the interface.
Plantronic needed domain labels that could change without a release. I kept compiled Gettext catalogs for application copy, added a database fallback for operational vocabulary, and used ETS and PubSub to make edits visible.
Plantronic needed to display details from two systems without importing their entire schemas. JSONB made that flexible, but behavior rather than convenience decided what became part of the task model.
Plantronic's routing policy was unfinished. A small rule language and manager UI let client and developer work in parallel. The same routing model still runs today.
#plantronic · #software-architecture · #domain-modeling · #elixir
Realistic seed data gave Plantronic a fast local reset, useful demos, and a safe way for colleagues to contribute without production data access.
An unfamiliar on-premise machine looked like a constraint. It became a test of whether years of infrastructure work could collapse into one repeatable deployment.
#plantronic · #infrastructure-as-code · #terraform · #kubernetes · #elixir
How an early rename helps define the boundary of long-running software projects.