What programming/technical projects have you been working on?

I was inspired by the XKCD mirrorboard layout, which theorized a way to type with one hand, but without a large learning curve by flipping the right side of the QWERTY layout to the left. At the end of the article, they discuss a potential auto-prediction method with Regex to search through all possible words and see which one could be typed with that combination of flipped and unflipped keys, something like /[wo][ow][ru][dk][sl]/. I was pretty curious to see how this would work so I created a basic experimental version as a webpage, and also as a Chrome extension (I do the majority of my typing on ChromeOS, and I didn't want to delve into the ChromeOS input method APIs).

Surprisingly, there are less collisions than I would have expected, and I can reach about 40% of my original typing speed with one hand. Some more common collisions I noticed were "words/works" and "like/side", but these are mitigated by tabbing through the possible options.

For a while now I've been playing on and off with a project to try and generate country music lyrics using machine learning (this all started from a joke about how simple many modern hit country songs are).

I picked it back up again recently using the GPT-2 model recently released by the Open AI research group. I scraped the lyrics for Billboards top 100 country songs for the last 20 years and fed that into the model for fine tuning.

My poor little laptop had an OOM error when trying to train with these massive data sets, so I rented an AWS server to train it (cost me less than $10 by the end.). Nothing really great has come out of it, but it's been fun and has generated some pretty comical stuff.

I've been creating my own keyboard layout.

Using Ilya Birman's typography layout has been quite pleasant. It's been in my inventory for about a year now, and the only problems with using it came from Windows itself.

That said, I find it inadequate for my needs:

• it lacks the umlauts (ä, ö, ü etc.), which is important for me if I'm ever gonna get better at German
• the dash I use most often behind the ordinary - dash – the – en-dash that I use for unbracketed parenthesis – is behind three-key stroke
• some of the other symbols I'd rather use are not available at all, and things I see no way of ever using are surprisingly-prominent

Basically, if it's difficult to get to, I'm never gonna get to it – and if it's easy to do, I'm gonna do it all the time. I'd much prefer my tools to accomodate my nature, not the other way around.

So, I've been using the Birman layout as a base for my own.

It's incomplete still. So far, I've compiled a few alpha builds using Birman's source code with changes and used them in practice. Right now, the layout – Spark – makes some changes to the Birman base – like putting umlauts to appropriate keys (so that [AltGr]+[a] produces ä).

In the future, when I devote time to learning how to do so, I'd like the layout to become multi-layered. I'm thinking of replacing Caps Lock with some sort of an auxiliary key that would allow me to traverse the layers of the layout. Each layer would host its own category of keys/symbols.

Low-level thinking permits adding media control keys, like zoom, or play/pause, or fast forward, or save screenshot. These might have to be bound to virtual keys that don't exist within the hardware of the keyboard.

In terms of languages, I may well bind different keyboard layers to layouts of languages I aim to use regularly – like German, or Norwegian, or Icelandic and French that I aim to learn eventually.

Perhaps with the assistance of software, I might be able to generate layers that aid my programming and design (e.g. by pasting the default index.html structure as plain text). Maybe add symbols that aren't used regularly but could aid production and/or presentation (such as the Unicode drawing boxes that I found useful in plain-text diagramming).

The only part of software assistance I use right now is the Spark External module for AutoHotKey. I managed to compile it to an .EXE file that I load on boot. It replaces native key commands with the ones I set, which are mostly media controls for the audio (because I listen to music for 80% of my uptime if I can help it). I wanted it to do a little more, but I couldn't seem to figure out the language before putting the project on ice. (A downside to .EXE-module approach is that sometimes Windows seems to "offload" the module, causing it to stop working. A simple relaunch fixes it for a few days.)

Ideally, I'd want to make my own keyboard, tied intricately to my needs. Media controls, multiple layers, hardware-level macros – who knows what else. I've seen various such projects online, and I'd always wanted to get into electronics.

I've been using PyTorch to train neural networks to do OCR on and off over the last few months.
This was prompted by a problem we had at work that was not solvable using the open source OCR engine Tesseract due to a noisy document background.
So I thought I'd apply my nascent machine-learning expertise to the problem in my spare time.

OCR of machine printed documents is apparently considered a solved problem, so there is surprisingly little information to be found that goes beyond "use Tesseract".
There are a bajillion scientific papers about text spotting (finding text in natural images) and scene-text recognition (recognizing said text in images once cropped) though. Most of them are kind of complicated...

The simplest approach I found, Facebook's Rosetta, simply wires a convolutional neural network (Resnet18) to directly output character-class probabilities for each vertical slice of the image using CTC -- Connectionist Temporal Classification. That's a method that optimizes a neural network to output the correct character sequence without one having to annotate where each character is in the image.

However, since CTC decoding ignores doubled characters (the "ll" in "hello", for instance), the networks I ended up training had a lot of difficulty producing them. CTC introduces a blank character to separate such doubled characters, but the network almost never managed to produce it, for reasons I have yet to understand.

I was stuck for a long while, until I reluctantly gave up on the idea of simplicity and brought out the big guns: encoder-decoder LSTMs enhanced with an attention mechanism.

And that finally worked.

The next step is to apply the network design to the actual problem, not to the easier proxy-task I've been using for development.

The second prototype for my accordion bass electronics project is coming along. I'm building a 9-bass out of FR4 with two levels of keyboard switches, with a cut up plastic dowel for the keycaps and nails to reach the lower level key switches.

In the process I learned why people spend money on drill presses and built a rig to drill holes in the center of the dowels. I'm still not happy with the keycaps and I'm considering switching to wooden dowels or resin molding next time.

Now I'm taking it apart again to do the wiring.

I've been busy writing an implementation of ed(1) in Assembler.

I've written most of the base, in that I can read a file into the line buffers and perform operations on that line buffer like insertion and deletion. I've written a version of pike's regex implementation in assembler too, which will be nice when I get to parsing input and writing the command interface

Doing some bioinformatics with Julia, the Bio packages are super good, it's a joy compared to the alternatives (R, python, ...).

I finally got around to installing Volvo vida software onto my laptop so that I could diagnose a few issues with a car I bought quite awhile ago. Fortunately the knockoff dice unit I bought from China is working just fine. Unfortunately I didn't find any electrical faults with the transmission solenoids and now I will attempt to remove and repair the transmission valve body next week.