A better Trader has been a work-in-progress project of mine for a very long time. The web UI was done in vanilla javascript, with old school imports, and PHP-style server-generated html, then added jQuery, then bootstrap, then started removing jQuery, then moved towards more-static html with JSON payloads for the data, then pined for better node imports, then then then. You get the point.

I went too long without a rewrite, so I recently became a weekend warrior skeletoning up the next gen web ui. Parts include:

  • Vite due to its blazing hot-loading, tree-shaking, polyfilling goodness
  • React because it’s good enough and gets the job done
  • Bootstrap because I won’t have time to finish the mobile apps for a while

For my UIs, D3 is the most important library there is. So the skeleton is based on responsively displaying a handful of some of Mike Bostock’s greatest hits (imho). This was quite important to me because D3 examples have been somewhat obfuscated when they were migrated to Observables notebooks. The skeleton makes it much easier for me to quickly get working D3 examples by copying Mike’s Observables code into a cozy little container with all the bells and whistles in place.

Let me know what you think of it.

Live Demo | GitLab | GitHub | Wiki

My little iPhone app is simple as I can manage (but no less, ha). SwiftUI is the new way, UIKit is the old way but huge, full of history – can I avoid it? It seems I can. I have login and logout, environment state across pages, tab views, REST API calls with JSON decoding, cookies, page navigation, etc. all working after the second busy weekend of work. And away we go!

I went swimming in the Atlantic for a couple hours. With my Samsung phone in my pocket.

So when I got an updated Android phone, I got an iPhone too. Time for some mobile app development.


Boost 1.77 is working well with it, and I’ve fully migrated to boost::json, which is working out great. The straw that broke the camel’s back was map.contains(), lolz. I was ready! I feel like I’ve had a hot bath. Nice.

TL;DR add this config to dnsmasq.conf to expand your LAN single-label hosts into FQDNs that systemd won’t hate:


For decades, DNS resolution was fine, and then systemd arrived and it was not. For the past couple years, for me and many others, systemd-resolved has been quite a headache, failing basic DNS resolution on any fresh Ubuntu (and other) installs. A real joy when you just want to get things going ASAP. After years of getting around it with shitty hacks, I finally nailed down what was going on.

Poettering and his crew decided that “single-label” host names on your LAN should never be allowed to resolve, even though it always used to in what he calls “classic DNS”. The systemd-resolved DNS handler in a vanilla install of Ubuntu 20.04 will drop your name resolution requests simply because the name does not have a dot in it. End of story. How nice. This awful default behavior follows some 2013 guidelines that were never previously enforced, at least not on me.

I use the simplest possible solutions that work, and for me that is dnsmasq. You can use one config file to configure static IPs for the MACs of all your LAN boxes. I just needed to reconfigure it to expand single-label names into longer “fake” FQDNs, with some dnsmasq hackery, and DNS on new boxes now works out of the gate. See the top of post (or this SO answer) for the configuration details.

There are supposed to be other solutions, like flipping on the LLMNR flag of systemd-resolved. That didn’t work for me, and I don’t want to have to futz with every single new LAN box and VM anyway. Hopefully this nightmare is behind me now. I hope for you, as well.