PhoenixTest foot guns→
Notes to self about the unexpected quirks of the otherwise excellent PhoenixTest library.
Notes to self about the unexpected quirks of the otherwise excellent PhoenixTest library.
The post-covid slump is real. On the plus side I became a thought leader, and shipped the best thing I will ever work on.
After working on a complex problem, I tend to over-complicate the next one. I call this "The Complexity Halo".
After three years of cheating death, I finally caught Covid. That said, the week hasn't been a complete write-off.
This week has been a balance of working on Hap, and making a start on finding a new Elixir contract.
Placing schemas inside contexts makes it difficult to distinguish between data and actions. Let's fix that.
In a Phoenix context we frequently need to create and update resources, using changesets. Each operation requires a function to get the changeset, and a function to perform the operation.
If the operation in question is "create", the standard approach is to name the changeset function create_changeset
, but that's just confusing; am I getting a changeset for the "create" operation, or am I creating a generic changeset?
I prefer the following conventions.
Git's pre-push hooks are a great way to enforce code quality. They're also a pain when you just want to push some in-progress work to a branch.
Going into this project, I assumed the biggest problem would be how to retrieve the status of each product. As ever, the real problem was naming things.
The plan has always been to launch Happy Stack with email notifications; that's it. I have lots of other notification channels planned of course, but email is still the most universal.