This keyboard is my very first electronics project. Prior to building Alpha, the only soldering I’ve done was to make the odd custom audio cable. As a result, I was… well, literally ill-equipped to take on his project, which required some serious investment.

Here are some of the essentials I picked up. All part numbers can be found on Digikey, which I used as my primary electronics supplier:

  • Soldering Iron (243-1156-ND)
  • Soldering Iron Stand (243-1156-ND)
  • Hemostat (243-1168-ND)
  • Multimeter (MN35-ND)
  • Desolder Braid (243-1185-ND)
  • Desolder Pump (243-1183-ND)
  • Lead bending tool (1568-1132-ND)
  • Fume absorber (243-1318-ND)

In addition, I took advantage of a cutting mat that was already in our possession as a work surface.

I also needed some consumables for assembly:

  • Magnet Wire (1568-1088-ND)
  • Solder (RASW.0201OZ-ND)

A couple of things to note, here.

First, I used magnet wire for the assembly. This was a very good choice. Magnet wire has a couple of incredibly useful properties:

  • It is coated with an insulation that burns off with a hot soldering iron and a little solder. This meant no stripping of insulation (except for circumstances where I really wanted to avoid overheating). I could just solder directly, confident that there wouldn’t be unexpected shorts.
  • Because it’s solid core wire and not stranded, it can be shaped easily. In the final build you can see how I’ve arranged the wire into clean right angles that would’ve been impossible had I used insulated, stranded wire.

Second, I opted for leaded 63/37 rosin activated solder. This stuff melts clean, freezes fast and consistently, and is generally just very easy to work with.


Just to review, a hand wired keyboard is built of a few essential parts that you have to build or source, including:

  • Switches - you gotta press something
  • Keycaps - no one wants to just press a switch
  • Case - everything’s gotta go in something
  • The keyboard controller - so the switches have something to talk to
  • Stabilizers - so your spacebar isn’t wobbly
  • Diodes - to ensure multiple key presses don’t confuse the controller
  • Hardware - you gotta piece that case together with something

Obviously a lot of the nuance in a build is selecting these parts so in the following sections I’ll go over those choices.

Switch selection

Probably the two most important parts decisions when building a keyboard are the switches and the keycaps.

In the case of the former, the best thing you can do is pick up a switch tester, which is a little selection of switches mounted in an acrylic block which allows you to feel out which switches might be best for you.

To narrow it down it’s important to understand the three main classes of switch: linear, tactile, and clicky. All mechanical switches actuate part way through the press, which allows the typist to register a key press without bottoming the key out.

A linear switch provides no explicit tactile feedback during the press. Instead, you just feel some additional resistance as the spring in the switch compresses.

A tactile switch includes the feeling of a “bump” on the way down--a brief increase of resistance followed by a linear-style press through to bottoming out.

A clicky switch behaves like a tactile switch, but includes an audible click to indicate the switch has actuated.

Among these classes things vary widely, from spring weight to tactile bump intensity and click loudness. There’s a lot to choose from!

Since I was building a keyboard for office use, I wanted to avoid clicky switches. But I do appreciate some amount of tactile feedback. Consequently, I decided to buy a KBDfans tactile switch tester.

Once the tester arrived, I eventually settled on the Kailh Hako Violet switch, which is a fairly light switch with a nice, light, tactile bump.

Keycap selection

Keycaps are an interesting challenge to choose. I won’t go too deep into the nuances, as there’s many of other resources out there that explain the variables, but in broad strokes you have to choose between keycap materials (ABS or PBT), printing method (laser etched, dye sublimated, or double shot), key profile (uh.. lots), and board compatibility.

The material tends to dictate the general feel of the keycap.

The printing method affects how well the keys wear over time.

Key profile is the shape of the keycap. Many mechanical keyboards include sculpted key profiles, which change row to row and create a curved overall shape to the board. Others (in particular the DSA profile) are flat.

Board compatibility is a function of key layout. For example, my layout includes a 1.75u shift (the standard square keycap is 1u all other keys are measured as a ratio of that base size), which is somewhat unusual. As a result, I needed a keycap set that included a shift key of that size.

And, of course, one can’t discount cost.

In my case, my oddball key layout immediately forced me to select DSA profile caps. Why? Well, because my layout had keys in unusual rows (e.g., the arrow keys on the bottom row), sculpted keycaps would’ve resulted in a weird, inconsistent profile, since the keys on my board would be in the wrong place relative to the normal profile for the caps.

Once I was forced to DSA caps, my options were a lot more limited.

On top of that, some of my key size selections (like the 1.75u shift) limited options further.

Factor in cost (keycaps can get enormously expensive!) and I ended up selecting the KBDfans DSA Lazer Etched 145 key blue and white cap set.

They’re not the highest end caps in the world, and the legends will wear off over time, but they’re still a pretty darn nice set!


To be honest, controller selection was dictated by two factors:

  1. I wanted an ATmega32u4 CPU, as that’s very well supported by the open source QMK keyboard firmware.
  2. I was ordering on Digikey.

That left me with a single choice: The Adafruit Itsybitsy 5V (1528-2501-ND).

This device worked out great! It has a decent number of pins (23) at a reasonable price point. The only tricky thing was finding a useful pinout using the AVR pin names. Fortunately, the website had a pin mapping, which I’ve happy cribbed and included here:

Itsy Bitsy Pinout

With that the rest was a piece of cake.

Case construction

As I mentioned previously, a sandwich-style case is composed of two pieces: the switch plate and the backing plate (and normally a couple of middle layers, but I skipped those).

I opted for 1.5mm brushed stainless steel, laser cut by Underpressure Welding. They did a wonderful job, though I should’ve asked them not to sand off the burrs that resulted from the cut, as the bottom plate ended up with some unsightly marks. Fortunately, the top plate was untouched, and I manually removed the burrs using a metal file.

The plan for the case was designed using the swillkb plate and case builder.

The case is then assembled using nickle plated hex standoffs and screws. Simple and effective.

As you’ll see later, I also lined the bottom plate with a piece of thin foam, both to protect the switch matrix from shorts, and also to reduce noise.

Other parts

There’s a grab bag of other random parts that I needed to complete this build:

  • Screws (H742-ND)
  • Standoffs (36-24395-ND)
  • Diodes (1N4148FS-ND)
  • Micro USB Breakout (1568-1194-ND)
  • 14 pin board-to-board mating pins (ED6864-14-ND)
  • 14 pin board-to-board mating receptacles (ED4764-14-ND)
  • 5 pin board-to-board mating pins (ED6864-05-ND)
  • 5 pin board-to-board mating receptacles (ED11158-ND)
  • 5 pin USB receptacle - (A26475-ND)
  • Foam insulation (EAR1033-ND)
  • Feet (KBDfans Anodized CNC Aluminum Feet)
  • 3M Command adhesive strips (3M162666-ND) - $5

There’s a lot to buy!

Posted on 2019-01-24

0 Comments on this page


Key layout

For my first keyboard I wanted to come up with a design that was unique enough to justify a build, but still practical and useful. After seeing an HHKB layout, I also decided I didn’t want to get locked into a traditional rectangular key layout. I wanted something different.

There are a few things about my target use case for this keyboard, and my own typing habits, that informed the layout I chose.

First, this keyboard would be used at work, where I no longer code professionally. Instead, my keyboard is used mostly for writing prose, in the form of email, documents, and so forth. This fact allowed me to sacrifice dedicated function keys and the grave/tilde key, as I knew I wouldn’t be using them heavily.

Second, my typing style has evolved to rely entirely on my left hand to operate the Alt, Control, and Super keys. Those keys on the right side of the keyboard see no use during my normal day to day activities.

Finally, I do tend to use the arrow cluster and page up/down keys a fair bit. I knew I’d want to preserve them in lieu of a true 60% layout.

What I ultimately arrived at is this somewhat peculiar design:

Alpha Key Layer 0

I developed this using the Keyboard Layout Editor, which is an enormously useful tool!

As you can see, by removing the right-hand meta keys I was able to use that space for other keys that I find most useful. In particular, Vim users will recognize the arrow key arrangement, which mirrors the hjkl navigation cluster. I then adjusted the key dimensions to produce a symmetric, tapered profile across the board.

In addition, I’ve defined a layer that includes the function keys, plus some useful media keys1:

Alpha Key Layer 1

In general this has proved mostly successful, though I gotta admit, the left control key positioning is a little tricky to adjust to (I’ve definitely missed it a few times!) and I do miss the F12 key in Linux (which I use to open Guake).


For the case my primary goal was to build something cheap, flexible, and easy to assemble. I knew that meant a sandwich case design, though in the interest of reducing costs, I left out the interior layers, instead opting for an open plate construction. The result is what I charitably think of as an industrial-style look that let’s you catch a glimpse of the guts of the thing.


I feel the most interesting aspect of this keyboard design is the entirely hot swappable nature of the build. Rather than soldering the matrix directly to the switches, I used Kailh hotswap sockets, which means the switches themselves can be easily swapped out.

In addition (and I have much more mixed feelings about this), the controller is connected to the matrix using a set of low profile board-to-board mating sockets and pins. This means the board can be easily detached from the matrix, which makes it possible to replace it or reuse the board in another project in the future.

Finally, the use of a USB breakout board with a custom made cable allows me to easily remove the case and detach the breakout board without disturbing the rest of the build.

This construction provides a couple of benefits. First, again, it allows repair or replacement of components and so forth, which is nice. However, for this paranoid first timer solderer, it also meant I could avoid soldering directly to delicate components. Other than soldering the headers to the USB breakout board and controller, all other joints involved cheap, replaceable sockets and pins.

In hindsight, I think this was a great design choice, with the exception of the hotswappable controller. As we’ll get to later, that choice resulted in the case not having enough space, due to the height of the combination of controller plus socket plus pins, which meant I had to get taller standoffs to complete the assembly.


1. This image doesn’t actually reflect the final layout, as I ended up mapping Fn-PgUp to Mute, and configured the Esc key to be the QMK Grave-Esc hyper key, among other minor tweaks
Posted on 2019-01-23

0 Comments on this page


If you couldn’t tell in my Mechanized post, I’m a big fan of mechanical keyboards.1

Well, unsurprisingly, it turns out I’m not the only one.

In fact, the mechanical keyboard community, which is well represented on Reddit, is a thriving little niche community of total keyboard nerds. And within that community, there are numerous sub-cultures: the keyboard collectors, the artisan keycap fans, the switch hackers, and--and this is the subject of this post--the builders.

Yes, builders. There are people who take create pleasure in building their very own keyboards.

When my good friend Jas first opened my eyes to this concept, I was fascinated. I joked that this was the nerd equivalent of building your own lightsaber--a right of passage from padawan programmer to master hacker.

Initially the joke ended there, but the idea got stuck in my brain. I just couldn’t shake the fascination with building my own board.

Within the building community there’s a few routes. The first is to buy a kit, which includes all the essentials you need to assemble the keyboard. Critically, this includes a PCB, which is used to wire the switches together to a controller to form the essential bones of the board, and the case, where everything lives. Some don’t even require soldering to assemble!

The second is to design a PCB and case from scratch, and then solder the switches to the PCB and put the whole thing together.

And the third is to build the case, but then connect the switches by hand using wire and solder.

Each route has its own pros and cons, trading off cost with effort and flexibility.

As the idea of building a keyboard took root in my brain, I knew one thing: if I was going to do this, I was going to wire it by hand. I wanted the infinite flexibility of a custom PCB with none of the hand holding! That also meant, if I was going to do this, I had to get a case custom manufactured.

But, of course, I wasn’t actually going to do this, right?

But then I started playing with different key layouts, trying to find that perfect, unique layout that would combine ergonomics, my own usage patterns, and aesthetics to produce just the right arrangement.

And the I found something I liked, and I thought, well heck, why not send out for some quotes to see how expensive it would be?

The next thing you know I was filling a shopping cart on Digikey with parts and equipment.

And before you know it, well damn. Apparently, I was committed to building a keyboard.

The rest of this blog series covers my adventures in building that keyboard.

Let the games begin!


1. And if you read that post, I can confirm that I still love my WASD Keyboard! Those Cherry Blue switches are just… delightful!
Posted on 2019-01-22

0 Comments on this page


I’ve always been a big fan of mechanical keyboards. For many years at work I held on to an IBM Model M, happily driving my neighbours nuts with the loud clickity-clack of its glorious keys. But, alas, it eventually broke down and I had to settle for a run-of-the-mill membrane keyboard.

Weirdly, though, the mechanical keyboard never really died, and thanks to the gaming community, has actually had quite the renaissance over the years. So, when, at work, I found myself needing a new keyboard, I got permission to purchase a eSports Poseidon. I fell in love with it immediately and, with its Cherry MX Brown switches, it has been a total dream (well, until recently… but that’s a whole other story), with just the right amount of tactile response and not entirely excessive noise…

Anyway, my own home setup has been evolving a fair bit lately, and I decided it was about time to ditch my Logitech membrane keyboard for a proper mechanical. But this time, instead of springing (har har) for a mass-produced gaming keyboard, I decided to order something special: a WASD V2 87 Key custom mechanical keyboard with Cherry MX Blue switches.

And it arrived today!

WASD V2 Keyboard

Awww yeah. It’s heavy. It’s seriously clickity-clacky (like… seriously). It looks amazing (some might say “ugly” or “garish” but I prefer “super-retro”). And now I’m writing this post as an excuse to bang away on the damn thing, because man oh man, is it ever fun!

It’s definitely gonna take some getting used to--the keys are definitely stiffer than the MX Brown switches on my work board, though I wonder if that’ll ease over time as I work it in--but compared to the mushy old keyboard I had before, it’s just way too awesome for words!

And it’ll probably drive Lenore crazy!

Posted on 2018-11-15

0 Comments on this page


After adding a Windows VM to the mix, to support the few things I need to do with that OS, I’ve found I’m actually seriously considering completely wiping Windows from this laptop and doing a single boot Ubuntu environment!

This is a genuinely surprising development. I never expected Ubuntu to work so darn well on this machine, but it’s pretty close to flawless. Heck, I recently had this machine plugged into my work corporate network, and the thing auto-discovered and set up the network printers without any direct intervention from me.

Mind == blown.

Meanwhile, Windows 10 in Virtualbox, while not the most high-performance environment in the world, is a perfectly suitable environment for Skype, Webex, Outlook, and any other little Windows dependencies I might encounter.

Honestly, I feel like after many years in the wilderness, I’m coming home once again. Linux is just a far more familiar, comfortable environment for me. I didn’t realize how much I missed it!

Posted on 2018-08-31

0 Comments on this page


So, first of all, Ubuntu on my Carbon continues to rock pretty hard. I’m genuinely impressed! To date, the only issues keeping me from going 100% Ubuntu all the time were work related:

  • We use Skype for Business
  • Webex on Linux basically sucks (at my company where we haven’t had the web app enabled yet)
  • Outlook Web App is fantastic… until you want to book a meeting, and then it basically sucks.
    • Oh, plus it does have some weird authoring glitches that are a bit of a PITA.

But for personal use, it’s been a total champ!

Fortunately, I’ve also found the obvious solution to the above issues (and one I’m sure many others employ): a Windows VM.

In particular, Windows 10 + VirtualBox is a perfectly capable solution for the aforementioned issues. Heck, even my Bluetooth headset and laptop camera work (in the case of the latter, it straight up works in vbox, and in the case of the former it looks like just another audio input/output device attached to the VM)!

And since the use cases are so modest, I can throw a measly 4GB of the total 16GB on this thing at Windows and everything runs pretty darn smoothly.

Not bad at all!

Oh, and also I decided to throw a little brutalism on this website for kicks. Enjoy!

Posted on 2018-08-18

0 Comments on this page


I’ve long been an enormous fan of Lenovo equipment, and last year I decided to finally upgrade my aging T410 and get the truly fantastic 2017 revision of the X1 Carbon. A year on it is unquestionably one of the finest pieces of equipment I’ve ever owned.

The laptop naturally shipped with Windows 10, and as an operating system I have few issues with it. My work involves a lot of Microsoft-specific software, including Outlook and Skype for Business, so it’s a good fit for when I want to work from home and not transport my work equipment from the office. But as a development environment it’s only decent. WSL certainly makes the experience a fair bit more enjoyable, but it stills feels a little clunky.

Meanwhile, there’s definitely a few things that irritate, the most notable being the unplanned reboots, for which Windows 10 has become legendary.

Of course, Windows on Intel hardware does have its advantages. Chipsets and peripherals Just Work, and Windows has gotten much better with touchpad support and so forth. So, in the end, I don’t have a lot of complaints. Ultimately, completely leaving Windows behind on this machine just isn’t tenable given my use cases.

But, that doesn’t mean I can’t try Linux out, and so I did with Ubuntu 18.04!

This is just a quick write-up of the installation process and some of the issues I’ve encountered, in case this has any utility for anyone.

First off, honestly, the install process was dead simple. I was a little worried about the UEFI bootloader and so forth, but ultimately I just had to:

  1. Disable Fast Boot in Windows
  2. Disable Secure Boot in the BIOS

After that, I carved out some space on the disk from the existing NTFS partition and then installed from a USB key I wrote using Rufus based on the Ubuntu 18.04 ISO.

So far, pretty bog standard stuff, and certainly a far cry from the old days of installing Slackware from a dozen floppies!

The OS, itself, works so well as to trick one into thinking all was going to be perfectly fine and everything was simply going to work out of the box!

Not so.

In particular, using the 4.15 kernel that ships with Ubuntu, I ran into a rather bizarre error where the Thunderbolt USB controller would be “assumed dead” by the kernel (Linux’s words). This resulted in attempts to enumerate the PCI devices failing, and that then lead to various and mysterious application failures if they happened to use libpci. I can only assume the USB ports were also non-functional, but I never actually checked that.

This lead me down an extensive troubleshooting path that was only resolved when I decided to downgrade my kernel.

Yes, that’s right. Downgrade.

Moving to 4.14 resolved the issue, which means clearly a bug has been introduced in 4.15 (and before you ask, yes I tested 4.17, and no the issue isn’t fixed… alas).

Oh, but there’s more!

Sleep on lid closed worked wonderfully, except that upon waking, two finger scrolling broke.


Fortunately, there’s a workaround: Add “psmouse.synaptics_intertouch=0” to your Linux kernel boot arguments.

With those two workarounds, this thing actually seems to be working pretty well (as evidenced by the fact that I’m writing this post on Ubuntu on my laptop). Wifi clearly works, as does Bluetooth, sound, and accelerated video. USB devices appear to work (though I’ve only just started testing). Plugging in an external HDMI TV works flawlessly. Suspend works perfectly (though I’ve still not gotten hibernate working).

In short, so far the essentials are functional.

Meanwhile, amazingly, battery life seems to be as good as Windows; something that I certainly couldn’t claim in the past. And that’s without any kind of tweaking.

Update: I installed TLP plus the associated Thinkpad kernel module and when just doing light browsing or typing, on a full charge, Ubuntu reports an astonishing fourteen hours of battery life. Windows has never come close!

In short, while this setup is clearly still not for amateurs (having to downgrade kernels and fiddle with boot arguments to get basic functionality working is not for the feint of heart), it does seem to work well once those issues are overcome.

The real question is one of long-term stability (and utility). Only time will tell!


Windows assumes the hardware clock is in local time. Ubuntu defaults to assuming the hardware clock is in UTC (which is almost certainly the right thing to do).

This means that switching between the two results in the clock getting set incorrectly!

The simplest solution is to make Ubuntu match Windows’ braindead setting as follows:

 timedatectl set-local-rtc 1 --adjust-system-clock

Confirm by just running timedatectl without any arguments, which should result in this warning:

 Warning: The system is configured to read the RTC time in the local time zone.
          This mode can not be fully supported. It will create various problems
          with time zone changes and daylight saving time adjustments. The RTC
          time is never updated, it relies on external facilities to maintain it.
          If at all possible, use RTC in UTC by calling
          'timedatectl set-local-rtc 0'.
Posted on 2018-07-22

0 Comments on this page


I mentioned a while back that I’d moved to using my NUC as a backup storage device, and that continues to be a core use case after I repaved and moved the thing back over to Ubuntu.

Fortunately, as a file server, Linux is definitely more capable and compatible than macOS (which is why, back when it was a Hackintosh, I used a Linux VM as the SMB implementation on my LAN), and so I’ve already got backups re-enabled and working beautifully.

But the next step is enabling offsite copies.

Previously, I achieved this with Google Drive for macOS, backing up the backup directory to the cloud, a solution which worked pretty well overall! Unfortunately, Google provides no client for Linux, which left me in a bit of a jam.

Until I discovered the magic that is rclone.

rclone is, plain and simply, a command-line interface to cloud storage platforms. And it’s an incredibly capable one! It supports one-way folder synchronization (it doesn’t support two-way, but fortunately I don’t need that capability), which means that it’s the perfect solution for syncing up a local backup folder to an offsite cloud stored backup.

But wait, there’s more!

rclone also supports encryption. And that means that (assuming I don’t lose the keys… they’re safely stored in my keepass database (which, itself, is cloned in multiple locations using my other favourite tool, Syncthing)) I can protect those offsite backups from prying eyes, something which Google’s Drive sync tool does not offer.

I can also decide when I want the synchronization to occur! I don’t need offsites done daily. Weekly would be sufficient, and that’s a simple crontab entry away.

Now, to be clear, rclone would have worked just as well on the Hackintosh, so if you’re a Mac user who’d like to take advantage of rclone’s capabilities, you can absolutely do so! But for this Linux user, it was a pleasant surprise!

Posted on 2018-07-03

0 Comments on this page


Well, it’s finally happened. After a year of running semi-successfully, I’ve finally decided the trouble wasn’t worth the effort and it was time to retire the Hackintosh.

As a project it was certainly a lot of fun, and macOS definitely has its attraction. In the end, though, I found my NUC was serving a few core functions for which macOS wasn’t uniquely or especially suited:

  1. Torrent download server
  2. Storage target for laptop backups
  3. Media playback of local content as well as Netflix

Of course, the original plan was to also use the machine as a recording workstation, but so far it hasn’t worked out that way. Yet, anyway.

Prior to a recent security update, there was a couple of issues that I generally worked around:

  1. Onboard bluetooth and the SD card reader don’t work.
  2. The onboard Ethernet adapter stopped working after heavily utilization.
  3. Built in macOS SMB support is broken when used as a target for Windows file-based backups.

These issues were resolved, by:

  1. Avoiding unsupported hardware.
  2. Using an external ethernet dongle.
  3. Performing all SMB file serving via a Linux VM running on VirtualBox.

Meanwhile, the threat of an OS update breaking the system always weighed on me.

Unfortunately, it didn’t weigh on me enough: the 2018-001 macOS security update broke things pretty profoundly, as the Lilu kernel extension started crashing the system on boot.

A bit of research lead me to updating Lilu, plus a couple of related kexts while I was at it, which brought the system back to a basically functioning state, except now:

  1. HDMI audio no longer worked.
  2. The USB Ethernet dongle stopped working.

The first issue rendered the machine unusable as a video playback device, a use case which is surprisingly common (my office is a very cozy place to watch Star Trek or MST3K!).

The latter left me with a flaky file/torrent server.

In short, all the major use cases I had for the Hackintosh no longer worked reliably, or at all.

Meanwhile, nothing I was doing uniquely relies on macOS. I’ll probably never get into iOS development, and the only piece of software I’d love to have access to is Omnigraffle (I never got far enough into recording tools to get attached to them).

So, no major benefits, and a whole lot of pain meant, if I’m being pragmatic, the Hackintosh was no longer serving a useful function.

So what did I replace it with?

Ubuntu 18.04, of course!

So far it’s been a very nice experience, with the exception of systemd-resolved, which makes me want to weep silently (it was refusing to resolve local LAN domain names for reasons I never figured out). Fortunately, that was easily worked around, and I’m now typing this on a stable, capable, compatible Linux server/desktop.

When I do finally get back to recording, I’ll install a low latency kernel, jack, and Ardour, and then move on with my life!

Posted on 2018-07-02

0 Comments on this page


My Google Groups web scraping exercise left me with an archive of over 2400 messages, of which 336 were written by yours truly. These messages were laid down in a set of files, each containing JSON payloads of messages and associated metadata.

But… what do I do with it now?

Obviously the goal is to be able to explore the messages easily, but that requires a user interface of some kind.

Well, the obvious user interface for a large blob of JSON-encoded data is, of course, HTML, and so started my next mini-project.

First, I took the individual message group files and concatenated them into a single large JSON structure containing all the messages. Total file size: 4.88MB.

Next, I created an empty shell HTML file, loaded in jQuery and the JSON data as individual scripts, and then wrote some code to walk through the messages and build up a DOM representation that I could format with CSS. The result is simple but effective! Feel free to take a look at my Usenet Archive here. But be warned, a lot of this is stuff I posted when I was as young as 14 years old…

Usage is explained in the document, so hopefully it should be pretty self-explanatory.

Anyway, this got me thinking about the possibilities of JSON as an archival format for data, and HTML as the front-end rendering interface. The fact that I can ship a data payload and an interactive UI in a single package is very interesting!

Update: I also used this project as an opportunity to experiment with ES6 generators as a method for browser timeslicing. If you look at the code, it makes use of a combination of setTimeout and a generator to populate the page while keeping the browser responsive. This, in effect, provides re-entrant, cooperative multitasking by allowing you to pause the computation and hand control back to the browser periodically. Handy! Of course, it requires a semi-modern browser, but lucky for me, I don’t much care about backward compatibility for this little experiment!

Posted on 2018-01-02

0 Comments on this page