As programmers, we often strive to reduce complexity. A major contributor to complexity is conditional logic (some conditionals are actually a result of bad design decisions but some are not and are easy to get rid of). In a previous post, I’ve shown how we can reduce the amount of conditional logic by using Pydantic with Literal types.
itertools and more_itertools are two awesome Python libraries that pack a lot of extremely useful processing functionality. Despite their strengths, it’s easy to get lost in the documentation, failing to understand how to apply them in real-world scenarios and avoid them altogether. In my opinion, avoiding them is a mistake as they allow us to write generic, composable, readable, and concise code.
A while back I accidentally stumbled upon more_itertools and decided to dive deep (I know, I’m a party animal). …
When we need to make changes to legacy code with no tests we often encounter the chicken and the egg problem. On one hand, in order to refactor the code, we need tests but on the other hand, if we want to add tests we need to refactor it first. When this happens we usually just make the changes and hope everything goes well. Is there anything we can do to increase our confidence while refactoring legacy code with no tests?
It turns out there is something we can do and it’s called Overcommitting. The idea is to rely on…
An Algebraic Data Type (or ADT in short) is a composite type. It enables us to model structures in a comprehensive way that covers every possibility. This makes our systems less error-prone and removes the cognitive mental load that comes when dealing with impossible states.
Programmers who work in statically typed languages that have pattern matching are most likely using ADTs in their day to day work. If you’re not one of them, why should you care? I’ve decided to write about ADTs because:
Dynamic languages support defining nested dictionaries (AKA hashmaps, hashes, hashtables, etc) with different types for the values. This makes it very easy to use dictionaries as function arguments or even as full-fledged domain models.
An alternative to dictionaries is data classes. Data classes are just classes that hold data. They should not be confused with Python’s dataclasses and are language agnostic.
In this post, we’ll discuss:
Before we start comparing…
Pydantic is a useful library for data parsing and validation. It coerces input types to the declared type (using type hints), accumulates all the errors using
ValidationError & it’s also well documented making it easily discoverable.
During my time using Pydantic, I picked up a few things that were not immediately obvious to me and also bumped into a few pitfalls. Since it took me a while to discover these, I figured it’s time to share them with the world.
Before we begin a few things to note:
What is FZF?
FZF is a command-line fuzzy finder. It enables you to run a very fast fuzzy search on the inputs that you feed it.
Besides the ability to quickly perform a fuzzy search it also has some other benefits:
FZF’s basic functionality includes:
A very simple (albeit not very useful) example is:
ls | fzf
People who are new to the Git CLI often feel frustrated, this is especially true if they’ve already used Git via a GUI (if you’re experienced with command-line game you could up your game with Git aliases)
It’s hard to blame them, using a Git CLI requires:
Despite the effort, I believe it can be extremely beneficial…
One of the main concerns for developers who want to start using Git from the command line is that it’s slow. It may also feel slow if you compare it to a Git GUI that groups multiple Git commands into a single action. This is where Git aliases can come handy.
If you’ve never used aliases you basically need to create a file named
gitconfig to store these aliases (if you’ve never done it before check setting up gitconfig). …