Posts
Helix file picker with lf
Cool Fish Shell abbreviations
Remap Caps Lock to Esc and some
Pretty selection sort in Rust
You can't just avoid complexity
Nix users, you can fearlessly start using Rust scripts already
Did some CLI/terminal self-care over the weekend
Embedding git version hash in a binary in a Nix friendly way
Migrating my blog from write.as
git alias to make a single commit reverting to previous commit
If you ever need to make a PR that just reverts the state of a branch to a certain point, you might find this useful:
Be careful what you measure because you will optimize it
Humans are very competitive. If you give them a number to rate themselves with, they will try to increase it.
If you find an Open Source project, and it's not very optimized on a certain metric you care about, to make it better, you have to do only one thing: write a benchmark for it. Ideally showing this project is worse in a given metric compared to some other similar projects. You're almost guaranteed that in a short time there will be improvements.
Most people must be familiar with the quote:
“Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.”
― H. James Harrington
It's an important insight and people internalized and wish to apply it... even where it can't be.
On always using the "lower than" operator
Public toilet model of maintaining a codebase
I find that it's useful to think about software projects as restrooms. Surprisingly a lot of aspects of software development fit well in this analogy.
We have toilets (codebases) to serve our needs. We don't particularly value them for what they are, other than as much as they are useful to us. We have rules and rituals around sharing them, and so on.
But let me just tell you something important about restroom maintenance.
Software project estimation is like drawing a spiderman
Please check this out first (feel free to skip around):
Have you noticed, that drawing a spiderman is very much like building a software project? No? Here's why I think so:
My case against mocking frameworks
Since "mocks" and "mocking" is somewhat vague, and nuances between mocks, fakes, mock objects, test doubles, spies, etc. are confusing, let's start with what I mean by "mocking".
What I mean by it is intercepting and/or substituting internal and often arbitrary function calls to test your code.
A great example of a mocking approach is a mocking framework like Mockito, where the tests look like this:
"Objects" (in OOP) are just confusing people
I have recently discovered a very good youtube channel about business software development: CodeOpinion. Very concisely yet informative. I highly recommend it. Don't worry - it's OOP-rant free, and all about mainstream accepted good practices, not some wacko OOP-hater like me.
Anyway, while going through some of the episodes I have found a good example of how "Objects" (in OOP) are a metaphor that is just confusing people.
Please watch the AVOID Entity Services by Focusing on Capabilities - it's just 7:30:
What I'd like you to know about making your software fast
I like fast code, and I cannot lie.
I've been optimizing a lot of projects over the years, and here are some tips that I'd like to share with you
Adding parallelism to your Rust iterators with `dpc-pariter`
TL;DR: I published a parallel processing library for Rust that works differently than rayon and is especially useful in cases where rayon falls a bit short. I'll talk a little bit about it, and show you when it can be helpful.
"Data-Oriented Programming Unlearning objects" - short review
I've recently purchased the Data-Oriented Programming Unlearning objects by Yehonathan Sharvit. I and would like to write out some notes I've captured during reading it.