aborg.dev

Calculation Solitaire

2026-01-03T00:00:00+00:00

TL;DR: I've implemented a mobile-friendly web version of Calculation solitaire. It is available at https://calc.aborg.dev/</a>

Over the last year I got into the Calculation</a> solitaire. I find it appealing as it is quite strategic and has a high skill ceiling. Specifically, the numbers on Wikipedia for 20% win-rate for inexperienced play and 80% for skillful play seem about right. My personal win-rate is around 70% with average play time of 20 minutes. I also implemented a greedy solver</a> and it wins 17% of hands.

To practice, I've implemented a mobile-friendly web version using React+Tailwind (source code</a>). I also ported it to Pico8</a> to play it on my TrimUI Brick handheld.

I would like to extend the web version with the study mode to help me improve my play. To get there, I'll need to get the Rust solver to a higher win-rate. Then compile it to WebAssembly and embed it into the Web app to analyze the quality of moves.

Zed: Keymap

2025-01-13T00:00:00+00:00

This post is a part of my "Zed is the Future?" series</a>

If your are a keyboard-heavy user, one of the first things you start tweaking in a text editor are keyboard shortcuts.
Coming from Neovim, I came to expect full programmability of my key mappings. However, Zed takes a different approach that steers more towards the zero-configuration philosophy that has become popular lately. Zed's keymap is configured through a collection of JSON files with the list of bindings and contexts where they are active:
[ { "context": "Dock || Terminal || VimControl" "bindings": { "ctrl-h": ["workspace::ActivatePaneInDirection", "Left"], "ctrl-j": ["workspace::ActivatePaneInDirection", "Down"], "ctrl-k": ["workspace::ActivatePaneInDirection", "Up"], "ctrl-l": ["workspace::ActivatePaneInDirection", "Right"], }, }, { "context": "Editor && VimControl && !VimWaiting && !menu" "bindings": { ", q": "pane::CloseActiveItem", "n": "search::SelectNextMatch", "shift-n": "search::SelectPrevMatch" }, } ] </code></pre> The JSON-based approach offers several advantages:

Auto-completion and validation tools can provide instant feedback while editing the config</li>
Keybindings are easily shareable as simple JSON snippets</li>
Finding specific mappings is straightforward with basic text search</li>
Future format migrations can be handled smoothly with automated tooling</li> </ul>
However, this comes with several drawbacks:

The JSON format can be verbose and repetitive, making keybindings more cumbersome to define</li>
As everything is defined in a single file with little organization, it becomes hard to explore and maintain the mappings</li>
Customizing default bindings requires copying the existing ones, as there's no native way to extend them systematically</li> </ul>
Alternatives</h2>
I've been wondering if there are alternatives that would be a middle-ground between the full Turing-complete configuration and the plain JSON files.
So I've built a tool</a> to generate the keymap from a more structured and concise definition written in Jsonnet</a> configuration language.
Here is the excerpt from my keymap:
local lib = import 'keymap.lib.jsonnet'; local ctx = lib.ctx; local map = lib.map; local leader = 'space'; local local_leader = ','; std.flattenArrays([ // You can split the keymap into multiple files. (import 'window.lib.jsonnet')(prefix='space w'), // Definitions can take parameters for customization. // For example, I copied default Zed Vim 'g' bindings and // added ability to replace prefix `g` with any other key. (import 'actions.lib.jsonnet')(prefix='g'), [ // Commonly used contexts can be defined in a single place // as the library functions. ctx.hub({ 'ctrl-h': ['workspace::ActivatePaneInDirection', 'Left'], 'ctrl-l': ['workspace::ActivatePaneInDirection', 'Right'], 'ctrl-k': ['workspace::ActivatePaneInDirection', 'Up'], 'ctrl-j': ['workspace::ActivatePaneInDirection', 'Down'], }), ctx.vim_normal({ n: 'search::SelectNextMatch', 'shift-n': 'search::SelectPrevMatch', [local_leader + ' q']: 'pane::CloseActiveItem', }), // When multiple bindings start with the same key, // they can be grouped together with `map.hydra`. ctx.vim_normal(map.hydra(leader, { '/': 'workspace::NewSearch', ',': 'tab_switcher::Toggle', })), ], // You can still use the standard keymap definition syntax. { context: 'Workspace', bindings: { 'shift-ctrl-r': ['task::Spawn', { task_name: 'Update keymap' }], }, }, ]) </code></pre> This config can be fed into jsonnet</code> tool to generate your familiar keymap.json</code>: jsonnet keymap.jsonnet -o keymap.json </code></pre> I'm still exploring the ergonomics of this approach, but it does address my configuration needs for now. The tooling for using it still has a few rough edges though - you need to manually invoke the keymap update after you change the Jsonnet file. Also, error reporting could be improved to provide more context when something goes wrong. I plan to polish it further and share it with the community to gather some feedback.

Zed: Navigation 2025-01-09T00:00:00+00:00 This post is a part of my "Zed is the Future?" series</a> Despite its name, I would argue that most time in a text editor is actually not spent editing. Instead, it is spent navigating between and within files that you are working with. Let's explore how to efficiently navigate with Zed! As a quick aside, I intend this post to be a living lab notebook</a> that I use to share my progress on the topic. Setup</h2> I will mostly focus on the keyboard-centric navigation, as this is my preferred setup. I use Zed Vim mode</a> and shortcuts below rely on it (by the way, you can find all available shortcuts in Vim mode by opening a Command Palette</a> and typing vim: open default keymap</code>). To add a bit of structure, I will distinguish between two different types of navigation: Local navigation: Moving and jumping within a single buffer to specific lines, words or characters</li> Global navigation: Moving between different files and searching across an entire project workspace</li> </ul> Local navigation</h2> Vim motions</h3> Local navigation is a bread and butter of Vim Motions</a> - the key shortcuts in Vim Normal mode that move the cursor to specific locations in the text. I won't describe them in detail, but there is an excellent guided tour</a> and a cheatsheet</a> that lists the most useful ones. Suffice to say that Zed implements them quite faithfully. There are also motions specific to Zed Treesitter integration</a> that are useful for navigating structured file formats, e.g., code or JSON. Here are the ones that I find most useful: w</code>/b</code>: move to the beginning of the next/previous word</li> CTRL + g</code>: move to a specific line number</li> /</code>, then n</code>/N</code>: search for a specific text in the buffer and cycle through the results forwards/backwards</li> gg</code>/G</code>: move to the beginning/end of the file</li> </ul> When I'm using Vim, I feel there is a gap that needs to be filled between very efficient navigation within a single line with f</code> motion and a bit more clumsy general search with /</code>. This gap is usually filled for me by EasyMotion</a>-style movement (specifically flash.nvim</a>) that allows to move to any visible character with just a few letter keypresses. Unfortunately, Zed does not have a built-in equivalent yet, but this is a very popular feature request</a>. Symbol outline</h3> Given the native Treesitter and LSP integration, symbol navigation feels quite reliable. CTRL + SHIFT + o</code> (or g s</code> in Vim): list and search symbols in the buffer</li> CTRL + SHIFT + b</code>: open and focus the symbol outline panel</li> </ul> Global navigation</h2> Workspace search</h3> CTRL + SHIFT + f</code>: opens a workspace-wide text search panel where you can type any text to find its occurrences across all files</li> g /</code>: automatically searches for the currently selected text across all files in the workspace</li> </ul> File search</h3> CTRL + p</code>: opens a fuzzy search dialog that lets you quickly find and open any file by name in the workspace</li> </ul> Symbol search</h3> g d</code>: go to definition of the symbol under cursor (e.g. a function name or variable)</li> g S</code>: search for any symbol (functions, classes, etc.) across all files in the workspace</li> </ul> Zed is the Future? 2025-01-06T00:00:00+00:00 "Zed</a> is a next-generation code editor designed for high-performance collaboration with humans and AI." I find this description from Zed's front-page very appealing and have been trying out the editor on and off for a few months now. So far, collaboration features have made it a tool of choice for mentoring and pair programming within my team. However, every time I considered a full switch for all my other editor use-cases, I lacked some critical features (see below) from my Neovim+Tmux setup</a> polished over the last 15 years. This time around, I have a good chunk of spare time between projects for sharpening my proverbial axe and I'm ready to sacrifice some productivity in the short-term to improve my habits</a>. So I decided to give Zed another try and this time learn to do things 'The Zed Way'. Moreover, I acknowledge that Zed is still under very active development and it will likely be that way for quite some time. So rather than evaluating it at this point in time, I'm interested to understand its long-term potential by learning more about foundations it is built upon, third-party extension tooling and the team and community behind it. I also just want to play around with Zed's codebase and try to implement the features I need myself, as I have never worked on an editor before :) To start off, here are some features that I currently miss: Faster navigation within a buffer page - I use EasyMotion/flash.nvim heavily to navigate within a single screen</li> Navigation between buffers - I use Telescope to switch between buffers and am still trying to get used to the mental model of Zed's tabs</li> More interactive search - I regularly search through hundreds of files with Telescope/FZF when I explore a new codebase</li> Persistent terminal sessions - I often develop on a remote server and rely on Tmux to have my workspace in the always-ready state</li> Keybinding discoverability - I struggle to find the necessary Zed keybindings (something like which-key.nvim could help?)</li> </ul> I plan to document my experience tweaking and hacking on Zed over the next few months in this blog. Bad muscle memory 2025-01-01T00:00:00+00:00 When we say "muscle memory", we usually mean it in a positive way - something that you've learned to do so well, you don't need to think about it. Today, though, I want to talk about the bad muscle memory - habits that are automatic, but actually are unproductive and prevent further improvement. The scary part about bad muscle memory is that it can be very hard to notice and correct. I recently switched to a new keyboard, first to Keyboardio Atreus and now to ZSA Voyager. Because these keyboards are much smaller, often only with 40% of the keys of a regular keyboard, I had to learn new positions for many keys. Moreover, these keyboards are fully programmable and encourage you to change the layout for your comfort. As I embraced the idea of tweaking the key positions on a whim, I came to a shocking realization that my most used keys are in terrible positions and I'm completely oblivious of this. Take for example the Enter</code> and Backspace</code> keys. They are used all the time in the regular typing, yet pressing them requires a really uncomfortable stretching hand movement. Similarly, I rely on many keyboard shortcuts that use modifier keys such as Shift</code>, Ctrl</code> or Alt</code>, and they are pressed with the weakest finger - the pinky. Once I moved these keys to more comfortable positions and to stronger fingers, it was a strict improvement and I can't imagine going back. Moreover, I was able to replicate most of the gains of the new layout on my laptop with kmonad</code></a> without any additional hardware. So the problem was really in my head and habits. This got me thinking, how many other things in my workflow and life are like this, and how do I go about discovering and correcting such bad muscle memory? The approach that have been working for me so far is to regularly try new things and get out of the comfort zone, for example: Write Advent of Code in the unfamiliar programming language like Zig</li> Try using a new code editor Zed instead of the familiar Neovim</li> Learn a new Graphite</a> keyboard layout instead of QWERTY</li> </ul> These exercises slow me down enough to start noticing my bad habits and motivate me to find ways to correct them. I'm sure there are many more ways to achieve the same effect, let me know</a> what works for you! Project Euler Streak 2024-11-18T00:00:00+00:00 I've just reached a 100 day streak solving a problem from Project Euler</a> every day. I've been a little worried that the difficulty will ramp up too quickly, but it happened to be just right - challenging enough to tickle my brain, but still manageable to solve within a day. I'm solving the problems exclusively in Rust, as this is my main working language right now. I implement all solutions from scratch without relying on external crates (e.g. for BigInts), as my main goal is to build the feel/muscle memory for elegant Rust code. To achieve this, I usually iterate on a solution for some time after solving the problem to make it as simple as possible. I plan to continue this streak until the end of November and then switch to solving Advent of Code</a>. I will likely use Zig for Advent of Code as I've been looking for an excuse to learn the language for some time now. You can find my solutions on Sourcehut</a>. Ludum Dare 56 2024-10-10T00:00:00+00:00 I recently participated in my 6th Ludum Dare game jam</a> and I want to share some reflections. This time around we've built a simple dexterity-based game called Animal Arcade</a>. Prefer simpler ideas</h2> During the initial brainstorming we came up with a list of three ideas and ended up choosing the one that was simplest to implement and iterate on. With games, there is a high chance that you will throw out the first few versions as unplayable garbage. And then you need to leave plenty of time to polish the final result. So I think going for simpler ideas is a good strategy if you want to ship something playable on a Game Jam with tight time constraints (72 hours). Iterate without fear</h2> It's surprising how easy it is to get attached to what you have already implemented and place yourself in the imaginary box preventing you from moving forward. You have to recognize this and be ready to discard what you've built and try a different path. In our game, the animals were shrinking over time and that was a core mechanic to make the game difficult. It was also a tied to the jam theme "Tiny Creatures", which is why we felt that we can't remove it. But there were a number of problems with this mechanic: Hard to come up with an explanation why the creatures were shrinking</li> Creature sprites looked ineligible at small scale</li> Past some size it was nearly impossible to hit the creature</li> </ul> We ended up removing the shrinking altogether and making the game difficult through other means (shooting delay, interesting movement patterns), but it took us some time to actually realize that this was an option. Leverage human perception</h2> Finally, some game mechanics really benefit or even work only with visual and sound support. When we introduced the delay between the user click and the shot landing on the screen, I was really surprised how disorienting even a seemingly small 0.3s delay felt. The game became too difficult but also didn't feel fun as my brain was really confused. Before abandoning the idea, I decided to add simple sound and visual cues - it suddenly became both easier and much more fun to time the shots. We ended up investing a lot more effort into the feel of this mechanic and I think it is one of the main reasons I enjoy the game. Final words</h2> I'm sure these ideas are not new, but sometimes you can only really feel them through experience - that's one of the reasons I love game jams, they always present this concentrated learning opportunity. If you have any similar reflections or comments, let me know on Mastodon</a>. Resistance Is Futile 2024-09-08T00:00:00+00:00 I have recently changed my name to Andrew Borg (from Kashin), so my personal page now lives at a new address - aborg.dev</a>. The previous address akashin.me</a> is still serving, but is now deprecated. I'm gradually migrating my other accounts, e.g. aborg-dev on GitHub</a>. Grid Game Toolkit 2023-12-27T00:00:00+00:00 I've always wanted to have a tool to quickly prototype various grid-based puzzle games like Crosswords, Sudoku, Hashiwokakero, etc. Sure, pen-and-paper can get you pretty far, and we used it extensively for our last Ludum Dare entry Skyland</a>, but it is a bit clunky to share when your playtesters are located remotely. After looking at many examples of such games (krazydad</a> has been an amazing resource), I think they all use a very similar vocabulary: A grid of fixed size (but possibly with irregular shape)</li> A fixed set cell types (with numbers, symbols, lines)</li> On-the-border or around-the-border hint system (using numbers or colors)</li> Solution can be fully expressed on the grid as a static snapshot (unlike many videogames like Sokoban or Snakebird where you need to record a sequence of actions)</li> </ul> So I decided to build the Grid Game Toolkit</a>, a framework for building such games with the following goals: Adding new games should be easy with minimal programming skills (e.g. with scripting or Rust trait implementation)</li> Should work well both on desktops and on touch-based devices (I really want it to work on my Android-based e-reader)</li> Can import puzzles from major providers like crossword newsletters and sites like https://www.nonograms.org/ as well as from PDF-based sources</li> Have built-in puzzle editor with a programmatic solution finder</li> </ul> It's a perfect opportunity to learn Rust better, so I will be using Bevy</a> game engine that worked well for our previous game jam. The MVP will support Japanese Crosswords, Sudoku and one more puzzle type. I hope this will be diverse enough to expose important design decisions, but also small enough to implement over the winter holidays. If you want to stay in the loop, I will be posting regular development updates on Mastodon</a> and will be using this blog for longer posts. Till the next time! Rebooting the blog 2022-09-07T00:00:00+00:00 It's time to dust off this blog and give it move love! As a first step I revamped the infrastructure behind it to get more comfortable with editing and deploying the blog. Previously, the blog was built with Jekyll, hosted in Google Cloud Storage Bucket and served with Cloudflare CDN. It had the benefit of fast load times and simple https certificate management, but the deployment process was far from ideal and involved manual rebuild and synchronization of folders to the cloud bucket. Since I've relocated most of my git repos to Sourcehut, I decided to try sourcehut pages</a> for hosting. This turned out to be extremely easy to set up thanks to an excellent guide</a> in Zola documentation. Overall, I'm quite happy with the new solution. It's easier and faster to deploy and also looks simpler from development perspective as I don't need to worry about version of Ruby and various plugins necessary in Jekyll. Building a compiler 2020-02-23T00:00:00+00:00 I finally decided to embark on the journey of building a real compiler to better understand how various pieces work under the hood. I'm particularly interested in error reporting, intermediate representation and code optimization. I'll be following the guidance from Crafting Interpreters</a> online book which so far proved to be quite easy to follow and full of fascinating facts from programming history. I'm planning not to follow the steps in the book too closely but rather pick the way that I feel makes most sense to optimize my learning and venture deeper into the topics I consider interesting. The first such change is using Python instead of Java for the interpreter implementation. As far as I can tell, this shouldn't be a big deal, but I hope it will help me to get a bit more familiar with Py3 and modern tooling like static type checking. As I go through it, I want to share some of the detours I'll be taking on this blog, so stay tuned! Neat tmux alias 2017-06-25T00:00:00+00:00 Trying to streamline my workflow with tmux</a> I've built a useful bash alias tmx</code>. This alias takes a single argument - name of the session, and connects to the session if it already exists, or creates a new session with this name. The motivation behind it is that it is shorter (no need to remember and type attach -t</code> or new-session -s</code>), and also involves less cognitive overhead (no conditional thinking). Here is a snippet of shell code that you can add to your .bashrc</code>/.zshrc</code>/etc: function tmx { name=$1 if tmux list-sessions | grep -q "^${name}:"; then tmux attach -t "${name}" else tmux new-session -s "${name}" fi } </code></pre> First, we list all available tmux sessions and then use grep</code> to look for the one, that has provided name. If this search succeeds, the return code of grep</code> is zero and we go to the first branch of the if</code> statement and connect to the existing session. Otherwise, the return code is non-zero and we go to the second branch that creates a new session. There is one tricky corner-case that needs to be considered, and I leave it to readers to discover it :) (what happens if there are currently no sessions?) With this alias, connecting to a tmux session Blog is as easy as: tmx Blog </code></pre> One additional big plus of this alias comes if you're using tmux over ssh connection (and who doesn't? :)). To connect or create a tmux session Blog on the remote machine you can use: ssh <hostname> -t tmx Blog </code></pre> For this to work don't forget to put tmx</code> alias to the top of .bashrc</code> if you're using bash or to .zshenv</code> if you're using zsh. Next step would be to extend tmx</code> to take arbitrary number of arguments, but honestly, I haven't yet encountered situation when I need it. This and other useful aliases that I'm using everyday can be found in my dotfiles</a> repository on Github. Thank you for reading, stay tuned! Let's start! 2017-06-17T00:00:00+00:00 After quite some time I finally decided to build a personal page and blog. I'm planning to post technical tutorials, fun facts, and other interesting discoveries that I'm encountering in my day-to-day life. I'm thankful to the maintainer of tufte-jekyll</a> for the awesome theme that is used to create this website.

aborg.dev

Calculation Solitaire

Zed: Keymap

Alternatives</h2> I've been wondering if there are alternatives that would be a middle-ground between the full Turing-complete configuration and the plain JSON files.</p>

Zed: Navigation

Local navigation</h2>

Global navigation</h2>

Symbol search</h3> g d</code>: go to definition of the symbol under cursor (e.g. a function name or variable)</li> g S</code>: search for any symbol (functions, classes, etc.) across all files in the workspace</li> </ul>

Zed is the Future?

Bad muscle memory

Project Euler Streak

Ludum Dare 56

Final words</h2> I'm sure these ideas are not new, but sometimes you can only really feel them through experience - that's one of the reasons I love game jams, they always present this concentrated learning opportunity.</p>

Resistance Is Futile

Grid Game Toolkit

Rebooting the blog

Building a compiler

Neat tmux alias

Let's start!

Symbol search</h3>

`g d</code>: go to definition of the symbol under cursor (e.g. a function name or variable)</li>`
`g S</code>: search for any symbol (functions, classes, etc.) across all files in the workspace</li> </ul>`