2026-GR-WebDevElixirTalk
Torey Heinz
committed Feb 06, 2026
commit 1158d01698834d480e5a651d3ef6a19ca508e488
Showing 1
changed file with
106 additions
and 0 deletions
scratch.md
+106
-0
| @@ | @@ -0,0 +1,106 @@ |
| + | 2026 GR Web Dev Elixir Talk |
| + | |
| + | ## Presenter Bio: |
| + | Torey Heinz is a full-stack developer at Vianet Management and founder of Shopflow, a software company serving small manufacturing businesses. Based in West Michigan, he brings over a decade of experience building web applications—primarily with Ruby on Rails and, more recently, Elixir and Phoenix. After 15+ years with Ruby on Rails, he caught the Elixir bug and hasn't looked back. |
| + | |
| + | |
| + | ## Presentation Title: Elixir in the Real World: A Practical Introduction |
| + | |
| + | Curious about Elixir? This session offers an introduction to the language powering systems at Discord, Pinterest, and Pepsi. We'll start with the "why"—a brief history of Erlang, the BEAM virtual machine. Then we'll explore what makes Elixir uniquely powerful: pattern matching that transforms how you write functions, lightweight processes that make concurrency approachable, and fault tolerance baked into the foundation. |
| + | |
| + | Then we’ll explore some real-world code examples: sending over half a million personalized marketing emails, managing TCP connection pools to Verisign's domain registry, and building internal admin tools that span multiple sites. |
| + | |
| + | ## Proposed Scope & Sequence |
| + | |
| + | **Total time:** ~45-50 min presentation + 10-15 min Q&A |
| + | |
| + | --- |
| + | |
| + | ### Part 1: Why Elixir? (10-12 min) |
| + | *Hook them with the "so what" before diving into syntax* |
| + | |
| + | **1.1 The Origin Story** (3 min) |
| + | - Erlang: Built by Ericsson in the 80s for telecom switches that couldn't go down |
| + | - The BEAM: A virtual machine designed for massive concurrency and fault tolerance |
| + | - Elixir: José Valim (Rails core team) brought modern syntax and tooling to the BEAM in 2012 |
| + | |
| + | **1.2 Who's Using It** (2 min) |
| + | - Discord: Scaled to millions of concurrent users |
| + | - Pinterest: Notification system |
| + | - Pepsi: Real-time systems |
| + | - The famous "2 million WebSocket connections on a single server" demo |
| + | |
| + | **1.3 Why It Matters for Web Apps** (5 min) |
| + | - *Your key point:* Web apps are I/O bound—waiting on databases, APIs, user input |
| + | - Most languages: threads are expensive, blocking is painful |
| + | - Elixir: Lightweight processes (not OS threads) make concurrency trivial |
| + | - Real example: Vianet migrated from AWS to Render, moved services to Elixir → faster sites, fewer resources, **$10k/month savings** |
| + | |
| + | --- |
| + | |
| + | ### Part 2: The Language (15-18 min) |
| + | *Show what makes Elixir different—not a full tutorial, just the "aha" moments* |
| + | |
| + | **2.1 Pattern Matching** (6-8 min) |
| + | - Not assignment—it's matching |
| + | - Function heads: same function name, different clauses based on input shape |
| + | - *Your story:* "At first it didn't click, then I realized you can write incredibly clear code where each function clause handles one specific case" |
| + | - Quick code example: handling different API response shapes |
| + | |
| + | **2.2 Processes & Concurrency** (5-6 min) |
| + | - Processes are cheap (can spin up millions) |
| + | - Message passing instead of shared state |
| + | - "Let it crash" philosophy—supervisors restart failed processes |
| + | - Quick visual: supervision tree concept |
| + | |
| + | **2.3 LiveView & Livebook** (4-5 min) |
| + | - **LiveView:** Real-time UI without writing JavaScript |
| + | - WebSocket connection (no HTTP overhead) |
| + | - Client sends just the event + changed data |
| + | - Server sends back only the HTML diff |
| + | - Result: tiny payloads, instant updates |
| + | - **Livebook:** Interactive notebooks for Elixir (great for learning, demos, data exploration) |
| + | |
| + | --- |
| + | |
| + | ### Part 3: Real-World Code (15-18 min) |
| + | *This is where you prove the concepts with battle-tested examples* |
| + | |
| + | **3.1 Email Marketing System** (6-8 min) |
| + | - The challenge: 500k+ personalized emails |
| + | - Supervision tree with a rate limiter—how it works |
| + | - Concurrency: processing emails and webhooks efficiently |
| + | - Bonus: Wiring up TinyMCE with LiveView JavaScript hooks |
| + | |
| + | **3.2 Domain Registry Integration** (4-5 min) |
| + | - Connecting to Verisign via TCP |
| + | - Connection pooling with the BEAM |
| + | - Why Elixir makes this cleaner than other approaches |
| + | |
| + | **3.3 Internal Admin App** (4-5 min) |
| + | - Multi-site management |
| + | - LiveView for real-time admin dashboards |
| + | - How quickly you can build interactive tools |
| + | |
| + | --- |
| + | |
| + | ### Wrap-up (2-3 min) |
| + | - Resources to get started (elixir-lang.org, Livebook, Phoenix docs) |
| + | - Your contact info / open to questions |
| + | |
| + | --- |
| + | |
| + | ## Notes on Flow |
| + | |
| + | The structure now follows your promo exactly: |
| + | 1. **Why** → History, BEAM, companies using it |
| + | 2. **What makes it powerful** → Pattern matching, processes, fault tolerance |
| + | 3. **Real-world examples** → Email, Verisign, admin tools |
| + | |
| + | Does this sequence feel right? A few questions: |
| + | |
| + | 1. **Livebook demo?** Are you planning to show Livebook live, or just mention it? A quick live demo could be a nice interactive moment. |
| + | |
| + | 2. **Code depth:** For the real-world examples, are you thinking actual code on screen, or more conceptual with diagrams? The supervision tree / rate limiter could go either way. |
| + | |
| + | 3. **The $10k savings story**—do you want that in the opener as a hook, or save it for later as proof? |