So I ran the Columbus Marathon this year. It was the first time I’d run it since 2007, so only a gap of 14 years! I strained my right Achilles tendon pretty
badly after doing a half marathon right after the marathon in 2007, and didn’t have the knowledge of how to rehabilitate it successfully, so stopped running
for quite some time. In 2017 I got inspired by watching a documentary about the Barkely Marathons, and started running again, only to be stymied by runner’s
knee. The knee pain was really quite chronic, but after probably about two years of various physical therapy exercises, I was able to (mostly) banish it.
In 2019 I signed up for the half marathon, and was able to finish in 1:35 — not bad for a casual runner being out of training for quite a while.
I had been planning to run the full marathon the next year, but COVID quashed that idea. I ended up deciding to train as normal, then run 26 miles on
the day the marathon would have been, just for fun. I did that, and then also signed up for a timed “race” that used staggered starting times to
avoid potential COVID exposure. I “bonked” during both those runs; the first was due to dehydration, and the second was also due to dehydration. Dispite
that, I was able to improve my PR by a few minutes each time (3:40 for the first attempt, 3:31 for the second).
This year I had an advantage in that I ran a staffed race, so hydration stations were available throughout the course, without me having to carry my
own water bottle. I made a point of slowing down to drink at each station, and always chose Gatorade in order to get extra calories/electrolytes. While
the strategy wasn’t foolproof (I ran 0:30 slower than my target pace for the last 3 miles of the race), I was able to finish without walking, and got a
new PR (3:18).
After the race, I wanted to write down my thoughts of how it went; hopefully in order to do better next time. Here, in no particular order, are some
random observations about this year’s race:
Somehow strained my right calf on the 2 mile run the day before. It was coming off a two day rest, and I didn’t warm up my calves/ankles as much as
I normally would have. Fortunately a combination of stretching/ice multiple times that day seemed to help. I also wore calf compression sleeves
(which I originally wasn’t planning on wearing), which also helped — I didn’t have calf pain during the race.
I didn’t want to go too fast during the initial mile, running around other racers and tiring myself prematurely. I was quite a bit back from
the starting line, and ended up running 0:30 slower than my target pace.
About 7 miles in, I noticed that the ball of my right foot was getting painful. I had never had this sort of pain in training. The shoes I was
wearing were well broken in, so my guess is that it was a remnant of when my daughter jumped on my right foot while we were in a trampoline,
two days prior. The pain got progressively worse, but was not debilitating. However, it took me quite a while to recover afterwards.
I also ended up stopping at a port-a-potty around mile 8. The urge wasn’t terrible, but it would have been an additional source of discomfort
during the race. Note to self: always try to go beforehand.
Mile 18 was the hardest, due to wind/fatigue and an uphill grade. However, it was encouraging to pass other runners during this section.
When trying to push going over an incline on Nationwide Boulevard close to the end of the race, my right hamstring started cramping up. I had to
stop for a moment and stretch it out, allowing at least one other runner to pass me.
I didn’t spend any time stretching/recovering later on in the day after the race; this probably made my soreness worse over the next few days.
Base your Docker image off ruby:3-alpine, and add a few packages: build-base to compile native extensions,
nodejs for a JS runtime, yarn for JS dependency management (both required for Webpack), and sqlite-dev for
SQLite (the default database used in a new Rails installation).
FROM ruby:3-alpineRUN apk update
RUN apk add --no-cache\
Build the image: docker build . --tag minimal_rails_image
Get in, loser! docker run --rm --interactive --tty --volume $(pwd):/app minimal_rails_image sh
Install the rails gem: gem install rails
Bootstrap a new Rails application: rails new .
Add tzinfo (Alpine doesn’t have it, apparently); remove the platforms: arg from the gem 'tzinfo-data' line.
I also had to remove the reference for it in the lockfile, before running bundle install again
Re-build the image: docker build . --tag minimal_rails_image
Run it (detached): docker run --rm --detach --name rails_container --volume $(pwd):/app --publish 3000:3000 minimal_rails_image.
You should now be able to hit localhost:3000 in your browser and see the “Welcome to Rails” splash page.
Rails console in running container: docker exec --interactive --tty rails_container rails c
Tail logs: docker logs --follow rails_container
Shell prompt: docker exec --interactive --tty rails_container sh
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.
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!
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.
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…
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.
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!