macOS 14 (Sonoma) broke the “Emoji & Symbols” keyboard shortcuts (fn/🌐+e or control+cmd+space) on Firefox: instead of opening, the emoji picker briefly flashes and disappears:

If you use the “Edit… Emoji & Symbols” menu, the picker works - but it’s annoying to reach out for the mouse whenever you need an emoji or special character! I thought such an inconvenient bug would be fixed quickly on a minor Firefox or macOS update, but months passed and the bug was still there.

Between annoyed and curious, I dug the source code a bit and wrote a patch that fixes it, and also a secondary problem with the fn/🌐+e shortcut (introduced in Monterey as a replacement/alternative for control+cmd+space): it works sometimes, but when it does, it also writes the letter “e” where the cursor is, which is equally irksome.

For reasons that I will explain below, Mozilla did not accept the fix. They are working on another solution, but it will take a while to be released. Since many people have the problem right now, I decided to share some details about my fix here, alongside with instructions for applying the patch to the official Firefox source code or downloading my patched version - which I rebranded “EmojiFox” to avoid confusion and respect Mozilla’s trademarks/license.

UPDATE: In January 7th, 2025, Mozilla released Firefox 134, which contains the aforementioned fix (and they were kind enough to mention the work described here on the beta release notes ❤️). I strongly recoomend that you just update your browser instead of donwnolading the outdated build below, and swittch back to the official release if you are still using mine. I’m keeping the downloadable file here for historical purposes only.

In this age of controversial social media platforms, having a blog is one of the few remaining opportunities to keep ownership over your content. There are several good solutions around to publish and host one, but Jekyll and GitHub Pages are a great (and free) combination for people like myself who are happy hacking a little bit - except for not providing a comment system out of the box.

For years, I filled that gap with Disqus - a service that hosts your comments in exchange for a bit of advertising space. It was great at first, but over time ads became heavier, users were pushed towards creating accounts and abusively tracked. Moreover, hosting comments externally affects search engine indexing, and over time this all caused people to comment less and less, so I decided to bring the comments back to my blog.

A comment system isn’t a very complicated app, but it would be another database that I’d have to care for, and a departure from Jekyll’s static generation model that served me so well. The ideal solution would be to store comments in the same place I store posts: a trusty GitHub repository. Jekyll can read data files to show the comments, and all I needed was to host an app somewhere that would create those files when a new comment is written.

I almost coded that app myself, but Eduardo Bouças wrote and kindly shared Staticman, which does precisely that. Sure, I still had to host/configure it, adapt the blog to send it the comments (and read them from the repository files), and migrate the old comments from Disqus. These things combined took me a couple days, so I thought I’d share the process here.

Having a relatively short office closure week for the holidays led my wife and I to look for a sunny break from the Canadian winter, and we noticed a lot of Canadians chose Cuba for that.

Between the proximity (it’s a 3-hour flight from Toronto), the relative affordability and our desire to understand the country beyond the usual left/right political narratives, we decided to give it a try. Here are some highlights of our experience and a few things we wish we knew before going.

People get surprised when I tell them I keep all my personal software projects running on a single server, and that it costs me roughly a cup of (fancy) coffee per month. This post explains how I do it, and how you can do it too!

Why bother?

Every now and then I build a personal project that requires hosting on a server - sometimes it’s a website, sometimes a back-end API for a watchface, or even a multiplayer game server. In any case, it is tempting to use a free service or self-host, but eventually some of those prove to be useful to other people (or myself) on the long run, requiring a more robust solution.

Sure, one can always embrace the DevOps culture and build the projects with tooling that describes their infrastructure needs in code, deploying on a cloud provider. That works, but comes with a price tag that might discourage building new projects, and you don’t learn a lot about how things work behind the scenes.

In contrast, configuring and keeping a server up in a cost-effective, secure and robust way is a fun challenge in itself and a great learning experience. Even if you have a team or a service that does it all for you, getting some hands-on experience with servers makes you build better software, as you’ll be more aware of the constraints and trade-offs involved when it is deployed.

In the last post I described how I used an ESP8266 board to detect when my ancient doorbell rings, and trigger a notification on my phone. This time, I’m going to use the same board and a relay to unlock the front door, which, combined with the ring detection, will allow me to get deliveries past the front door, open it for visitors, and even unlock both that door and the internal one (which already has a smart lock) when I arrive home!

After years of living in single-room condos, we decided to try a more spacious, two-store house, which has a very old and low-tech doorbell: a button on the door triggers a “ding-dong” classic doorbell - very easy to miss if you are on the upper floor, causing all sorts of issues with deliveries.

Sure, I could make it ring louder, but it would be annoying for anyone on the lower floor. And I also want to automate other hurdles related to package delivery, so I decided to first get the doorbell to ring into my Home Assistant setup (where I can trigger all sorts of automations).

RFID + NFC = NExT implant

NFC (the tech used in mobile phones for contactless payments and contact exchanges) and RFID (used in product identification/tracking, building access cards and many other things) are found everywhere these days. I played a little bit with cheap tags that can be used to interact with phones, but implants are getting more practical, so I decided to give one of them a go!

(I know, I know: technically, NFC “is” RFID - or, specifically, is a set of protocols built upon a subset of the RFID ones, but I’m going with the commonplace usage of the terms: “RFID” for the unregulated “low frequency” 120-150 kHz tags that use all sorts of proprietary protocols, “NFC” for the “high frequency” 13.56 Mhz devices using specifically NFC)

I didn’t want to limit myself to a single technology (or to go with two implants), but Dangerous Things (yes, that’s the company name 😅) sells the NExT: an implant with both an RFID chip (that can simulate - or “clone” - fobs and tags on the wild) and an NFC chip (which can store 888 bytes of data, accessible to any NFC reader I touch, including smartphones).

There are some limitations: its NFC can’t be used for payments (like, for example, the Walletmor), and the RFID can’t emulate super advanced security, or hold multiple tags, but the combination is enough for a lot of uses, plus it’s a field-tested set of chips that should be operational for years and years, so I chose it.

• Part I: CPU (6507)
• Part II: Cartridge
• Part III: TIA (Video chip)
• Part IV: Clock and Composite Video
• Part V: RIOT (RAM, I/O, Timer) and Audio
• Part VI: Joystick, switches, fixes and wrapping up

It has been a wild ride, and it finally comes to an end. Here are the final tweaks I’ve added to this project, which results in a mostly working Atari 2600. Most importantly, I learned a ton and had a lot of fun. If you came so far, I hope you did too!

• Part I: CPU (6507)
• Part II: Cartridge
• Part III: TIA (Video chip)
• Part IV: Clock and Composite Video
• Part V: RIOT (RAM, I/O, Timer) and Audio
• Part VI: Joystick, switches, fixes and wrapping up

After Hello World

Now that I got Hello, World! running, I feel confident this project may actually succeed! 😅 The next step is to run an actual game, which requires wiring the last chip (and, due to the poor video I have so far, a sound circuit).

• Part I: CPU (6507)
• Part II: Cartridge
• Part III: TIA (Video chip)
• Part IV: Clock and Composite Video
• Part V: RIOT (RAM, I/O, Timer) and Audio
• Part VI: Joystick, switches, fixes and wrapping up

TV Time

In the previous post, I had the CPU, cartridge and TIA wired and tested, but still needed the Arduino to make them tick and check the resuts. All those hex numbers were fun to debug, but let’s get to the real deal: plugging it to the TV.