There are pearls to be found. Check out these git logs.
The right tool for the right job, right? Well let me introduce you to psql.
Adding policies is easy. Removing them is difficult. Say no to more process. Trust your team instead.
From big-endian to little-endian through unsigned integers. A tale of two ends, and Elixir shines again.
GitHub’s squash and merge button is great. But make sure to write a good commit message before you confirm those changes.
Elixir is known for being a language made for building distributed applications that scale, are massively concurrent, and have self-healing properties. But is Elixir good enough for the mundane scripts of this world?
To write good commit messages, you must read commit messages. And to read commit
messages, you must use
git blame effectively.
Long-lived processes are everywhere in Elixir. Let’s look at why they’re needed and how to create them!
When coming from object-oriented languages, I often hear people ask the question, “How do I organize my code? Modules are just bags of functions!”. That is a question I asked myself as well, but after using Elixir and Elm for a while, I have noticed that there is a principle of organization that I keep using and that I see in the wild. I like to think of it as the principle of attraction.
Concurrency is a first-class citizen in the Elixir platform. The concurrency model is that of isolated, independent processes that share no memory and communicate via asynchronous message passing. In other words, a process can run concurrently without concern of others, and processes communicate with each other only via send-and-forget messages.
One of the benefits of tests is that they are the first piece of code that will interact with our application. As such, they can offer valuable insights into the application's complexity.
Supervision trees are awesome. For a while I was a bit confused as to how to use the
supervision strategy. Let’s look at it step by step by creating a simple
bank account from which we can deposit and withdraw money.
When working on a feature, I often find pieces of code that I have not seen before. In order to better understand the class or method, I like to use tests as documentation and as a way to explore the code's functionality.