https://kevinpeterson.me Kevin Peterson's blog Thu, 12 Feb 2026 01:12:43 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed https://kevinpeterson.me/favicon.ico https://kevinpeterson.me All rights reserved Kevin Peterson 2026 https://kevinpeterson.me/blogs/a-practical-look-at-the-pipeline-pattern-in-python https://kevinpeterson.me/blogs/a-practical-look-at-the-pipeline-pattern-in-python Tue, 09 May 2023 00:00:00 GMT kevinpetersoncr0930@gmail.com (Kevin Peterson) https://kevinpeterson.me/blogs/building-a-resilient-background-worker-in-elixir https://kevinpeterson.me/blogs/building-a-resilient-background-worker-in-elixir Wed, 11 Dec 2024 00:00:00 GMT Logger.info("Job completed successfully") {:stop, :normal, job} {:error, reason} -> Logger.error("Job failed: #{inspect(reason)}") {:stop, reason, job} end end defp perform(_job) do if :rand.uniform() > 0.7 do :ok else {:error, :random_failure} end end end ``` ### Key Ideas - The worker does its job and exits - Success and failure are explicit - No retry logic inside the worker --- ## Step 2: Supervise the Worker Now we introduce a supervisor to manage worker lifecycles. ```elixir defmodule MyApp.WorkerSupervisor do use DynamicSupervisor def start_link(_) do DynamicSupervisor.start_link(__MODULE__, :ok, name: __MODULE__) end @impl true def init(:ok) do DynamicSupervisor.init(strategy: :one_for_one) end def start_job(job) do spec = {MyApp.Worker, job} DynamicSupervisor.start_child(__MODULE__, spec) end end ``` ### Why This Works Well - Each job runs in isolation - One crash doesn’t affect others - Restart behavior is consistent and observable ## What Happens When a Job Fails? When `perform/1` fails: - The GenServer crashes - The supervisor handles cleanup - Logs clearly show what happened No silent retries. No hidden state. No cascading failures. This is one of the biggest advantages of building background work directly on the BEAM. --- ## When I Use This Pattern This approach works well for: - API-triggered async work - Data enrichment - External service calls - Internal tooling and pipelines I wouldn’t use it for: - Massive job queues - Exactly-once delivery - Persistent retries without storage Elixir gives you primitives — not opinions. ## Final Thoughts Elixir didn’t just give me better concurrency. It changed how I think about **failure as a design input**. Small processes. Clear supervision. Predictable recovery. When production gets boring, you’re doing it right. --- --- ]]> kevinpetersoncr0930@gmail.com (Kevin Peterson) https://kevinpeterson.me/blogs/deploying-javascript-applications https://kevinpeterson.me/blogs/deploying-javascript-applications Wed, 04 May 2016 00:00:00 GMT kevinpetersoncr0930@gmail.com (Kevin Peterson) https://kevinpeterson.me/blogs/making-generated-javascript-inline-caching-friendly-in-rescript https://kevinpeterson.me/blogs/making-generated-javascript-inline-caching-friendly-in-rescript Sat, 22 Aug 2020 00:00:00 GMT loBits + hiBits ``` Generated JavaScript looks like: ```js var value = { lo: 32, hi: 33 } function sum(param) { return param.lo + param.hi } ``` Why this works well: - Object shapes are consistent - Property names are stable - Debuggers show meaningful structures --- ## Variant Encoding (Tagged Unions) Variants are encoded using different strategies depending on whether they carry data. ### Variants Without Payload These compile to simple numbers. Rescript: ```ocaml type color = | Red | Blue | Green ``` Generated JavaScript: ```js Red = 0, Blue = 1, Green = 2 ``` This representation is compact and fast. --- ### Variants With Payload Variants that carry data compile to objects with a stable layout. ReScript: ```ocaml type tree = | Empty | Node(tree, int, tree) let t = Node(Empty, 3, Empty) ``` Generated JavaScript: ```js var t = { TAG: 0, _0: 0, _1: 3, _2: 0 } ``` Each object: - Uses the same fields - Preserves stable shapes - Works well with inline caching --- ## Optimized Variant Encoding (Single Payload) When only one variant carries data, ReScript skips the TAG field entirely. ReScript: ```ocaml type list = | Nil | Cons(int, list) let xs = Cons(1, Nil) ``` Generated JavaScript: ```js var xs = { _0: 1, _1: 0 } ``` This reduces object size while keeping pattern matching predictable. --- ## List Encoding for Debugging Lists can also be encoded using clearer field names: ```ocaml { hd: 1, tl: { hd: 2, tl: { hd: 3, tl: 0 } } } ``` This improves debuggability while remaining efficient for JavaScript engines. --- ## Polymorphic Variants Polymorphic variants also generate stable shapes. ReScript: ```ocaml let v = `hello(3) ``` Generated JavaScript: ```js var v = { HASH: someNumber, VAL: 3 } ``` These shapes remain consistent and engine-optimizable. --- ## Final Thoughts ReScript’s approach to encoding data is about more than performance. It also improves: - Debugging experience - Predictability - Confidence in refactors By combining strong typing with JavaScript-friendly output, ReScript produces code that runs fast and stays understandable. This balance is what makes ReScript especially appealing for long-lived, production frontend systems. ]]> kevinpetersoncr0930@gmail.com (Kevin Peterson) https://kevinpeterson.me/blogs/practical-css-tips-for-hotwire-apps https://kevinpeterson.me/blogs/practical-css-tips-for-hotwire-apps Sun, 02 Apr 2023 00:00:00 GMT kevinpetersoncr0930@gmail.com (Kevin Peterson) https://kevinpeterson.me/blogs/understanding-to-a-vs-to-ary-in-ruby https://kevinpeterson.me/blogs/understanding-to-a-vs-to-ary-in-ruby Mon, 06 Feb 2023 00:00:00 GMT “If someone asks for an array, here’s how to represent this object as one.” Ruby will only call `to_a` when **you explicitly ask for it**. Example: ```ruby range = (1..3) range.to_a ``` Result: ```ruby [1, 2, 3] ``` This is safe and predictable. Nothing magical happens behind the scenes. In Rails, you’ll see `to_a` used when: - Converting ActiveRecord relations - Materializing lazy enumerables - Making data serializable --- ## What `to_ary` Is For `to_ary` is an **implicit conversion**. It tells Ruby: > “This object *is* an array.” Because of that, Ruby will call `to_ary` **automatically** in situations where it expects an array. Example: ```ruby class Pair def to_ary [1, 2] end end pair = Pair.new a, b = pair ``` Ruby calls `to_ary` without asking you. This is powerful—but dangerous. --- ## Why `to_ary` Is Dangerous When you define `to_ary`, Ruby may use it in places you didn’t expect: - Multiple assignment - Array destructuring - Splat (`*`) operations - Method argument expansion Example: ```ruby def takes_array(arr) arr.length end takes_array(pair) ``` If `pair` implements `to_ary`, Ruby silently treats it as an array. This can: - Hide bugs - Break method contracts - Make debugging harder That’s why `to_ary` should be used **very rarely**. --- ## A Rails Example Where This Matters Consider a Rails model that wraps multiple values: ```ruby class Coordinates def initialize(x, y) @x = x @y = y end end ``` If you add `to_ary` here, Rails helpers, form builders, or serializers may start treating it as a real array. That’s usually not what you want. If you want explicit conversion, use `to_a` instead: ```ruby def to_a [@x, @y] end ``` Now conversion only happens when you opt in. --- ## When You Should Use `to_ary` Use `to_ary` only when: - Your object truly *is* an array conceptually - Implicit conversion makes the code clearer - You fully understand where Ruby might call it Common examples: - Tuple-like objects - Value objects meant for destructuring - Internal DSLs with controlled usage Even then, caution is warranted. --- ## When You Should Use `to_a` Use `to_a` almost everywhere else. It’s the right choice when: - You want predictable behavior - You’re working with collections or enumerables - You don’t want Ruby guessing your intent Rails itself heavily prefers explicit conversions for this reason. --- ## Final Thoughts The difference between `to_a` and `to_ary` isn’t about arrays. It’s about **intent**. - `to_a` says: “Convert me if asked.” - `to_ary` says: “Treat me as an array everywhere.” In most Ruby and Rails codebases, explicit conversion wins. If you ever feel unsure, don’t implement `to_ary`. That’s usually the right choice. ]]> kevinpetersoncr0930@gmail.com (Kevin Peterson) https://kevinpeterson.me/blogs/why-elixir-changed-how-i-think-about-backend-systems https://kevinpeterson.me/blogs/why-elixir-changed-how-i-think-about-backend-systems Sun, 12 Jan 2025 00:00:00 GMT “How do I protect shared state?” to > “What state actually needs to exist?” Once you model work as small, independent processes, systems become easier to reason about — and easier to scale. --- ## Letting Things Fail (On Purpose) One of the hardest mindset shifts for me was accepting that **failure is normal**. In many stacks, failure is treated as something to prevent at all costs. In Elixir, failure is expected — and *designed for*. Supervision trees make this practical: - A process crashes → supervisor restarts it - A bad request doesn’t poison the system - Recovery is automatic and predictable This doesn’t mean you ignore errors. It means you **contain them**. Production systems become calmer when failure paths are intentional instead of accidental. --- ## Phoenix, LiveView, and Real-Time Without Pain Phoenix feels familiar at first — routing, controllers, templates. But where it really shines is real-time work. With LiveView: - State lives on the server - UI updates are pushed efficiently - You avoid large client-side complexity for many use cases It’s not a replacement for React in every scenario. But for dashboards, internal tools, and real-time workflows, it’s hard to beat. The key lesson for me wasn’t LiveView itself — it was realizing how much frontend complexity exists *only* because the backend can’t keep up. --- ## Elixir Isn’t the Only Tool (And That’s Okay) I don’t use Elixir everywhere. Some problems are better suited for: - Python (ML, scripting, glue code) - TypeScript (frontend-heavy products) - Go (simple, static binaries) What Elixir taught me wasn’t “always use Elixir.” It taught me to **choose tools based on failure modes, concurrency needs, and operational simplicity**. That mindset carries over no matter what language I’m using. --- ## Final Thoughts Elixir didn’t make me a better programmer overnight. But it made me a more **intentional system designer**. I now think more about: - What happens when this crashes? - Who restarts what? - How much state do I really need? - Can this fail without taking everything else down? Those questions matter more than syntax. If you’re curious about Elixir but unsure where it fits, my advice is simple: build something small, put it under load, and watch how it behaves. That’s where it clicks. ]]> kevinpetersoncr0930@gmail.com (Kevin Peterson) https://kevinpeterson.me/blogs/why-i-like-using-rescript-for-frontend-work https://kevinpeterson.me/blogs/why-i-like-using-rescript-for-frontend-work Thu, 18 May 2023 00:00:00 GMT string = "v4" ``` That’s all you need. No wrappers. No ceremony. --- ## Why I Reach for ReScript I like ReScript when I want: - Confidence during refactors - Clear and enforced data models - Fewer runtime surprises - Strong typing without heavy syntax It works especially well for: - Frontend-heavy applications - Shared UI libraries - Teams tired of TypeScript edge cases --- ## When I Wouldn’t Use It ReScript isn’t always the right tool. I usually avoid it when: - The team has no interest in typed functional concepts - The project is very small or short-lived - The ecosystem depends heavily on TypeScript-only tooling Like any language, it works best when the problem fits. --- ## Final Thoughts ReScript doesn’t try to replace JavaScript culture — it improves it. You still write React. You still ship fast. You just catch more problems *before* users do. For me, that tradeoff is worth it. If you’re curious, try converting a single component or utility first. That’s usually enough to see whether it clicks. ]]> kevinpetersoncr0930@gmail.com (Kevin Peterson)