Build a minimal Docker image for Rails

FROM ruby:3-alpine

RUN apk update
RUN apk add --no-cache \
    build-base \
    nodejs \
    yarn \

COPY Gemfile Gemfile.lock /app/

RUN bundle install


CMD ["rails", "server", "--binding="]


Converting an Apple Newton keyboard from DIN-8 to USB

For some reason, recently I got it into my head that I wanted an Apple Newton keyboard. Who knows how these ideas get planted in ones mind? I have a general interest in retro Apple equipment, but have never actually owned, or even used, a Newton before. But the Newton keyboard accessory is just so small and cute, it has an appeal all of its own. A keyboard is still the primary interface method between a human and computer, too, so I figured I could justify getting one. The keyboards I currently own are fairly esoteric, so a Newton keyboard would be a fine addition to the collection.

The problem with actually using said keyboard is that the connector isn’t really compatible with anything. It uses a DIN-8 connector, which is the same physical size as Apple’s old ADB connector, but is not actually compatible with ADB. Before buying, I searched around on the ‘net and found a blog post by one Jim Lombardo, which showed how he used a 5V microcontroller to translate the output of the Newton keyboard to something that a modern computer can use. I had no experience with using a programmable microcontroller before, but the instructions/source code were all there, so figured I could suss it out.

The Newton keyboard alongside my Model M
The Newton keyboard alongside my Model M. Notice the mess of wires where the DIY adapter is.

Fortuntely, everything worked without a hitch. A little solder and programming the controller got the keyboard working on my modern Macintosh. The one annoying part was the ugly mess of wires surrounding the DIN-8 -> USB transition. I wanted to enclose everything inside the keyboard, and then just have a USB cable visible, but as you might expect there was not enough room. I also didn’t really want to cut/destroy the old cable, even though I couldn’t see myself ever using it. Opening up the keyboard showed that the DIN-8 cable connects to the keyboard PCB via a 6 pin JST connector. Why couldn’t I disconnect the keyboard’s DIN-8 cable, then solder the JST connector directly to the microcontroller? As it turns out, I could do exactly that. I bought some cheapo connectors on Amazon, and they worked a treat. Now the thin microcontroller is stashed inside the keyboard, with only the USB cable visible. Success!

The JST connector connected directly to the microcontroller
The JST connector soldered directly to the microcontroller inside the keyboard.

So, was all that work worth it? Mmmmmaybe. A Newton keyboard definitely a unique conversation piece. I’m sure I’ll get a few comments about it if/when I bring it back into my office. It’s very compact, as you might expect — even smaller than my 60% Happy Hacking Keyboard. So it frees up a lot of space on your desk. It even has an Apple/command key, which is perfect if you use a Macintosh. The keyboard does have a few downsides, of course: no function keys, and no escape key(!). Pretty funny to use this with my (work-provided) Macbook Pro, which also doesn’t have an escape key. It is only annoying sometimes — I map caps lock -> control, and use control+c with vim, etc. The other thing about the Newton keyboard is that it’s actually not that great of a keyboard. It uses rubber domes and in general is similar to other cheap keyboards you would get in the mid-90s. The keys are a bit stiff, and it takes a while to get used to. I probably wouldn’t use it as my main keyboard, but as a novelty it’s pretty fun.

To sum up: converting a Newton Keyboard to USB is relatively easy, and if you have any interest in this sort of DIY nonsense, I’d say give it a shot! I still have 9 JST connectors that I will never use for anything else, so if you start this project and want one, get in touch via the comments and I’ll mail you one for free.


Re-capping a NES

I’m a low-key video game collector. Mostly because I just like games, and end up holding on to the junk I buy for each console generation. I’ll occasionally venture on to eBay to pick up the random retro title. Plus I worked at a used game store for a while back in college, which helped my collection immensely.

Sometimes, however, I don’t exactly remember where I picked up a particular piece of kit. Maybe it was scrounged from a rando on craigslist, or I found a good deal online. Who can know these things, exactly? Regardless, I have a top-loading NES, and am unsure of the origin. All I know is that recently, it’s the only working NES system that I own. I use the word “working” loosely, here. The system would power on, but would only show static. After leaving the unit running for 10 minutes or so, the video and sound would slowly start working again. Not the worst thing in the world, but kind of annoying.

I’d heard that similar problems could be caused by bad capacitors, so I figured I’d try a DIY fix. Searching around online produced one of many small hobbyist shops that specializes in retro game tech: Mortoff Games. Amid many DIY products, they sell a complete capacitor replacement kit for NES systems. I’ve got rudimentary soldering skills (and it’s only five capacitors), so I thought I’d give it a shot.

The general process is to remove the solder around the existing parts, using solder wick or a solder sucker, then replace each component. My wick was almost completely ineffective in removing the existing solder from the PDB, but I persevered. Trolling YouTube for “howto” videos produced the advice that adding a small amount of additional solder can help trigger the wicking action. I think part of the problem was that the board is so thick, too. Next time, I might try a solder sucker. Putting the replacement capacitors back in place was way easier.

Amazingly enough, after I put everything back inside the case, it worked! The unit powers on with perfect, crisp video and sound. For a beginner-level project, it was definitely a success. I’ve been introducing the kids to some older games, now that the system is working reliably. I just hope this isn’t the start of more re-capping projects…

Narrator: it was!



So, after a very, very long time, I’ve decided to come back to my neglected website. A few years ago, when I was working at Nationwide Children’s Hospital, I had more than enough time to spare to learn basic system administration and write blog posts. However, since coming (back) to CoverMyMeds, I had less desire to work with computers outside of the regular 9-5. Late last year, however, I ended up switching teams, and while the new team is good, the work just isn’t as satisfying as it used to be (I could probably write a whole essay on that, but we’ll save it for another time). Therefore I’ve started itching to do “extracurricular” activities.

One of the things on my list has been to ditch ReCAPTCHA from my lame commenting system. The main reason is that, in general, I’m de-Googling. I was an early Google user (snagged my preferred username on Gmail by signing up on April 1st, 2004; remember how folks thought 1GB of storage was an April Fool’s joke?), but they’ve transformed from the scrappy tech-nerd underdog to a giant data-sucking behemoth. I’ve been taking steps to preserve my online privacy by installing browser add-ons such as uBlock Origin, which really enhances my web experience — with the unfortunate side effect that some sites break, because they expect certain JavaScript trackers to be present. This includes ReCAPTCHA. ReCAPTCHA is mostly a black box, but in general it forces users to help train Google image recognition, and in part seems to determine your “human-ness” by your activity on Google properties. I don’t really want this for myself, so it also doesn’t make sense for me to force it on the few folks who might stumble across this site.

Following a recommendation on Twitter led me to hCaptcha. It’s basically a privacy-enhancing alternative to ReCAPTCHA — it uses similar checks to prevent abuse, but is not helping Google hoover up all the datums. Of course, hCaptcha makes it pretty easy to change a few lines and start using their service. In making the change, I struggled more with updating the super old versions of the Ruby libraries running the comments app, rather than with any hCaptcha problems. I’d recommend giving it a shot!


Developing for Apple Watch

Recently I was tasked with developing an Apple Watch extension for an existing iOS app. Since I have no interest in Apple Watch, I’d never taken the time to use one, or investigate the development process. After about a month of banging my head against the keyboard (in a metaphorical sense), I thought I would complain about my experience on the intarnets.

First of all, Xcode won’t install development builds if the watch is locked, and the watch locks itself on sleep when not being worn. So you basically have to be wear it in order to do any sort of active development. Annoying if wearing something on your wrist is irritating whilst typing.

Speaking of wearing the watch: the plastic band which is included with the cheapest watch is the absolute worst. To secure the clasp, you need to thread the loose end of the strap in such a way that the rubbery exterior rubs right against your wrist, catching and pulling out every arm hair in its path.

When testing a watch app on the actual device, the app never launches automatically. Xcode says it is running, but there’s no indication on the watch itself. My technique here is to open an unreleated app, which seems to trigger something and remind the watch that it’s supposed to be running the development target.

The watch simulator is no better. Apple Watch has two modes of interaction: touch and “Force Touch.” The simulator’s default option is to differentiate between the two by using Apple’s new pressure-sensitive trackpads (if available). Problem is, it doesn’t work. Then you need to switch input modes by using a keyboard shortcut. Except the shortcut doesn’t always work either. When trying to bring up a context menu, I’ll Cmd+Shift+2 to trigger a “deep press,” then tap the simulator, and nothing happens. It seems to randomly work on the 3rd or 4th try.

Communication between the watch and phone is slow and/or buggy. Even on the simulator! I guess maybe they’re trying to totally emulate real-world behavior, which in that case kudos all around. I will randomly get WCErrorCodeMessageReplyTimedOut errors, then do the exact same thing a second later and have it work flawlessly.

Speaking of communication, you’ll probably want/need to communicate with the parent iOS app from a number of the different views in your watch app. Problem here is that only one WatchKit class can receive messages from the phone. So you end up making your extension delegate the message-sending delegate as well, and handle communication within the watch app by sending notifications everywhere. For a simple app it might not be so bad, but that sort of architecture gets unwieldy rather quickly. Maybe I’m just a dummy, but Apple’s documentation sure doesn’t mention any other potential design patterns.

Speaking of documentation, Apple’s documentation is… not great. Many times there was no differentiation between watchOS 2 and watchOS 3 APIs. I spent a ton of time finding out that it is impossible to share UserDefaults between watch and phone. Problem is, it used to be possible, and so I fiddled about implementing “solutions” that never worked. I ran into two issues that the documentation makes no mention about. I don’t often ask questions on Stack Overflow, but did for these particular problems. The answers I got were underwhelming, to say the least.

Basically, the entire process was death-by-one-thousand-cuts frustrating. I wasn’t bullish on the entire concept of smartwatches, and if this is what the “best” has to offer, I might be put off it for good.