Shimming Your Way Off a Dead Elixir Dependency
An abandoned dependency was blocking a major upgrade I needed. Here are the two ways I retire one, and when a shim beats a big-bang rewrite.
Available now for Elixir work. Two weeks. One problem. $6,000. Details →
27 posts.
An abandoned dependency was blocking a major upgrade I needed. Here are the two ways I retire one, and when a shim beats a big-bang rewrite.
I have hardened LocalCents with more automated Elixir quality checks than I have ever run. The whole guardrail setup, wired in a real repo.
Notes on how my use of AI has changed over three years, and what's working and what isn't inside LocalCents.
We all nod along to "good code" but rarely define it. Here are the four attributes I look for, and the practices that protect each one.
How I track work, from issue statuses and types to pull request conventions, with sample PR templates you can copy.
You open a project you did not write, hit a wall, and find no one left to ask. The habits that spare the next developer that moment.
My meme about code reviews, got some great replies. I have to share.
Documenting the code aesthetic choices I made in Flick, my side project, as it reached its MVP milestone.
Some captured notes about technical debt from recent book club discussions.
Should a context accessor return `{:ok, noun}` or a bare `noun` or `nil`? Why I am moving toward fetch functions and tuples.
Please heed my warning or be cursed with coupled code!
I recommend avoiding nested aliases since it negatively impacts your ability to text search a project for module usage.
A list of terms I try to use consistently in my Elixir code, and a nudge to build a shared vocabulary with your team.
Use fixtures in your Swift unit tests to quickly build business objects and validate scenarios.
Bouncing between iOS, Go, C, and Kotlin on one client project, and why I think good programmers are better off knowing many languages.
Professional iOS projects document two ways: inline comments on the types, and guides that explain the thinking above them.
Why consistent code style matters more than which style you pick, and how SwiftLint keeps an iOS project honest about it.
The README is the first thing anyone meets in your project, including future you. Here is what I make sure mine covers.
Kicking off a series on what separates a professional iOS project from a hobby one, starting with why I keep learning new languages.
I am running my half-day iOS Refactoring workshop publicly in July, on mastering small improvements instead of risky rewrites.
Students no longer get the Knight Rider analogy for delegation, and that is a small tragedy for a Big Nerd Ranch instructor.
A small tip that makes Cocoa unit test runs launch faster by bailing out of the app delegate early when tests are the target.
My Philly CocoaHeads talk reviewing a handful of iOS code patterns, and where to find our growing archive of meeting videos.
A 1,780-line pull request gets a worse review than a small one. Why I keep working to make my changes smaller than that.
An architecture kata I ran at a CocoaHeads Side Project Saturday. Pair up, design one app, then compare what everyone built.
Notes from the first Software as Craft Philadelphia meeting, a good mix of discussion and hands-on pairing.
An Xcode tip found while wrestling with RestKit serialization. How to run only the tests you care about right now.