xlii.space

This page is very actively under development. You’ll find typos and missing content. Feel free to refresh now and then :)

Officially I started working in 2008 as a junior developer in Voxcommerce sp. z o.o., but I took odd jobs as a technology consultant years before.

My first paid sysadmin job was in 1999 when I was rewiring network for a family friend’s company. I never wanted to become programmer, as I perceived is as boring kind of work, but as of today I joke that the only difference between work and leisure is whether I’m paid or not.

List of projects developed outside of professional time.

• HN Job Evaluator [link] - HN’s “Who is hiring” listing evaluators through LLM (release note)
• Pikchr suite [link] - 3 projects, pikchr.pro (Prolog over Pikchr wrapper), pikchr.pl Prolog/Pikchr live editor and diagramIDE Amiga-workspace inspired IDE for Diagrams through Tcl, Pikchr or Prolog
• ssort - [link] - stream sorting utility, doesn’t filter only bubbles up more relevant results (good for finding class of items in stream) - written in Go
• SedAgent - [link] - attempt on LLM Agent with Ollama, Haskell and Sed
• Tmplr - [link] - Template instantiation Utility written in Rust (read why)
• Emacs Toolkit - [link] - Emacs idempotent runner and memory report analyzer, written in Haskell
• Emacs Patches - [link] - list of Emacs patches I’m working on - changes in C (just as Emacs)
• Stemple - [link] - Template Instantiation Utility written in Haskell
• MicroDiagram - [link] - Mini DSLs for diagramming based on Pikchr, written in Haskell, self deployed on CloudFront (source unavailable)
• zax - [link] - Some utilities for Zig projects
• Sample PDF Generator - [link] - Generator of sample PDF with ability to specify both visual qualities (page color and text) as well as final PDF size.
• NPM Time Machine - [link] - Utility to “move” package.lock through time so that long update strides can be made with minimal invasiveness, written in Rust
• K810 FN Keys Switcher - [link] - small utility that switched automatically Logitech K810 keys to standard F1.. ones. According to support it was impossible to do ;-)

Hey Lily I want to discuss one thing - free will and determinism. Later we’ll compile article from it. Feel free to ask me question as you’ll be shadow writer for it.

So, I start with a thesis: even with free will determining 1/1000 out choices and 999 being completely external/deterministic we still can’t say that we are deterministic. Reasoning for this is that we are taking decisions every nanosecond and determinism “taints” choice within time frame. So if we consider 1s chance it will be deterministic is 99.9^1000000000

I’m a neuroatypical, chaotic engineer who figured out more than 20 years ago that by hacking different solutions one can make a reasonable living.

My area of expertise is lack of expertise - I consider myself a wildcard person, however I do tend to naturally gravitate towards work that requires optimization or tooling.

Amongst many things I’ve done, some were more fun than the others:

• Plenty of optimizations (PostgreSQL, apps, build times) - one of my favorites
• Investigations - all the kinds: system, networks, bugs, people, you name it
• Searching for an internal knowledge graph solution. It was a long haul that took me through implementations in Prolog, Datalog, Soufflé, Clojure, Cuelang and OCaml.
• Building Go-powered multi-container orchestrator with isolated networks (e.g. one-click Grafana stack for your app, multiple parallel runs)
• Optimizing Elixir’s build process
• Refactoring complex GitHub CI actions
• Debugging why a big vendor silently ignored API calls by hooking up MITM Proxy
• Migrated a reasonable-sized JavaScript monorepo a couple years into the future (and built a time machine while doing that)
• Was doing TLA+ models to verify time-based assumptions in an unstable distributed system environment.
• But also checking on Dafny and F*
• Three.js visualization model linked to product data
• Took a decision and successfully rewrote a search engine 2 days before launch because the planned one was heavily unstable
• Had my own personal kernel for a Fujitsu-Siemens laptop because the suspend button didn’t work as I wanted
• …and own drivers for a Logitech keyboard because it was crippled

Want to say hi? alexander at kaminski dot se

It's been more than 5 months since I started working on Emacs optimization on macOS. This posts is a "check-in" because at this specific moment I'm reasonably satisfied with its performance.

It is also, however, an explanation why I got to that point and what I'm confident is a root cause of this behavior along with underlying mechanisms for that.

+ title = "What the ADHD?" date = "2023-05-07" template = "page_toc.html" draft = false [taxonomies] tags = ["adhd"] [extra] intro = "Following text covers ADHD exclusively and is a break-off from a longer text on related topic. While it can be read by anyone, it does have some engineering-related concepts and comparisons." +

#+END_EXPORT

Without going into personal details — I have a stake in ADHD. I'm raising awareness and try to help those who have it — knowingly or not. Due to that I'm always on the lookout of new knowledge, ideas, techniques and tools.

+ title = "Upgrading Node Stack" date = "2023-05-10"

template = "page_toc.html" slug = "upgrading-node" draft = false [taxonomies] tags = ["software_engineering", "javascript"] [extra]

intro = "" +

#+END_EXPORT

Dealing with a dependency hell is a dirty job.

It probably got its name directly from how fun that activity is. Years ago I heard description that something is like a chewing on a broken glass, but slightly less entertaining. It would fit.

+ title = "Forest Thinking in Prolog" date = "2024-06-26"

template = "page.html" slug = "forest-thinking-in-prolog" draft = false [taxonomies] tags = ["prolog", "choicepoints", "backtracking"] [extra] #class = "orange_header"

intro = "" +

#+END_EXPORT One thing that really annoyed me at the beginning of my adventure with Prolog was when THIS happened:

?- between(1,3,A).
A = 1 █ <- blinking cursor

I couldn't understand Why Prolog wouldn't produce all the solutions? It felt so obvious, that A can have 3 different results.

+ title = "Software Is A Tire" date = "2023-05-05" template = "page.html" draft = false [taxonomies] tags = ["light", "software"] [extra] +

#+END_EXPORT

• Tires are everywhere
• Nobody needs a tire by itself
• Tires aren't exciting (except for tire engineers and tire salespeople)
• Tires "just are" <hr/>

• You don't have to buy very expensive tires
• There are reasons why the cheapest tires are cheap
• For some people tire's brand is more important than it's quality <hr/>
• Tires are more complicated than most think
• It's neigh impossible to explain in detail process of making tires
• Modern tires are result of work of many specialists and highly specialized equipment
• Nobody cares how awesomely engineered your tire is (unless you're in business of selling tires) <hr/>
• Tires require specific skills to handle
• Everyone can learn skills to handle tires
• Even with knowledge, handling tires is hard work
• It might be very difficult to get rid of stains got from handling tires <hr/>
• Many claim to be able to change the tire, a few succeed
• Tire change isn't critical knowledge for a tire engineer
• Handlers are relevant only as long as there's something to put tires on <hr/>
• Tires deteriorate over time
• Well maintained tires can serve for a long time
• Neglected tires under bad conditions can deteriorate very quickly
• Unskilled handler can have serious impact on the tire lifetime
• The more tires your own the harder it is to maintain them
• The biggest cost come from the tires that are not in use
• It's important to be aware of the state of your tires
• Badly maintained tires can blow in your face <hr/>
• It's important to properly dispose of used tires
• Some dump used tires in the woods and hope for the best
• Smoke from burning tires can be seen from miles away
• The more tires you have, the more visible fire will be <hr/>
• Tires by themselves won't help you figure out where you should be going
• Tire shouldn't be the leading factor when deciding on the route
• Don't opt for rough road only because you have tires to test
• It's not the tires' fault that you got lost or hit dead end <hr/>
• Good tires are important component of safety
• Some tires can make you more comfortable
• Some tires make increase your mileage
• Tires can save lives <hr/>
• It's not a good idea to run on bald tires
• Bald tires + rough conditions = almost certain crash
• In some lucky cases journey with bald tires might still turn out OK <hr/>
• There is no "best" tire
• Tires should be picked with road and conditions in mind
• Tire that works for someone else might not be good fit for you
• Tire tailored for specific conditions can be the worst choice when they change
• Sometimes you need a very special tires
• On some occassions tires will be helpless and employing extra means might be necessary <hr/>
• Tire is easy to blame when things go out of control
• Nobody talks about tires when they do their job right

+ title = "Network Scenarios Cheatsheet" date = "2024-06-15"

template = "page_toc.html" slug = "network-scenarios" draft = false [taxonomies] tags = ["software_engineering", "network", "design"] [extra]

intro = "" +

#+END_EXPORT I find it amusing that software engineers (or at least those I know) are very risk averse but paradoxically very optimistic about some topics. Complete trust in reliable network conditions is a belief that puzzles me often.

After frequent conversations about what is - and should - be considered “normal” reliability when passing messages between distributed systems I got bored with recalling (and repeating!) same examples.

+ title = "The Knob" date = "2023-03-30" template = "story.html" draft = false [taxonomies] tags = ["fiction"] [extra] class = "knob" +

#+END_EXPORT

I pressed play and sat as slightly coarse sound of a vinyl record filled the room. Compared to available technology quality was laughable at best, but it wasn't about the music for me. I don't know if that was true or not yet turning various knobs to get what I wanted felt great and precise. Lows, mids, highs; frequencies tuned exactly as I wanted.

+ title = "Grounding in Prolog" date = "2024-06-20"

template = "page_toc.html" slug = "grounding-in-prolog" draft = false [taxonomies] tags = ["prolog", "software_engineering"] [extra] #class = "orange_header"

intro = "" +

#+END_EXPORT

Grounding is one of the weirdest concepts in Prolog and the ones that occassionally comes back to haunt me.

Since Prolog is for Nerds³ I decided to translate it to Engineer½ (like myself) language.

<div class="framed w-75 centered"><img src="/images/prolog-grounding-redacted.png" alt=""></div>

+ title = "A Flying Giraffe" date = "2024-06-17"

template = "page_toc.html" slug = "flying-giraffe" draft = false [taxonomies] tags = ["software", "software-engineering", "process"] [extra]

intro = "" +

#+END_EXPORT

In spirit of trying to not get into very long texts, I've extracted this from a larger piece, which might feel disconnected.

Single iteration loop, that can be taken from "base" software development process, one that's often taught during education usually is a simple one.

When writing immediate mode (egui) applications it comes to me quickly that nigh all logic computations should be done off the UI thread. There are many ways to approach it, however as a fan of event-based systems sooner or later I implement some kind of event handling. The pattern is almost the same with minor differences and looks like this:

#[derive(Clone)] pub struct ProcessorConfig { pub id: String }
#[derive(Clone)] pub struct TaskResult { pub success: bool }
pub struct State { pub active_tasks: Vec<u32> }

#[derive(Clone)]
pub enum Event {
  ProcessorStart { config: ProcessorConfig },
  ProcessorStop,
  LongRunningTask { id: u32 },
  LongRunningTaskComplete { task_result: TaskResult },
}

struct EventHandler {
  state: Arc<RwLock<State>>,
  tx: tokio::mpsc::Sender<Event>,
}

impl EventHandler {
  fn handle(&self, event: Event, event_queue: &mut VecDeque<Event>) {
    use Event::*;
    match event {
      ProcessorStart { .. } => self.process_processor_start(event, event_queue),
      ProcessorStop => self.process_processor_stop(event, event_queue),
      LongRunningTask { .. } => self.process_long_running_task(event, event_queue),
      LongRunningTaskComplete { .. } => self.process_long_running_task_complete(event, event_queue),
    }
  }

  fn process_processor_start(&self, event: Event, _event_queue: &mut VecDeque<Event>) {
    let Event::ProcessorStart { config } = event else {
      return;
    };
    println!("Starting processor with config: {}", config.id);
    // ...
  }

  fn process_processor_stop(&self, event: Event, _event_queue: &mut VecDeque<Event>) {
    let Event::ProcessorStop = event else {
      return;
    };
    println!("Stopping processor...");
    // ...
  }

  fn process_long_running_task(&self, event: Event, _event_queue: &mut VecDeque<Event>) {
    let Event::LongRunningTask { id } = event else {
      return;
    };
    
    println!("Starting task {}", id);
    if let Ok(mut state) = self.state.write() {
      state.active_tasks.push(id);
    }
  }

  fn process_long_running_task_complete(&self, event: Event, _event_queue: &mut VecDeque<Event>) {
    let Event::LongRunningTaskComplete { task_result } = event else {
      return;
    };

    println!("Task completed. Success: {}", task_result.success);
    if let Ok(mut state) = self.state.write() {
      state.active_tasks.clear(); 
    }
  }

…

Ever heard about Brainf*ck language?

It’s an esoteric language that has 8 operators that programmer can use to create programs. This, for example, is “Hello World” example:

>++++++++[<+++++++++>-]<.>++++[<+++++++>-]<+.+++++++..+++.>>++++++[<+++++++>-]<++.------------.>++++++[<+++++++++>-]<+.<.+++.------.--------.>>>++++[<++++++++>-]<+.

In case Brainf*ck name is too offensive, there is also Ook! Ook! language that uses pairs of Ook., Ook? and Ook! as operators. An example operators in Ook! Ook! is Ook! Ook. or another is Ook? Ook?.

I guess you can already see that I have some experience with esoteric languages.

Every LLM-backed tool I built started the same way: wire up an API client, handle key storage, paper over provider quirks. hn-jobs-evaluator had Gemini baked in. Next tool, same plumbing from scratch.

llmuxer is the extraction of that pattern into a 3-crate library.

llmuxer is the core: LlmConfig holds provider + key, builds a client, and exposes QueryBuilder and CacheBuilder via a fluent interface. Provider differences stay inside.

llmuxer-keystore persists configs so you’re not re-entering API keys across tools.

It’s been almost 20 years since I started working as a software engineer. Finding my next role has become excruciatingly difficult. If you’re looking for someone like me, my resume is linked - feel free to reach out.

I rarely sent out more than three applications. Usually, from those three that I sent, two resulted in interview invitations that converted to offers.

Today the reality is vastly different. Out of 20 applications I sent, and those were carefully selected - I don’t like going wide - only four resulted in initial interviews. None have led to an offer.

Monthly “Who’s Hiring” threads on HN are a mess to filter. Freeform text, dynamic ordering - keyword search misses half the relevant listings.

Good problem for an LLM. I built a Rust/egui app that fetches the thread, scores each listing against your resume and requirements via Gemini, ranks by fit.

The interesting design decision was the UI. Listings are long, evaluations are freeform, there are hundreds of them. CLI/TUI ruled out immediately - some descriptions wouldn’t fit a screen. A table with scrollable cells is quirky (scroll-in-scroll), but it’s the only layout that lets you skim fast without losing context. Everything else I tried either hid too much or required too many clicks to get anywhere.

Every software engineer worth their salt has lived through the static vs dynamic debate at least once. It’s a good debate to have, many times even. The arguments are well known but often tackled from different angles. At its core, however, it goes in a similar direction. Static types give confidence, ease of refactoring, guarantees. Dynamic types give flexibility, ease of use and no-fuss development. Both are equally successful at delivering software.

Every team has a code review process. Tickets move, PRs open, comments accumulate, something gets merged. The system looks like it’s working because the system looks like it’s working.

This is about what actually happens in the middle part – between “created” and “merged” – and the people doing it. You’ve worked with all of them. One of them is you.

“Politics is for people who can’t write good code.”

I can’t overstate how much I hate GitHub Actions. I don’t even remember hating any other piece of technology I used. Sure, I still make fun of PHP that I remember from times of PHP41, but even then I didn’t hate it. Merely I found it subpar technology to other emerging at the time (like Ruby on Rails or Django). And yet I hate GitHub Actions.

With Passion2.

Day before writing these words I was implementing build.rs for my tmplr project. To save you a click - it is a file/project scaffold tool with human readable (and craftable) template files. I (personally) use it very often, given how easy it is to craft new templates, by hand or with aid of the tool, so check it out if you need a similar tool.

CUE is the Swiss Army knife of file generation. It is the tool you grab when you need to generate complex JSON, validate YAML, or generally stop configuration files from ruining your life. It slices, it dices, it ensures your integers are actually integers. But guess what else it can be? It turns out, it is also a surprisingly effective Literate Programming tool.

This is important because, let’s be honest, the current king of this hill is org-mode. And while org-mode is powerful, it is also a bit of a golden cage. It works perfectly as long as you never leave the Emacs ecosystem. But the moment you try to export a workflow to a colleague who uses VS Code, you realize you have accidentally signed up for vendor lock-in. You want your documentation - your “literate code” - to be portable, not a magic spell that only works inside one specific editor.

**

They say the definition of insanity is doing the same thing over and over again and expecting different results. In software engineering, we call this “benchmarking.” Or, in my specific case, “rewriting a template utility four times because I am spiritually incapable of settling.”

The goal was simple. Deceptively so. I wanted a tool called tmplr. Its job? To take a template, sprinkle in some variables, and spit out a file. It is the sort of task that a shell script could do if you didn’t value your sanity, or that Python could do if you didn’t value your startup time.

…also known as synergized orchestration of federated functional paradigms via lattice-theoretic constraint-based asset dissemination ;-)

or “how I generate X YAML files with Cue to keep my sanity intact”.

I like modularity. When working on my project I made every diagram (or parts of it) into separate module. E.g. something like this:

Unfortunately - Haskell’s Stack gets confused and then (for example) testing mod2 makes it rebuild whole application; slow and annoying.

// make_tool.cue
package main

import (
  "tool/file"
)

files: {}

command: make: {
  for k, v in files {
    "\(k)": file.Create & {
      filename: k
      contents: v.contents
    }
  }
}

This is a quick boilerplate for Cue lang to start producing (text) files.

That way one can create many (consistent!) files from a single Cue file/package by using cue cmd make. As an example - I use it to generate Pikchr diagrams wrapped in Markdown:

If you’re one of my 3 stalkers (HEY Y’ALL!), you might’ve noticed that I started to write about Haskell recently. If not, well you know now :)

Haskell is a nice language in a way that it teaches one (i.e. me) a new tricks. Tricks from Haskell that I started started wrtiting a piece about. I’m at the trick of small functions but I also recently read an interesting article with which I don’t (in general) agree and decided to follow on –1 Small functions considered harmful.

• Design
• Word on the Prompt
• Types
• Implementation
• Main Function
• End result and final word
• Main.hs

Inspired by Fly.io article I figured that writing an Agent in Haskell (which I recently picked up) would be a nice exercise, so hey, why not do it?

This post is walk through full implementation of a GNU Sed agent (that doesn’t work correctly, but probably because I’m using it wrong).

When thinking about agent design my thought process was as follows:

This is a description of recently released MicroDiagram prototype. Check it out if you haven’t yet. It’s mostly technical and discusses some of the challenges I faced, as it was my first Haskell project.

• Backend - single binary written in Haskell, consisting of
  • Piano Diagram Parser + Generator
  • Diagram generating utilities
  • Scotty web server [1]
  • HSpec and Quickcheck tests
  • Code volume is - approx. 1200 non-empty lines of Haskell code
• Frontend unpoly [2]
  • With fragment rendering for the Piano result
• Deployment
  • Couple Cloudflare Containers [3] load balanced by Cloudflare worker
  • Single not-static binary running on Debian

Average request duration is 7 ms and the median CPU time per request (diagrams are updated on keystroke!) is 0.88 ms.

• Setup
• How to input ◊ ?
• Tricks
  • Smart Flush
  • Instant Templates (just add water)
  • Regexp Catch-Guards
  • The Recipe For Macro Success
  • G◊-◊-◊-◊ Lozenge crazy
• Final Words

Recently I’ve stolen from tremendous anvil editor 1 idea of using Lozenge (◊) as an utility character in Emacs.

Since it integrated almost seamlessly I decided to share it with world.

While article this is Emacs-specific, it’s highly probable you could integrate following tricks in the editor of your choice.

I’ve been working on a specific idea for some time - microdiagrams DSL. The core concept is quite straightforward: instead of having one language for all diagrams, have multiple languages for various purposes. For example, this diagram is designed to help learn piano by illustrating the relationship between different keys.

This idea had multiple prototypes. I won’t get into the details why (hey, I hope to make some money out of it someday!), but I’ve entertained the same idea for quite some time. One would say that technology doesn’t matter, but I disagree. I think that for side projects (or Magnum Opus for that), one shouldn’t use boring technology.

Recently I thought that writing about Cuelang and thought “hey, wouldn’t it be nice if I could put some Cue code into Org and evaluate it so that I could showcase the result”?

Well, it’s a shame ob-cuelang doesn’t exist. However, thanks to the LLMs I could vibe code it, right? And so, I steeled my nerves, thought hours about the prompt and, after 30 minutes and 2 glasses I put nervously:

Table of Contents

• Favorite
  • Go
  • Cuelang
  • CLIPS
  • Zig
• Promising
  • C
  • Haskell
  • Souffleé
• False promise
  • Prolog
  • Mercury
  • Perl
• Left behind
  • Clojure
  • Rust
  • Ruby
  • Elixir
• Bland
  • Python
  • TypeScript
• Honorable mentions
• No, please, no

As I’m juggling languages often there are those which I like more or less and it fluxuates over the period of time. I figured out it might be good idea to put on (virtual) paper why I find language attractive.

This one is stupid. I have an idea for parser and I even have a proof of concept working in CLIPS1. Given my search it seems it something like recursive-descend parser, but I’m not sure if it qualifies.

If you know drop me an e-mail please.

I will use Lisp-like syntax, but this has no implementation except for aformentioned CLIPS, and is more about data structures and logic.

When I write about rune I mean rune as per in Go language, aka a codepoint. Token is one of (I’m still considering full grammar):

September 20th, 2025 marks exactly one year since I bought Roland’s FPX-30, 88-keys full sized digital piano. Being in my 4th decade of life I never taught myself any instrument, even though I own and dabble with many.

In fact, while I’m unable to remember sounds or hear them in my head, it seems I have a rather good understanding what “sounds nice” that allows me to ad-hoc compose music.

Is free will an illusion? For centuries, this question has felt like a philosophical deadlock. Arguments often get stuck trying to define consciousness or find a “ghost in the machine.” But what if the problem isn’t how we see ourselves, but an outdated way of seeing the universe?

This isn’t another abstract philosophical argument. It’s a practical case built on two of the most powerful tools we have for understanding reality: statistics and physics. The goal isn’t to “prove” free will directly, but to dismantle the one argument that insists it’s impossible.

Profiling Emacs on macOS is a child’s play…

…with a playbook stashed away.

It’s easy in the end; however, there are numerous pieces of misleading information out there that have to be found.

What’s needed?

• Xcode + CommandLineTools
• Instruments.app
• Emacs with source and debugging symbols (optional, but recommended)
• GNU Make (for the lazy) - scroll to the bottom

Getting Xcode and the CommandLineTools are straightforward; Instruments.app should come inside the package.

I have been recently roaming.

Doing some Zig, doing some Go, some Janet. Some C integration. Should have focused on my project but life threw more at me than I could handle, so I sought… happy distractions.

My experience with those technologies taught me new tricks and one day, when I needed some more distraction, I decided to debug something that had made me furious for years: Emacs jank1.

One thing that really annoyed me at the beginning of my adventure with Prolog was when THIS happened:

?- between(1,3,A).
A = 1 █ <- blinking cursor

I couldn’t understand Why Prolog wouldn’t produce all the solutions? It felt so obvious, that A can have 3 different results.

When working with predicates (fancy name for function as far as I am concerned), they not only produce value as in the other programming languages. They can produce something along the lines of “hey, here’s a result, but you know, I have more, so get back to me if you want, m’kay?”.

Grounding is one of the weirdest concepts in Prolog and the ones that occassionally comes back to haunt me.

Since Prolog is for Nerds³ I decided to translate it to Engineer½ (like myself) language.

When you declare a list in Prolog it comes with strings attached (sometimes literally):

?- length(AwesomeList, 3).
AwesomeList = [_, _, _].

Too much? Not enough? Who can say! According to Prolog it might be what you wanted!

Single iteration loop, that can be taken from “base” software development process, one that’s often taught during education usually is a simple one.

There are many variations but usually they all look like this:

I wouldn’t say this representation is bad, but it has one nasty flaw.

It camouflages complexity. Complexity which accumulates over time from this naïvely basic process happening again and again and again.

I find it amusing that software engineers (or at least those I know) are very risk averse but paradoxically very optimistic about some topics. Complete trust in reliable network conditions is a belief that puzzles me often.

After frequent conversations about what is - and should - be considered “normal” reliability when passing messages between distributed systems I got bored with recalling (and repeating!) same examples.

So I designed cheat sheet to look at when planning for systems interactions.

Dealing with a dependency hell is a dirty job.

It probably got its name directly from how fun that activity is. Years ago I heard description that something is like a chewing on a broken glass, but slightly less entertaining. It would fit.

Some time ago I was tasked with upgrading libraries for a medium-sized project. It wasn’t legacy by any means, as dozens of developers divided between the teams were working on it daily. I wouldn’t describe structure as trivial. It was neatly split into parts which kept dependencies between them and had adequate volume of source for the role it was fulfilling.

Without going into personal details — I have a stake in ADHD. I’m raising awareness and try to help those who have it — knowingly or not. Due to that I’m always on the lookout of new knowledge, ideas, techniques and tools.

My knowledge is based on personal experience, accounts of those diagnosed and pre-diagnosed, conversations with therapists but also taken from the books and internet sources such as published research, info-sites or (rarely) popular publications.

• Tires are everywhere
• Nobody needs a tire by itself
• Tires aren’t exciting (except for tire engineers and tire salespeople)
• Tires “just are”

• You don’t have to buy very expensive tires
• There are reasons why the cheapest tires are cheap
• For some people tire’s brand is more important than it’s quality

• Tires are more complicated than most think
• It’s neigh impossible to explain in detail process of making tires
• Modern tires are result of work of many specialists and highly specialized equipment
• Nobody cares how awesomely engineered your tire is (unless you’re in business of selling tires)

• Tires require specific skills to handle
• Everyone can learn skills to handle tires
• Even with knowledge, handling tires is hard work
• It might be very difficult to get rid of stains got from handling tires

• Many claim to be able to change the tire, a few succeed
• Tire change isn’t critical knowledge for a tire engineer
• Handlers are relevant only as long as there’s something to put tires on

• Tires deteriorate over time
• Well maintained tires can serve for a long time
• Neglected tires under bad conditions can deteriorate very quickly
• Unskilled handler can have serious impact on the tire lifetime
• The more tires your own the harder it is to maintain them
• The biggest cost come from the tires that are not in use
• It’s important to be aware of the state of your tires
• Badly maintained tires can blow in your face

• It’s important to properly dispose of used tires
• Some dump used tires in the woods and hope for the best
• Smoke from burning tires can be seen from miles away
• The more tires you have, the more visible fire will be

• Tires by themselves won’t help you figure out where you should be going
• Tire shouldn’t be the leading factor when deciding on the route
• Don’t opt for rough road only because you have tires to test
• It’s not the tires’ fault that you got lost or hit dead end

• Good tires are important component of safety
• Some tires can make you more comfortable
• Some tires make increase your mileage
• Tires can save lives

• It’s not a good idea to run on bald tires
• Bald tires + rough conditions = almost certain crash
• In some lucky cases journey with bald tires might still turn out OK

• There is no “best” tire
• Tires should be picked with road and conditions in mind
• Tire that works for someone else might not be good fit for you
• Tire tailored for specific conditions can be the worst choice when they change
• Sometimes you need a very special tires
• On some occassions tires will be helpless and employing extra means might be necessary

• Tire is easy to blame when things go out of control
• Nobody talks about tires when they do their job right

Mickey Petersen wrote nice piece about compile feature in Emacs - something I use a lot and I recommend the read.

I like to have instant feedback, so I use it for almost everything after which run recompile that replays last compile command. recompile can be bound to the key, but my favorite trick is to use Local Variables.

Ready recipe:

## Local Variables:
## eval: (add-hook 'after-save 'recompile nil t)
## End:

It works with any file and thanks to that I get recompile every single time I save the file.

Mickey Petersen wrote nice piece about compile feature in Emacs - something I use a lot and I recommend the read.

I like to have instant feedback, so I use it for almost everything after which run recompile that replays last compile command. recompile can be bound to the key, but my favorite trick is to use Local Variables.

Ready recipe:

## Local Variables:
## eval: (add-hook 'after-save 'recompile nil t)
## End:

It works with any file and thanks to that I get recompile every single time I save the file.

Hey!

Thanks for accepting my invite. Don’t worry, this will be short. I have a places to be, people to… educate. So I’ll have to run soon.

I took the liberty and ordered for both of us. Steak & salad. Good, right?

See, I’m with the Company. Yeah, …that one. We serve your coffee, we make your cereal, we provide you with social entertainment and all this other boring stuff. I do, however, always find it amusing that the same company can produce toothpaste and at the same time be a supplier of network cable for a city.

Hey!

Thanks for accepting my invite. Don’t worry, this will be short. I have a places to be, people to… educate. So I’ll have to run soon.

I took the liberty and ordered for both of us. Steak & salad. Good, right?

See, I’m with the Company. Yeah, …that one. We serve your coffee, we make your cereal, we provide you with social entertainment and all this other boring stuff. I do, however, always find it amusing that the same company can produce toothpaste and at the same time be a supplier of network cable for a city.

For the last few months I was very unhappy with my iPhone 13 Pro battery.

It was discharging way too quick. How quick? After 10 hours after unplugging I usually got “battery low” alert. I didn’t feel my usage throughout the day would be enough explain it.

I tried to troubleshoot it, but to no avail. The only hint I got was “Find My” app, that was using 100% of the battery when inspecting part of the available battery slope. I tried various strategies but wasn’t able to fix it.

For the last few months I was very unhappy with my iPhone 13 Pro battery.

It was discharging way too quick. How quick? After 10 hours after unplugging I usually got “battery low” alert. I didn’t feel my usage throughout the day would be enough explain it.

I tried to troubleshoot it, but to no avail. The only hint I got was “Find My” app, that was using 100% of the battery when inspecting part of the available battery slope. I tried various strategies but wasn’t able to fix it.

Hey y'all!

I have an important PR:
> ...
> 131 files changed, 1255 insertions(+), 318 deletions(-)

Anyone up for a review?

Huge PRs can be a scary thing. When PRs like this are in review queue one I’ve seen following happen:

• PR is pushed away for as long as possible (or even to oblivion)
• Reviewer studies PR for a long time and their energy is drained to last drop
• PR is skimmed top to bottom and pushed forward with “not my problem” attitude

Everyone knows that such huge pull requests should be split into smaller, reviewable ones. And yet they still happen from time to time.

Hey y'all!

I have an important PR:
> ...
> 131 files changed, 1255 insertions(+), 318 deletions(-)

Anyone up for a review?

{{ image(src="/images/let_me_oout.jpg",alt=“Meme image about man trying to get out of fenced area”) }}

Huge PRs can be a scary thing. When PRs like this are in review queue one I’ve seen following happen:

• PR is pushed away for as long as possible (or even to oblivion)
• Reviewer studies PR for a long time and their energy is drained to last drop
• PR is skimmed top to bottom and pushed forward with “not my problem” attitude

Everyone knows that such huge pull requests should be split into smaller, reviewable ones. And yet they still happen from time to time.

Blackboxing of React Component is a (self-named) process that I use in order to separate visual component from the logic layer.

As a refresher - visual components are the type of components which role is to “look nice”. They can have some logic inside, but ultimately they’re dumb. They don’t reach out for data, they don’t handle complex state changes, however they can render different elements reacting to props changes. Components that have complex logic in them are usually named Controller Components or Logic Components. While it’s a very good idea to aim for such separation, real life project have this line blurred.

Blackboxing of React Component is a (self-named) process that I use in order to separate visual component from the logic layer.

As a refresher - visual components are the type of components which role is to “look nice”. They can have some logic inside, but ultimately they’re dumb. They don’t reach out for data, they don’t handle complex state changes, however they can render different elements reacting to props changes. Components that have complex logic in them are usually named Controller Components or Logic Components. While it’s a very good idea to aim for such separation, real life project have this line blurred.