Testing your README.md
I’ve wanted a good way to test READMEs in elixir. I started building something myself before my good friend Wojtek pointed out that there was a simple solution.
This is where I think things. Sometimes it's about code. Sometimes that code works.
I’ve wanted a good way to test READMEs in elixir. I started building something myself before my good friend Wojtek pointed out that there was a simple solution.
I’ve seen a lot of elixir at this point, both good and bad. Through all of that code, I’ve seen similar patterns that tend to lead to worse code. So I thought I would document some of them as well as better alternatives to these patterns.
I originally wrote this for the backend engineers at Bleacher Report. I thought that it might be useful to others to repost it here. I’ve obfuscated the names of the specific services but otherwise left it as is.
I’m a big fan of telemetry. It’s arguably the most important elixir project released in the past few years. Most of the mainstream libraries have started to adopt it, and that’s a good thing. But, there’s still a lot of inconsistency in how telemetry is used across projects. I thought it would be good to write up some of the conventions that I’ve been using.
One of my new goals is to try to make my elixir libraries more reusable. It’s an easy mark to hit if you only use modules and functions. But once you start adding processes, ETS tables, and other stateful constructs, the solutions get murky.
Rich Hickey posted this gist back in 2018 about the entitlement of people who use open-source software. I’m not going to re-iterate his points and instead suggest that you give it a read. But, I’ll leave you with one of my favorite quotes:
In the middle of 2019, I rediscovered RSS. I see you rolling your eyes; how could you possibly forget about RSS? I suppose I’d just gotten lazy. I’d allowed Twitter or some crappy news aggregator to dictate what I was reading. But, considering how I could become a more discerning consumer, it occurred to me that RSS hadn’t gone anywhere, and I should start using it again.
I gave a talk last year about how to properly boot elixir applications. In the talk, I showed how to load configuration values into an ETS table on boot, and this was the same pattern that I used initially in Vapor. I now think that this is a bad idea.
There are a few things in the Elixir/Erlang ecosystem that I consider required reading. To spawn, or not to spawn? by Saša Jurić is definitely one of them. If you haven’t read it, you need to. It’ll change the way you think about building elixir applications.
A common need in web applications is to “undo” a deletion event. This is referred to as a soft-deletion. The record still exists but its hidden from the user. Soft deleting allows the user to restore that data in the event that they need it in the future.