Our communication practices can be very disrupting. Remote work has taught me to be more considerate of how I communicate with others. We should treat other people's time as we like ours to be treated.
Our communication practices can be very disrupting. Remote work has taught me to be more considerate of how I communicate with others. We should treat other people's time as we like ours to be treated.
Most people learn vim's `normal`, `insert`, and `visual` modes. But they're only casually acquainted with vim's powerful Ex commands. Let's take a look at some.
Vim has a reputation for being hard to quit. But it turns out there are so many ways to get out of it — it's like vim wants you to quit. Let's look at a few.
My workflow usually involves squashing many commits into a single one. But sometimes, the workflow calls for the opposite action -- splitting a single commit into many. This is how I do it.
Having your code reviewed can be daunting. But it can also be very helpful. As reviewers, we can make the difference. Here are five tips to make your code reviews more helpful to the author.
When faking external services in tests, start with something simple. I like having a public interface to adapters and having an in-memory adapter for tests. Let me show you an example.
Toggle between alternate files, edit files by type, and create files with templates — all with `vim-projectionist`. If you've never used it, you're in for a treat.
Many people ask, "How do I find time to refactor?" I think the question itself betrays a misunderstanding of refactoring. Let me tell you when I refactor.
Don't let your git repo become a graveyard of stale branches. But how do you even know what branches are there? Let me introduce you to `git branches`.
Refactoring has a specific meaning. When we misuse the word, we lose the ability to communicate an important concept. Let's revisit what refactoring is and what it is not.
Recently, thoughtbot decided to make Upcase free. It has a lot of great
learning materials, especially when it comes to Rails, vim, test-driven
development, and tmux.
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?
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 simple_one_for_one
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.
