A UI shouldn’t lose your inputs.
This may seem obvious, but I often see applications that behave incorrectly if your inputs come too fast. One common situation where I see interfaces falter is keyboard shortcuts that bring you to a text input. Keypresses after the shortcut should always land in that input.
A common example is an app launcher. On GNOME I tap Super and type to search my apps. If I type Superfoo it should search for “foo” every time. GNOME works correctly here. No matter how overloaded and laggy my system is, and no matter how fast I type, the search is accurately captured. KDE’s KRunner does not pass this test. Oftentimes the first few characters of my search will land in the previously-focused application. I think this is because it is implemented as a separate process, and it can take a moment to start up and capture keyboard focus. macOS’s Spotlight also fails, although the failure window seems much smaller than KDE’s and required significant system load to hit.
Ghostty handles paste events asynchronously. Typing Ctrl+Shift+vEnter can trigger the Enter first, then the pasted text lands on the next line.
This occurs on web apps too. I’ll pick on Linear as they appear to have thought about this to some degree. Some shortcuts like a1 will reliably self-assign the ticket no matter how fast I type or how locked up my system is. Even complex interactions like mbCtrl+VEnter will mark the current issue as blocked by the issue in my clipboard. That is how it should work!
However, they aren’t perfect. /foo can have various behaviours depending on how fast you type. It should search for “foo” every time, but I have seen a few failures:
This can happen for mouse events too. For example Firefox has an excellent feature where after clicking the close button on a tab, the next tab’s close button will always land in the exact same spot. Even if the tabs were previously compressed because too many are open, they will wait until you move your mouse away to expand again. This way you can just keep clicking in the same location to close many tabs with ease.
But the tab closing animation ruins this! There is a gap in time where the old tab hasn’t gone away and clicks just disappear. So you can’t simply click 4 times to close 4 tabs, it may close fewer than you intended. You instead need to wait until the previous click is fully processed before performing the next click. This isn’t the worst failure mode but can make workflows where you close lots of tabs unnecessarily slow and annoying. Ctrl+W doesn’t appear to suffer this issue and always closes the right number of tabs.
This reminds me of the classic moving click target UX failure. This is the opposite of that: instead of the target jumping away as you try to click, the predictable target is instead not ready yet.
The main difficulty in implementing this correctly is that you need some sort of global input routing that buffers events until the application is ready for them. This can be quite difficult in browser applications as there is no way to “defer” input events other than completely blocking the main thread. So if follow-up keypresses are required you need to synchronously adjust focus, which may be difficult in your framework. This typically also precludes any form of lazy loading. Alternatively you would need to implement your own focus and input event handling logic, which is almost certainly a bad idea.
Asynchronous work is a complicated case in general, because buffering inputs for an extended period is confusing to the user. What if that work can fail? Do you drop the buffered input events? Or feed it to the previously focused input control? Do you need some sort of timeout? Luckily I find that this case is very rare. (Although the clipboard example above is one of these cases.)
If you have any sort of UI automation, this is easy to test: feed the keys in as a single batch and be sure that your app handles them properly!
Typing speed shouldn’t affect functionality! Keyboard shortcuts are designed for people to go fast, nothing will harm your productivity more than familiar keyboard shortcuts doing something unexpected! (Bonus points if those inputs aren’t lost, but trigger a completely different action like “delete”.) It is easy to say that it is a 2 millisecond gap and no one will hit a window that small, but that gap may be much larger on a low-end machine swapping like crazy. Or maybe my local LLM is hogging my GPU for a second or two. Don’t let fingers race your UI, just close the gap.
]]>I randomly had the idea that it would be interesting to “dig into” all possible Sudoku puzzles. So I created Digdoku. The landing page is an “empty” puzzle, each link leads to a puzzle with one additional square filled. Values that are not possible are excluded. So you can never get an invalid puzzle by clicking links (but you can by editing the URL).
The concept is simple. Basically for every unset cell it attempts to solve the puzzle with every number from 1-9. If any solution is found that value is possible, otherwise it is omitted.
This “eager” removal of impossible values means that it functions as a solver as well. By the time you click all of the provided squares (or often sooner) there will be only one possible grid, and it will be revealed.
However, implementing this simple solution is fairly slow. So some optimizations were necessary. These are primarily around skipping options that are easily determined to be impossible or were already found to be possible. The solver is still mostly a brute-force depth-first solver with some very basic rules put on top (such as eliminating duplicate values in a box/column/row group and if a value can only be in one place as a group it must be that).
The slowest case I am aware of takes about 100ms on my desktop. It could almost certainly be much faster, I suspect another order of magnitude would be fairly easy to achieve. But in the first version some cases took over six minutes, so I’m calling it good enough for now.
One downside is that the URL only keeps minimal state, so a lot of options need to be re-eliminated every step of the way. Maybe compiling to WASM and running an incremental solve client-side would be better. Might be something interesting to try. It would also avoid the risk that my single-core VPS gets overloaded if this gets popular. I do have caching enabled, but I suspect after a few clicks hits will become quite rare.
There is also something about a simple HTML response that I am very fond of. Theoretically you could pre-render every possible grid into a static site. But according to Wikipedia there are 6.6e27 valid Sudoku grids, so I’ll hold off on the pre-render for now.
]]>PostgreSQL major version upgrades are something that NixOS currently doesn’t handle for you. This is my process, documented mostly so that I can remember it next time I want to upgrade.
I use the standard NixOS module for Postgres. My main config looks like this:
Notable features:
Log in as the postgres user. (sudo -su postgres)
Define the old version old=16
Get the old and new versions:
Initialize the new data directory. Be sure to use the arguments from your config!
Copy the configuration (this is really only needed if you have extensions that need to be loaded, the main value we care about is shared_preload_libraries. But copying the whole file is easiest and the NixOS module will overwrite it anyways when starting the new version.).
Run the check
Stop the old Postgres. systemctl stop postgresql
Run the migration. This is the same command as the check without --check.
Start the new PostgreSQL server. (This is typically done by activating the new configuration such as sudo nixos-rebuild switch.)
At this point the new version is running. Note that rolling back will cause data loss as new changes are being made only to the new data directory.
You may wish to rename the old directory so that if you do accidentally roll back it is more likely that things fail rather than losing data. But if you have insecure apps that let the first user be admin that may be a bad idea. Maybe you could do something like put a file there or a directory owned by root? But I haven’t tested any of these things.
As suggested by pg_upgrade run vacuumdb --all --analyze-in-stages.
At some point in the future once you are confident that the new DB is running fine (a few weeks doesn’t hurt) you can remove the old data.
I’ve been taking a few timelapse videos recently and as an amateur I’ve just been using the default phone camera apps. Google Camera defaults to “Auto” for the speedup, which keeps the resulting video between 15 and 30s no matter how long you record for (with minimum of 5x speed). It also offers explicit 5, 10, 30 and 120x speeds. The iPhone forgoes explicit options and only offers an auto mode with 20-40s output target and a 20x minimum speed.
Both of these apps have a limitation that they can only output 30 fps video. That seems like a missed opportunity since the faster than real time playback already tends to produce jumpy video. Getting 60 fps (or even 120 fps) makes a huge improvement to smoothness. The hardware can easily support these output framerates as the capture framerate will still be lower than regular speed videos.
My preferred approach is to record the video at “twice the duration” as I actually want, then to speed it up after the fact. Recording at a higher input framerate always gives you more flexibility as you can always speed it up later, and if you carefully pick your input framerate you can do this losslessly to avoid degrading the video quality.
For example, if I want to end up with a 1 minute 60 fps video covering 1 hour of real time. I need to record at which is 1 fps. Google Camera doesn’t show you the framerate directly, but you can easily convert the input speeds to framerates. Since it always expects to output 30 fps the calculation is just , so to capture at 1 fps I need to select 30x speed.
To losslessly convert the video you can use ffmpeg bitstream filters.
This can easily be adjusted to other framerates by changing the -r and -bsf:v values.
I think this is an unusual opinion, so I thought I would share.
I prefer not to import external symbols into the local scope. For example, I prefer:
over
There are various reasons for this, but all the most important ones boil down to being unambiguous. When I am reading code I see library::Foo and know that it comes from library. I see crate::Foo and know it comes from elsewhere in my code and if I see just Foo I know it is from the current file (and possibly private, so I could be a bit more careful with how I use the API). I don’t need to guess or lookup what Foo I am working with. (And when I do inevitably guess I don’t need to have that background process asking “did I guess wrong?”)
I find when I am working on codebases where the convention is to import things I am very frequently tracking down the definition of some type or function as I don’t know whether it is local or from which library. This is especially painful when reading or reviewing code in a web interface. If you are reading a patch the imports are likely not expanded (if they didn’t change) and even if you have the whole file expanded you need to check if the referenced value is the global import from the top of the file or some local shadow.
Another thing I love about fully qualified names is that I can just copy and paste code around or move it from file to file without needing to figure out which imports are needed in the new file (and inevitably importing the wrong Error at least a few times). For the most part code in other files and examples online can just be pasted into the file and work.
It’s not some dramatic productivity boon, but it certainly makes cleanups and refactors much smoother and a frustrating tedious step that is necessary when working with import-heavy code.
In some cases they are. But more often than not this is just a poor choice by the library author (in my opinion). For example in Rust the standard hash-map is std::collections::HashMap. But even that is just an alias. If you want to work on an Entry you are now typing std::collections::hash_map::Entry. I see no reason it couldn’t have been std::HashMap and std::HashMapEntry or std::HashMap::Entry. (I don’t mind a small amount of nesting when it is very strongly associated, but still don’t really see much point.)
I much prefer C++‘s style where almost everything is just under std. For example std::unordered_map. An iterator is slightly nested at std::unordered_map::iterator but if you ask me that is still a pretty reasonable name. And I would much rather see that in code than wonder what iterator we are working with.
If it hurts stop hitting yourself, don’t find a way to numb the pain.
I see this come up as an argument against, and I am pretty dumbfounded. Some people see that you have std::io::Error and std::fmt::Error. So they can’t both be std::Error. But that is kind of my point! When I see code referencing Error I don’t know which error type from the dozens of libraries that the code might be using it is! That is what makes the {library}::{name} pattern so great, it is conflict free. If I use that throughout my code I never have to worry if Write is std::fmt::Write, std::io::Write or crate::Write because it is spelt out! I would much rather the types be actually named std::FmtWrite and have everyone “agree” on the name (because they have no choice) than half the time having it called Write and half the time having it called FmtWrite, WriteFmt or DebugWrite (because some other Write was in scope and the programmer needed to come up with their own name).
This isn’t an imagined problem. I regularly find myself reading rustdoc documentation and needing to hover over a type name so that my browser displays the fully qualified path in the link target! I feel that which Error or which Write is being used is important enough that it be immediately visible, in both code and generated documentation.
Avoiding imports means that the library authors are responsible for solving conflicts. And we are back to the fact that when I see a type or function it is unambiguous and I don’t have to waste brain cycles figuring out what Error I am looking at.
I’m not a stickler to this rule. There are some cases where I will use imports. Sometimes the names are just too long and repetitive. In that case I strongly prefer a local use with a short scope. This ensures that I don’t need to look far to resolve the ambiguity.
(And more often than not when I run into this case it isn’t because the name is intrinsically high-entropy, but because someone got carried away with hierarchy. Stop hitting yourself.)
I’ve been using Rust as an example but been trying to avoid being Rust-specific. But it is my primary language, so I do have some thoughts to share. If you don’t care about Rust you can stop reading now.
Avoiding imports in Rust is going against the grain. I would recommend that all crates provide a flat API. However, for many projects avoiding use isn’t the right choice. Just follow the common coding convention and be happy. To see a real-world example of both a flat API and avoiding use you can check out rl-core which is a small project where I am quite glad I chose to break convention. A lot of my “for-me” or “internal” code is written in a similar style.
By default, Rust wants to ship your file structure as your exports (Conway’s law). So for example mylib::Foo needs to be defined in src/lib.rs and mylib::submodule::Bar needs to be defined in src/submodule.rs or src/submodule/mod.rs.
With a single re-export per module this can be solved!
One extra statement to free you from hierarchy. Re-exports are well-supported by Rust so rustdoc and the compiler will pick mylib::Config as the path to show users rather than mylib::config::Config. (I don’t know the exact heuristics but when working like this there will be a single public export, so there isn’t much cleverness needed.)
pub use also only sets the maximum export visibility. This means that pub, pub(crate) and private things in the module will have the expected visibility. So the definitions in the files look the same as they normally would and the export lines only need to be added when you add or remove modules.
The only real downside of this approach is the src/lib.rs will see everything as local and can reference Config rather than crate::Config. But this is a very minor issue and the solution is not to put anything into lib.rs. (Keeping only module definitions and re-exports in lib.rs is a very common pattern anyways.)
The nice thing about just re-exporting everything is that it also frees you from deciding where to put things based on what you want the exported name to be. You don’t need to put std::collections::hash_map::HashMap and std::collections::hash_map::Entry in the same file to have them appear at the same place, you can put them into separate files if you wish or the same file if you need access to non-public APIs. (The Rust std implementation does actually re-export these from various places, re-exports are very common and not something to be feared.)
Personally I just put every single type and most functions into separate files. I find that it keeps everything simple and organized and I prefer switching between different files than different parts of a file when going back and forth. So for example in rl-core I define rl_core::Config in src/config.rs and rl_core::Tracker in lib/tracker.rs.
Traits are where things start to get hairy. To call a trait method as a method the trait needs to be in scope. So if you want to call foo.a_method() where a_method is somelib::TheType::a_method you need to use somelib::TheType.
However you always have the option to call the method using a fully-qualified path. For example somelib::TheType::a_method(&foo) or <Foo as somelib::TheType>::static_func(). For the occasional method call I often do this because I do like seeing where .a_method() comes from, it isn’t always clear if it is a method directly on foo or which trait defined it. However nesting a few calls with this quickly becomes messy and sometimes I make a practical choice to just use the use. I prefer to do this just for a short scope to help keep the origin information close to the code, but for very common traits I will sometimes add a global import like use std::io::Write as _ (make the trait methods available but don’t actually pull the name into scope).
stdThe elephant in the room is that in Rust std (and core) love love love hierarchy and lots of names are super long. I wish I could have a long talk with whoever decided it was really important that std::sync::atomic really needed to be nested under sync. I think we would have been fine to reserve the top level std::atomic for these operations even though they are synchronization related.
It is what it is. I’m not going to advocate for The Great std Naming Reform even if I would prefer it. We have a pattern, and we can deal with it. Most of the names aren’t so long that they need to be imported so most of the time I just spell them out. Occasionally I find myself repeating a long name frequently and just import it. I have yet to be stricken by a bolt of lightning from the heavens.
]]>Over the past year I’ve been on a small adventure to find some excellent Fish & Chips in Toronto, Canada. While I haven’t found the perfect chip shop I have gone to a handful of the most popular places and would like to share what I learned.
I’ve been to quite a few restaurants, but I’m only going to discuss the ones that stand out. I don’t think you will be disappointed by any location on this list.
lenduckworthfishandchips.ca - Last Visited 2025
Thanks to Mark Prosser who sent in this recommendation after the initial list post went out. This one had managed to escape my searching but I eagerly gave it a try.
The fish was excellent, I tried the halibut as they claim it to be their specialty, and it did not disappoint.
The chips were also stellar, if I really nitpick they could have been slightly crispier, but they were great as they are with a crisp outside and fluffy inside.
We shared the Sumptuous Seafood platter and everything on it was top notch. The shrimp was super flavourful and while I rarely enjoy battered scallops these were really good. I would strongly recommend this platter which fairly easily serves two. We also got a side of calamari which was also amazing with some sort of curry mayo dip. To top it off we got the pumpkin pie which was also delicious.
oldeyorkefishandchips.com - Last visited 2025
This is probably the location that I have seen recommended the most. And for good reason! This place serves probably the best battered fish I have ever had. We tried the Cod and Haddock, both were great. The cod was more flavourful, but the haddock was closer to a classic white flaky fish. I definitely want to go back and try the halibut.
The chips however were a bit mediocre. Not bad by and stretch, but when it says “chips” above your door I expect better. The outside was a touch tougher than I would like, and the inside wasn’t fluffy like it should be.
We also tried onion rings and a deep-fried Mars bar which were both fantastic. (I don’t know if they allow subbing in onion rings for the chips but if they do, I would recommend that.)
mcnies.com - Last visited 2024
This is an old classic of mine as I practiced karate next door for many years. It seems to mostly fly under the radar online, but I think it deserves to be better known. The highlight here is definitely the chips. They are just perfect with crispy outside and fluffy inside.
The fish however isn’t as good as it could be. The batter in particular is a bit breadier than I would like as opposed to being super light and crispy.
Other things I have tried are the onion rings, which are possibly my favourite ever (I’m super picky about rings) and the scallops which I wouldn’t recommend (but I don’t think battered scallops are my cup of tea).
seawitchfc.com - Last visited 2024
This is also an online favourite. One of the easiest to get to as it is just a streetcar or short walk from the 1 subway line. They also have an awesome mural on the side of the building, so it is hard to miss.
While I enjoyed my meal here it did not stand out in any way. Solid fish and chips that I would definitely go to often if I lived nearby, but if you are going out of your way I would probably try one of the other options first.
I prefer Len Duckworth’s overall. The fish may not have quite been as good as Olde York but it was still excellent and everything else was top of the charts. It is also just a short walk from Main Street Station which makes it very easy to get to from basically anywhere in Toronto. Second place goes to Olde York, the fish is just that good, and I can get great chips elsewhere. McNie’s still has a place in my heart and I would probably go from-time to time if it wasn’t so far away from where I live. While Sea Witch is solid all around I think I would only go back if I was in the area, if I am going out of my way I would probably find something new first.
Did I miss your favourite? Let me know and I’ll update the list after some thorough research!
]]>Anyone who has had an outdoor cat will have experienced a thoughtful gift left on your doorstep in the morning, usually a dead bird or mouse. These gifts are made with love, and take effort to acquire and return to your doorstep. However, us humans generally do not appreciate them.
I often find similar features in software. For example, the wiki that our company uses recently released a new feature: when you copy from a document it would format the copied text as Markdown. For example if I copied part of a code snippet inside a second-level list it would be formatted as:
Whoever implemented this feature clearly worked really hard to ensure that parent context like the two lists above were included in this copying. However ultimately it isn’t what users want. When copying the entire list keeping the formatting could be useful, however when copying just one word the context is typically not desired. In this case the result is that I can’t paste it into my terminal.
Often these features are technically interesting. It is a fun coding project to take a snippet of the document and turn it into accurate Markdown. It is easy to forget to take a step back and think if the user actually wants this.
I find that these features often occur when overriding default behaviours. Web apps are a common culprit. Overriding copying is a common example, but also overriding spell checking, form filling, link following or undo. Many times there is a key feature that the developer wanted to provide, and they made impressive effort re-implementing browser behaviour. At best the feature is useful, but the reimplemented browser behaviour falls short of native. But very often the feature that was provided isn’t actually even helpful.
]]>