Dawid Ciężarkiewicz aka `dpc`

Radicle is a very promising "peer-to-peer code collaboration stack built on Git". If you're a NixOS user (you should be) and have some public server machine, it became very easy to set up your Radicle Seeding Node, thanks to Nix contributors that recently added support for it in …

In $HOME/dot/.config/helix/config.toml [keys.normal] C-f = [":new", ":insert-output lf -selection-path=/dev/stdout", "split_selection_on_newline", "goto_file", "goto_last_modification", "goto_last_modified_file", ":…

Inside $HOME/.config/fish/config.fish: function multicd echo cd (string repeat -n (math (string length -- $argv[1]) - 1) ../) end abbr --add dotdot --regex '^\.\.+$' --function multicd function last_history_item; echo $history[1]; end abbr -a !! --position anywhere …

Using xremap > cat .config/xremap/config.yml modmap: - name: CapsLock to RightCtrl/Esc remap: CapsLock: held: Ctrl_R alone: Esc alone_timeout: 500 keymap: - name: RightCtrl+hjkl to Arrows remap: Ctrl_R-h: Left Ctrl_R-l: Ri…

use itertools::Itertools; fn selection_sort(mut v: &mut [u8]) { while let Some(smallest) = v.iter().position_min() { v.swap(0, smallest); v = &mut v[1..]; } } Rust Playground link

Recently I've seen lots of articles about avoiding complexity in software. The general trend is always: "Simple good, complex bad", "Avoid complexity", "Build small", etc. Here is the thing: truly simple software usually sucks. That's why almost nothing that you're doing and usin…

cargo-script is an in-progress feature of cargo, that allows writing "shell-like" scripts using Rust and run them as such. It's already implemented and available in the Rust nightly toolchain. For time being, this makes it a bit inconvenient to use as it requires sourcing the nig…

Did some CLI/terminal self-care over the weekend. Started with trying out Monaspace. Led to Wezterm, led to polishing and integrating everything into a coherent whole. I have now this nested 3-level hierarchy (terminal tabs, tmux tabs, helix tabs), which acts are workspace and w…

In Fedimint we have developed a quite neat way to embedded verision hashes in all the binaries. It works both for builds in a local dev shell and in the build artifacts produced as Nix flake outputs. It does not unnecessarily invalidate the Nix derivations. I'm not saying it's p…

I've been using https://write.as to host my blog for years, but unfortunately they've never added a proper solution to achieving proper "archives" page. As the number of my posts increased, this became increasingly annoying. I finally decided to migrate things to self-hosted solu…

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:

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.

A couple of years ago I've read a blog post somewhere, where the author said that they always use < or <= and never > and >=. So instead of: if v.len() > MAX_ALLOWED_SIZE { which is written the way one would say it: "if the length of v is greater than allowed ...…

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.

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:

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:

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:

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

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.

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.