Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Making software better without sacrificing user experience.
Bringing dwm Shortcuts to GNOME 2023-11-02 The dwm window manager is my standard "go-to" for most of my personal laptop environments. For desktops with larger, higher resolution monitors I tend to lean towards using GNOME. The GNOME DE is fairly solid for my own purposes. This article isn't going to deep dive into GNOME itself, but instead highlight some minor configuration changes I make to mimic a few dwm shortcuts. For reference, I'm running GNOME 45.0 on Ubuntu 23.10 Setting Up Fixed Workspaces When I use dwm I tend to have a hard-set amount of tags to cycle through (normally 4-5). Unfortunately, dynamic rendering is the default for workspaces (ie. tags) in GNOME. For my personal preference I set this setting to fixed. We can achieve this by opening Settings > Multitasking and selecting "Fixed number of workspaces". Screenshot of GNOME's Multitasking Settings GUI Setting Our Keybindings Now all that is left is to mimic dwm keyboard shortcuts, in this case: ALT + $num for switching between workspaces and ALT + SHIFT + $num for moving windows across workspaces. These keyboard shortcuts can be altered under Settings > Keyboard > View and Customize Shortcuts > Navigation. You'll want to make edits to both the "Switch to workspace n" and "Move window to workspace n". Screenshot of GNOME's keyboard shortcut GUI: switch to workspace Screenshot of GNOME's keyboard shortcut GUI: move window to workspace That's it. You're free to include even more custom keyboard shortcuts (open web browser, lock screen, hibernate, etc.) but this is a solid starting point. Enjoy tweaking GNOME!
Installing Older Versions of MongoDB on Arch Linux 2023-09-11 I've recently been using Arch Linux for my main work environment on my ThinkPad X260. It's been great. As someone who is constantly drawn to minimalist operating systems such as Alpine or OpenBSD, it's nice to use something like Arch that boasts that same minimalist approach but with greater documentation/support. Another major reason for the switch was the need to run older versions of "services" locally. Most people would simply suggest using Docker or vmm, but I personally run projects in self-contained, personalized directories on my system itself. I am aware of the irony in that statement... but that's just my personal preference. So I thought I would share my process of setting up an older version of MongoDB (3.4 to be precise) on Arch Linux. AUR to the Rescue You will need to target the specific version of MongoDB using the very awesome AUR packages: yay -S mongodb34-bin Follow the instructions and you'll be good to go. Don't forget to create the /data/db directory and give it proper permissions: mkdir -p /data/db/ chmod -R 777 /date/db What About My "Tools"? If you plan to use MongoDB, then you most likely want to utilize the core database tools (restore, dump, etc). The problem is you can't use the default mongodb-tools package when trying to work with older versions of MongoDB itself. The package will complain about conflicts and ask you to override your existing version. This is not what we want. So, you'll have to build from source locally: git clone https://github.com/mongodb/mongo-tools cd mongodb-tools ./make build Then you'll need to copy the built executables into the proper directory in order to use them from the terminal: cp bin/* /usr/local/bin/ And that's it! Now you can run mongod directly or use systemctl to enable it by default. Hopefully this helps anyone else curious about running older (or even outdated!) versions of MongoDB.
Converting HEIF Images with macOS Automator 2023-07-21 Often times when you save or export photos from iOS to iCloud they often render themselves into heif or heic formats. Both macOS and iOS have no problem working with these formats, but a lot of software programs will not even recognize these filetypes. The obvious step would just be to convert them via an application or online service, right? Not so fast! Wouldn't it be much cleaner if we could simply right-click our heif or heic files and convert them directly in Finder? Well, I've got some good news for you... Basic Requirements You will need to have Homebrew installed You will need to install the libheif package through Homebrew: brew install libheif Creating our custom Automator script For this example script we are going to convert the image to JPG format. You can freely change this to whatever format you wish (PNG, TIFF, etc.). We're just keeping things basic for this tutorial. Don't worry if you've never worked with Automator before because setting things up is incredibly simple. Open the macOS Automator from the Applications folder Select Quick Option from the first prompt Set "Workflow receives current" to image files Set the label "in" to Finder From the left pane, select "Library > Utilities" From the presented choices in the next pane, drag and drop Run Shell Script into the far right pane Set the area "Pass input" to as arguments Enter the following code below as your script and type ⌘-S to save (name it something like "Convert HEIC/HEIF to JPG") for f in "$@" do /opt/homebrew/bin/heif-convert "$f" "${f%.*}.jpg" done Making Edits If you ever have the need to edit this script (for example, changing the default format to png), you will need to navigate to your ~/Library/Services folder and open your custom heif Quick Action in the Automator application. Simple as that. Happy converting! If you're interested, I also have some other Automator scripts available: Batch Converting Images to webp with macOS Automator Convert Files to HTML with macOS Automator Quick Actions
Running VSCode in Chromium on OpenBSD 2023-06-05 VSCode and its many variations are not available on OpenBSD. This doesn't cause issue with many OpenBSD users, but those making the jump from Linux might miss access to such a popular editor. Lucky for us, there is a hacky workaround to solve this problem. VSCode in the Browser I tried my best to build something like code-server locally and run that directly in my browser - but I failed miserably. Instead, I fell back on vscode.dev which is essentially a remote version of code-server. Getting things to work seamlessly proved a little more challenging. I found the best performance was running everything through Chromium with special parameters enabled on launch. Note: The following assumes you have already installed chromium First we need to disable unveil for Chromium. This will allow us to access our system files through vscode.dev using the "Open folder..." or "Open file..." commands without issue: chrome --disable-unveil Everything should work pretty solid right out the box now - except it doesn't. Syntax highlighting does not work without enabling WASM/WebAssembly. Your experience might be different, but I had to include the following when launching Chromium from the terminal: ENABLE_WASM=1 chrome --enable-wasm Success! We can avoid typing out these complex commands everytime we want to launch our editor by setting up an alias (in my case via .zshrc): alias vscode="ENABLE_WASM=1 chrome --enable-wasm --disable-unveil" That's it! Now I can just pop open VSCode on OpenBSD by simply running vscode in my terminal. Hopefully this can help others slowly transition over to OpenBSD - which you should do because it is amazing!
Converting My X201 ThinkPad into a Slabtop 2023-05-01 I recently wrote about physically disabling the WiFi toggle switch on my X201 which was a fun "hack" to an annoying issue I was running into. Since then, the laptop has been running flawlessly. The only other minor issue I had was the poor display quality. The screen works perfectly fine but the X201's age prevents it from being the best possible display for day-to-day tasks. Both the resolution and viewing angles are quite poor. So, what were my options to remedy this problem? Swap out and upgrade the laptop's display (not many options for this though) Connect an external display, keyboard, mouse and dock the X201 Something else? Looking into "Something Else" I found that the possible replacement screens weren't worth the cost/hassle to swap out. And setting the laptop aside, docked with external peripherals sounded fine in theory - but then I would be missing out on the X201's amazing classic keyboard... Then I thought to myself, "Why not just remove the display entirely?" So that's what I did. The X201 display (still inside the top lid) disconnected from the body of the laptop. Removing the entire top lid was easier than I initially thought it would be. The beautiful thing about these older, classic ThinkPads is the ability to completely dissemble them. I won't go into heavy details on how to take one of these machines apart, since great documentation already exists. But once you have the keyboard and hinge screws removed it is essentially as easy as lifting the lid out of the chassis. (After disconnecting the small display connectors, of course) Ditching Alpine for Debian I love Alpine Linux. It's normally my go-to distro (paired with dwm) for most of my laptop devices. Unfortunately, I find tiling window managers a slight pain to use on larger, 4K displays. I also wanted this slabtop to "just work", instead of needing to fiddle around with WiFi, xrandr, audio etc. Not to mention that Debian is rock solid stable. Defaulting to the XFCE DE was a no-brainer as well since this device is somewhat old. The X201 "slabtop" connected to my 27" 4K monitor via the ThinkPad UltraDock. Closing Thoughts This slabtop gives me those old-school "Commodore64" vibes (or more recent devices like the Raspberry Pi 400). This setup certainly isn't for everyone but for my use case it's working well. Traveling with a machine like this might prove a little more challenging - although you could simply pair it with a smaller travel monitor (I'm sure the overall carrying weight would be similar to the standard X201). If nothing else, it is good to keep this option in mind if you ever break your laptop's display and don't feel like spending the money to fix it. Just grab an external monitor you have laying around and make a slabtop!
More in programming
Once a year at my church, I usually give one sermon. I was asked to tie the theme to a young adult retreat we had taken to the Sunshine Coast. My first experience giving a sermon was many years ago at my old home church in El Monte, California. It was a Vietnamese-American church, but…
As with my last post on AI, let me open with a statement: Just because most people hold AI a certain way, doesn’t mean that we always must, either now or in the future. As I noted in that piece, and my shades of gray post, I am well aware — and agree with — … Continue reading Must we always use LLMs this way? →
The CSS Working Group resolved to use cursor: pointer for buttons and other clickable form controls in the new appearance: base styles. That happened on October 21, but I posted about it yesterday and, uh, people have feelings about cursors. I wrote about buttons and cursors back in 2022, when a post titled "Buttons shouldn't have a hand cursor" was making the rounds. I admitted I didn't have a strong opinion either way, then argued that not using the hand cursor had become the new anti-pattern anyway. The web isn't an operating system, and people expect clickable things to show a hand. The issue is Cursors For Base Appearance in CSS Forms Level 1. The group adopted the rules from this comment, and the part that's triggering half the Web is: select, option, input[type=checkbox], input[type=radio], button, input[type=button], input[type=submit], input[type=reset], input[type=color], input[type=image], ::file-selector-button { cursor: pointer; } It seems like we have a tabs vs. spaces sort of debate. Again. Nicole Sullivan pulled cursor data from a bunch of design systems and, in September, 27 of the 33 systems that set a cursor used pointer. After she added more systems, it was closer to a 50/50 split. Elika Etemad made the usability case in the meeting. Per the minutes, she said the hand "makes it clear, as soon as you're hovering an interactive control, you're supposed to click on it," and called it a "usability benefit even if not historically done on some platforms." "But the hand means it's a link" Haz had an interesting reaction: The debate is over, and evil has won. His point is that he can't tell whether ⌘-clicking something will open it in a new window anymore. He feels more confident clicking a button when he knows it won't change the URL, like when it just opens a popover or a panel. He's not wrong about that.* I replied that I've been on team evil since 2022 (albeit without a strong opinion, just following what users seem to expect). Touch screens don't have a cursor at all, and on desktop, browsers show a link's URL in the corner when you hover it. That's some type of hint, at least. Haz pushed back that he'd have to watch the bottom-left corner with his peripheral vision, which is fair. He also said he never cared which cursor buttons got, he just wanted links to have their own. I can appreciate that. "But desktop apps don't do it!" Jacob Paris liked the standard cursor on buttons because it makes web apps feel more like desktop apps than websites. My opinion hasn't changed, though. People have already learned that a hand cursor means clickable on the Web. It's by no means mandatory, but it's familiar and satisfying, so it stuck. Either way, nothing changes today. The resolution only covers appearance: base, which browsers haven't shipped yet. Buttons and selects still use appearance: auto, and their cursor is still default. If your CSS reset, design system, or web components already set cursor: pointer on buttons, keep it. When appearance: base ships, controls that opt in will get the same cursors by default. But remember, these are only defaults! You can still add whatever cursor you want to whatever element you want. Nobody's gonna stop you. In 2022, I said I'd keep changing the cursor on buttons until there's a good reason to stop. In 2026, I still haven't found one…and neither has the CSS Working Group. *Thinking about this more, if 50% of design systems opted to add cursor: pointer to buttons already, isn't this already a moot argument? **In general, I think the Web should be more personal and expressive so who even cares about a default? This is especially true for personal and fun sites. Just don't go too crazy, especially when it affects accessibility and the overall user experience.
TokyoDev has grown substantially over the past few years. We’ve expanded our community, dramatically increased the scope and frequency of our events, and have curated a library of articles for international developers. Despite all that, the way we run the business hasn’t changed much. I’ve continued to coordinate most of these activities myself, making the final decisions and keeping everything connected. In short, TokyoDev cannot run without my daily input. That approach worked well when TokyoDev was smaller, but it’s increasingly limiting how much we can accomplish. To help the business grow further, I wanted to find someone to take over some of my responsibilities and bring a fresh perspective. This is a significant step for me personally, as while I have worked with many contractors over the years, I have never actually hired a regular employee. Most importantly, I wanted to ensure that this person was someone I could trust to understand what TokyoDev stands for, and to make decisions in line with our philosophy. So I’m happy to announce that Scott Rothrock is joining TokyoDev full time as our Head of Operations. About Scott Scott has lived in Japan for nearly 20 years and has worked as a software engineer in multiple industries and environments, including small Japanese-owned businesses, overseas employers, and international companies based in Japan. Until the end of October 2026, he was the head of the Japan Markets team at Kraken Technologies, where he led an international team of software engineers in delivering complicated, regulated products on strict timelines for Japanese electricity and gas retailers, while also ensuring compliance with evolving organizational and global standards. He’s made a name for himself both inside and outside Japan as a kind, effective mentor who can cultivate great engineers and leaders. Scott’s previous role in TokyoDev Some of you may already know Scott in another capacity, as he has been involved with TokyoDev since 2022. He began as a community volunteer and later became our community manager, which also included responsibilities such as managing our article pipeline from submission to publishing. When I created TokyoDev’s Discord, I had no previous experience running an online community. Scott joined soon after I started and began helping other members, stepping in when people behaved inappropriately, and configuring our roles and permissions and safety features. I was impressed by his initiative and asked him to become an official moderator in January 2023. Outside of his role as a moderator, Scott has always pushed TokyoDev to grow; for example, he arranged internet events such as livestreamed AMAs and interviews. He organized TokyoDev’s first meetup as a volunteer in February 2023, which taught me that there was interest in TokyoDev events outside of the internet. By the end of 2023, I had brought him on as our part-time community manager. What I saw throughout his tenure was that Scott continued to take initiative in expanding TokyoDev. Scott was one of our first external contributors, writing about his experience living with a disability in Japan. He encouraged me to expand and refine both our editing and submission processes so that we could reach out to even more contributors and platform their perspectives. The editorial team now consists of him and Rebecca Callahan, and they’ve had a hand in every article that TokyoDev has published. In other words, since 2022, Scott has shown that he cares about TokyoDev as much as I do. He is invested in what we do and why we do it, and shares my vision for what TokyoDev can become. What changes now Scott’s experiences as an engineer, a mentor, and a leader make me confident that, as our Head of Operations, he will continue to help TokyoDev mature. A big part of what has made TokyoDev successful is that I see the software developers who use our site as my peers and genuinely want to help them. Scott shares that perspective, and will join me in ensuring that TokyoDev remains true to its principles while we grow. So what changes in the short term? Nothing dramatic. I will teach Scott about managing TokyoDev as a business, and he will document our processes and products as a part of that learning. He will also look for areas of improvement while ensuring that we remain compliant with regulations and labor law. Over time, I will hand over some other responsibilities. I will continue to run TokyoDev, but TokyoDev will become less dependent on me for its day-to-day operations. Long term, I’m excited about what this will enable us to do. TokyoDev has always been about helping international software developers build successful careers in Japan, and bringing Scott on full time puts us in a much better position to continue doing that. We look forward to writing the next chapter of TokyoDev together.
