A New Perspective on Typing

Now that I have more time on my hands thanks to the summer holiday, I’ve been looking into a thing that I’ve been interested in for a while: alternative keyboard layouts. A few years back, I learned touch typing, and it’s massively improved my ability to type. Already, I was a fairly quick typist with a manner of ‘hunt-and-peck’ typing, using three fingers per hand to reach around 110 words per minute. However, it was also somewhat error-prone, and caused undue strain for only a small set of fingers. So, a while back I learned how to properly use touch typing, which slowed my typing speed a bit but increased my accuracy while decreasing strain.

One thing that I learned while learning touch typing is the fact that the qwerty-layout of most English-language keyboards was designed to slow down typists to avoid typewriters jamming up because of people typing too swiftly. Computers, clearly, don’t have this concern anymore, though most English-language keyboards do still use the qwerty-layout. So, some people have worked on changing the layout to increase typing speed once more, resulting in layouts such as Dvorak and Colemak, which focus on putting more common letters right on the home-row (the central row where your fingers rest with touch-typing).

The past week or so, I’ve been learning about Colemak via learncolemak.com and practicing with this new layout over on keybr.com. I was quite happy to discover that switching keyboard layouts is tremendously easy in Linux, requiring just a simple command:

setxkbmap -model pc104 -layout us -variant colemak

As you can imagine, switching back just involves the same command but without the listed variant. The only thing remaining is that the actual letters on the keys would then be incorrect. However, since touch typing involves learning all the keys through muscle-memory, there’s no point in looking at the keys in any case. In the long run, though, since I do have a Keychron K2 mechanical keyboard, I could just switch the keycaps over to a Coleman layout if I would be interested.

Still, it’ll take quite some daily practice before I’m comfortable enough to switch over like that. For the time being, I may end up using the following command to easily switch between three separate layouts:

setxkbmap -model pc104 -layout us,us,us -variant ,intl,colemak -option grp:alt_shift_toggle

Using this snippet in my i3wm configuration file, I can use alt+shift to on-the-fly change between standard qwerty-layout, an international “dead keys” layout that allows me to use punctuation to insert diacretics for typing in Dutch, and the Colemak keyboard layout.

I’m looking forward to seeing how this new layout will be treating me. In the meantime, I’ll keep on enjoying how easy things are to set up in Linux (never thought I’d be saying that, but here I am!).

Unexpected Learning

Lately, I’ve been playing a bit of Cities Skylines, a city-building simulation game where you are a mayor tasked with building up a city from scratch (so, really, you’re a city planner). It’s quite a complex game, even without all the DLC, so I went to YouTube to help find some more information on how to play properly. I was quite happy to find that a YouTuber named City Planner Plays has a set of tutorials up, and as you may expect: he’s a city planner giving his perspective on how to do this. The thing that’s really interesting about this is that it doesn’t just teach me how to play the game, but he also discusses some actual city planning every now and then, such as the key difference between arterial, collector, and local road networks.

I can highly recommend his tutorial to learn more about Cities: Skylines:

FreeCAD Tutorial

Over the past week or so, I’ve been following a YouTube tutorial for FreeCAD by a YouTuber calling himself Adventures in Creation. It’s been an amazing set of videos so far that starts all the way from how to download the program to the latest video, dealing with making a small engine out of individual components. I’ve gotten all the way from not knowing how the program works to being able to set up a basic part, ready for 3D printing. If, you know, I had a 3D printer (someday, printer . . . someday).

In any case, I wanted to link to that tutorial here, for anybody who wants to have a great introduction to FreeCAD:

A little bit of experience

When I started this blog, I mainly did it as an outlet for my thoughts. I wanted to have a place to put my experiences, and since I’d started moving away from most social media, this was still a good place to send things out that weren’t specifically targeted at somebody (come to think of it, I do seem to write to somebody, even if that is an abstract idea of a somebody). However, when I posted about the last revision of the pomodoro timer yesterday, I started scrolling back to see what my earliest posts about it. What an experience to see the progress, not just in the design but also just in my ability to build things! Yesterday, I had the satisfaction of seeing a neatly completed product but, today, I have the joy of seeing the advancement in my own skills. A lovely little benefit to blogging.

In any case: have a look at the before-and-after yourself:

Just compare that to the second revision:

And to think there’s only really a few months between these versions!

Fun of Physics

The past days I’ve been following a course from the DLZA for the Dutch N-level radio amateur exam. So far, I’ve been dealing with a lot of the introductory topics; as it’s a comprehensive course for the general public, much of the initial focus is on basic physics (mostly electronics). I’ve had all of this in highschool, so all of it is quite familiar, particularly since I’ve been brushing up on some electronics for my other hobby.

One thing I had completely forgotten, though, is just how much I enjoy physics. Currently, a lot of this is simple arithmetic but I’d forgotten how much I just enjoy the chase of it. Simply seeing a problem, a little mini-puzzle, and working it out to find the right answer is enticing and alluring. I recall how I almost registered for a physics degree when I started uni. There were so many options: mathematics, English, psychology, physics, IT, philosophy – I had to pick just one (and ended up picking three over time, but that’s a whole different story).

At the start of my career, I had to spend time trying to translate my university experience to career actionable skills – what was the added value that I could sell to my potential employers? It was pretty tough, because in academia you do end up in a bubble. I always compared myself to the people around me, which meant that most of my skills seemed quite generic. After all, I’d surrounded myself with skilled and intelligent people who were all learning the same things I was. Once I joined the general labor market, however, I started seeing what my life path had really brought me: I really love problems.

For most of my colleagues, a problem is a worry that gives them headaches. Some panic when problems pop up while others try to ignore issues. For me, though, I can get bored if there’s nothing around to solve. I realized that this is exactly what my life has taught me so far: physics is filled with problems to solve. So is philosophy, and literary theory, and cultural analysis as well – each focuses on key problems that require you to solve them. I realized that in all my endeavors, I was always looking for the problem to solve.

For most of my career, these problems are abstract and high-level. If I implement this regulatory change or that process, perhaps half a year from now when that’s settled into the organization and students and staff are used to it, we may see a slow reduction in caseload over time for the year after that. I may have a student complaint where I have to weigh the costs and benefits of upholding the regulations versus individual justice and fairness for the student. All quite abstract, but whatever it is I do, the result is out of my sight.

However, now that I’m working with some elementary physics problems again, the focus of my problem solving is reduced to the very immediate. I need to know whether coil L in this schematic will cause the fuse to blow or not and, if so, what resistor I’d need to add to resolve it. Working it out involves drawing the schematic, doing some basic math drawn out right in front of me, and finally reaching a result that is consistent with the structure as a whole.

The regular enjoyment I get from solving problems is the joy of using my brain. The joy of knowing that I can understand complex issues, analyze them, and then make them understandable for others as well. The joy I find in physics is also a very elemental joy – I enjoy the physical act of doing it. Of writing down equations, working them out, and seeing the progress right there. It’s an almost child-like joy at how magical the natural world really is. A joy of seeing all these spell-like, almost alchemical formulas that are actually the most natural thing around.

Science is awesome, y’all.

Finally Learned to Make Solder Bridges

Yesterday, I tried my hand at soldering a new prototype HV programmer, with much success. After watching some YouTube videos on soldering, I had a strong theory on what may have been my problem in making solder bridges: I was using a rather wide tip at a high temperature, which resulted in spreading too much heat around. That’s why I kept running into issues where the surface tension kept working against me. I read a tip that lowering the iron’s heat to about 300C (some even suggested as low as 250C) would help a lot on making bridges. On top of that, I switched to my smallest tip to help reduce the heat transfer. Those two changes combined now allowed me to add some solder to existing connections without melting too much.

Figure 1: An intermediate soldering bridge

Above you can see the first tryout of making solder bridges. As you can see, some are better than others. The line on the left is quite sloppy, but still effective. I’m much more pleased with that triple row of solder bridges in the middle, for instance. Nevertheless, as I was soldering the set, I would use my multimeter to check the connection as soon as I had finished a line.

In the end, I was quite pleased with the final product. It doesn’t look as clean as I would like, but it looks neat, at least. It’s also a great first attempt at doing this properly. This is something I can build on, and I feel quite proud of myself.

Figure 4: The topside of the finished product.

The topside of the board looks quite neat, now that most of the connections are solder bridges on the underside. Apart from learning to make those solder bridges, I also improved on my method of laying jumper wires on top of the board. Partly thanks to my new wire stripper, and partly due to being a little less parsimonious, I ended up with exact straight wires. Before, I tried to cut them perfectly to size to start with. Now, rather, I strip more than I’ll need from one end, cut the insulation exactly to size, and then use a wire cutter to get the jumper. This way, I use a little more copper wire, but it’s also far easier to cut to exact size by just trimming the excess leads. There are only two things I’m less happy about: firstly, the resistor on the top-left is not flush with the board. While trying to solder it down, it slipped and I just couldn’t easily get it back down. Secondly, the LM7808 is slightly askew. It works fine, but it’s just a little sloppy.

Figure 5: A comparison of the first prototype to the second.

Clearly, when comparing the first to the second prototype, the second is much cleaner by far. For one, of course, it has fewer components, so it’s easier to look less cluttered. Secondly, though, just not having that mess of wires makes all the difference.

Now, the big downside is that I haven’t seen it confirmed to work yet. From what I can see, all the connections should have been correct. So, to troubleshoot, tomorrow I’ll first have to compare my schematic to the original version to see if I made a mistake there. Secondly, I’ll have to one-by-one check my connections to the schematic. After that, I’ll check the voltages and continuity on each connection with my multimeter to see what’s happening. If that doesn’t give me any answers, I’ll have to use my logic analyzer to see what’s happening when I press the button. (EDIT: while I previewed this post after drafting, I noticed what is the most likely issue. Pin 4 on the master IC is not connected to the ground bus – the long vertical line. Comparison the soldering job to the schematic shows this quite clearly).

However, even if it doesn’t end up working, I really am proud of the neatness of the solder job. I felt so much more comfortable doing that, and it was incredibly enjoyable to do now that it was working well. I’m sure that with more practice, I’ll get those lines looking neater and neater as time goes by.

Amateur Radio

I just signed up for a course training me up for an N-class amateur radio operator license. The “N” meaning “novice”, apparently. That’s the introductory license for amateur radio operators, allowing a person to broadcast over a small selection of the available bandwidth. It seems like an interesting hobby to try out, and as I discovered the introductory is really low. It seems like a great niche between my interest in electronics and interest in computing. Worse thing that could happen is that I discover that it’s not as interesting as I thought, and I’ve learned some new things. So, why not, you know?

Experiments in Arch Linux

For the past couple of years, every so often I try to install Arch Linux on one of my laptops to see if I can reasonably work with it. Over time, every time I’ve installed it, I’ve made it more and more functional. Usually, I would into some practical problem that would prevent me from doing what I’d want with it, and I’d end up installing Manjaro on it to just have a working system. The first time, I got stuck on trying to get networking to work (NetworkManager or iproute2 are the answer); the next, I was stuck in the commandline interface (installing xorg-server ended up being the answer); after that, I got an Xorg server running, but couldn’t properly install a desktop environment (I ended up going to i3wm); and so on, and so on. This time, however, I’ve gotten farther than I ever have.

Ever since I fully switched my desktop over to Linux, I’ve had to solve more and more issues myself. Pretty much every time, the real issue was just my ignorance – I’d have updated something without properly reading what the consequences where, or something would break because I didn’t do a simple fix, or things along those lines. The consequence of solving these, though, is that this time around when I installed Arch Linux, I didn’t really run into many issues anymore. Or, more accurately, I encountered the same thresholds, but I’m not getting stuck on them anymore. Sure, I had no sound after the first boot, but that just made sense, because I had no drivers installed. So, a quick install later, some referencing of the Arch Wiki, and I was done.

Similarly, this time around, when I ran into features that I was lacking, I at least had some idea of what I’d want. I’ve experimented a little bit, so I know a program or two that does what I need, and I can more accurately decide which of those I want. Or, as I have been noticing now, I have obtained decent enough skills to implement a minimal fix myself. Running i3wm from a basic install meant I didn’t have my media buttons active yet. No big problem, I just needed to reference the i3wm documentation to see what the syntax was, reference my keyboard layout to see what my key names are (just to confirm it was the default), and them implement a simple volume-up and volume-down key combo. Then I noticed there was no feedback to using those. Well, install a notification daemon, use pactl to list a bunch of info that includes my current volume, grep out the volume, awk out the exact number, pass that to dunst, and done.

Implementing that made me really feel comfortable with Linux. That was a moment when I really saw a set of separate skills come together into a single solution to a simple problem that just a year ago would have me reinstall Manjaro Linux rather than work it out myself. This is the point where there’s a Souls-like enjoyment: I’ve butted my head against the problems long enough, and thanks to my perseverance, I’ve now gained enough experience to start netting a win here and there.

Now, on to solving the next little thing I want to improve in this setup . . .

My First Sed Script (That Became a Bash Script?)

Last post, I wrote about a Sed script I wrote to help me switch configurations. As always, I’ve learned a little in the meantime, and I’ve updated the script to reflect that. As a result, it’s not a Sed script anymore, but a Bash script that calls on Sed directly to perform tasks.

I noticed that I was not being very efficient. For one, I created three files to do something that could be done in one. For another, two of those files (the Sed scripts) were virtually identical, with only two words being changed in four instances. When saw what I had done, I was reminded of a thing I read somewhere, but sadly cannot recall where:

If you’re doing something more than once, you’re not using a computer correctly.


It’s a little provocative, of course, but I like the central idea of it. A computer is meant to automate tasks, and if you, the human user, are repeatedly performing the same task, surely you should let the computer handle that? Furthermore, there’s an added risk of error: I could edit one file and forget to edit the others to match. Or, of course, were I to write a much, much larger program, copy-pasting the same code only leads to a less legible program in the end.

So, I figured to replace the repeated words with a variable, set in the Bash script, and that reduced the need for two separate Sed scripts. Now that I was down to just the one small script, I realized I could just put it directly in Bash. I would lose the Sed syntax highlighting in Vim (as it would be highlighting Bash), but to be fair the Sed highlights aren’t that great anyway. So, long story short, I ended up with the following, single script:

# switch_config.sj -- Bash script to switch over i3wm configs
# $1 = switch argument

# Check what file to change
case $1 in
    -d|--desktop) to=Desktop
    -l|--laptop)  to=Laptop
    *) echo "Select either -d, --desktop, -l, or --laptop"; exit 1

# Back up file, using \cp to avoid interactive alias
\cp config -f config.old

# Catch potential errors
if [ $# != 1 ]
	then echo "Error: please provide one argument."; exit 1

echo "Swapping i3wm configuration over from $from to $to."

# Using sed, comment out one set, and uncomment the other
sed -i '
/# '"$from"'/,/^$/{
	/# '"$from"'/b

/# '"$to"'/,/^$/{
	/# '"$to"'/!s/#//
' config

My First Sed script

2020.07.22 edit: There’s a followup to this post, that you can read here. It has an updated version of the script.

For the past weeks, I’ve been reading through O’Reilly’s Sed & Awk, 2nd Edition, to learn those powerful commandline tools. The other day, I had a practical problem for which Sed seemed like the perfect solution out of the box. It’s small, and quite trivial, but it made me proud nonetheless.

In brief, the situation I run into is that I run Manjaro Linux using the i3WM windows manager on both my desktop and laptop, and I would like to share configuration files between them; however, due to their different resolutions, I want most but not all settings to be shared. Specifically, I have a few windows I keep on a scratchpad (basically: floating windows that you can hide, as well as keep consistent across workspaces). I still tweak these files every so often as I try to add features I like or adjust the look of this or that. I then share the config file between my two PCs, which leads me to having to adjust a few settings:

 # Laptop configuration
 for_window [class="^popup_term$"] resize set 960 540
 for_window [class="^popup_note$"] resize set 455 758
 bindsym $mod+equal [class="^popup_note$"] scratchpad show, move position 906 5
 # Desktop configuration
 #for_window [class="^popup_term$"] resize set 960 540
 #for_window [class="^popup_note$"] resize set 455 1070
 #bindsym $mod+equal [class="^popup_note$"] scratchpad show, move position 2540 324

By the way, you can see the constant tweaks here, because I used to have the popup-term class take different sizes depending on PC or laptop, but I recently settled on using the same resolutions for both. So, that one, for instance, will have to be edited out again into the general settings. The settings above used to be part of those settings, but I split them off to separate the desktop/laptop-specific configurations. Then, using my newly-gained Sed skills I made a tiny script that just comments out one set of code and removes the comments for the other:

# Commands to switch to desktop configuration

# Comment out laptop configurations
/# Laptop/,/^$/{
        /# Laptop/b

# Uncomment desktop configurations
/# Desktop/,/^$/{
        /# Desktop/!s/#//

It’s a fairly straightforward substitution: anything between the start of the Laptop section to the first blank line gets subjected to the code. Using a branch to nowhere (using a branch without a label in Sed means it skips to the end of the script), I make sure to skip the title (I want to keep that a comment), and to skip the blank line (just to keep it looking neat). Then, a basic regex takes every line that doesn’t start with a comment and replaces those lines with a # and the line. Lastly, we do the inverse in the Desktop section: we simply replace the # character with nothing in all lines except the title. Since we’re only removing a character, there’s no need to filter out anything else.

Because I have two scripts, one for the move to desktop and one to laptop, I made a small bash script to switch between them:

# Bash script to switch over i3wm configs


# Back up file, using \cp to avoid interactive alias
\cp config -f config.old

# Catch potential errors
if [ $# != 1 ]
        then echo "Error: please provide one argument."; exit 1

# Check what file to change
case $1 in
    -d|--desktop) computer=desktop;;
    -l|--laptop) computer=laptop;;
    *) echo "Select either -d, --desktop, -l, or --laptop"; exit 1

echo "Swapping configuration over to $computer."

# Implement the change using sed
if [ $computer == desktop ]
        then sed -i -f desktop.sed config
        else sed -i -f laptop.sed config

This way, I don’t have to take the individual steps myself, and just use the one command to take care of it. Plus, if one day I figure out a way to check if the config file has changed from a previous version, I could use this to automate an adjustment. For now, I’m just happy I figured out a practical means of automating something I used to have to do manually each time I edited the configuration file.