I love these, but I really want to see one in true 3D with a globe and projected ECEF coordinates.

For a similar theme, there are some fun txt bulletins of critical importance to time keeping that have amusingly informal formats. ie: this is the official reference for current and upcoming leap seconds, and it's formatted as a letter from a specific person:

datacenter.iers.org/data/latestV...

"the standard HTML elements don't have the functionality users have come to expect"
->
replaces `<a>` tag with custom links that lag and don't support click to navigate, show AI slop on hover, 10MB of react deps, override copypaste.

There are also many great C++ tips here (that actually apply to most languages), and the gist generally boils down to avoiding hierarchical/nested data structures and stdlib maps in favor of arrays. This basic idea leads to simple programs being fast and enables further optimizations when needed.

vector-tile-spec/2.1/vector_tile.proto at master · mapbox/vector-tile-spec Mapbox Vector Tile specification. Contribute to mapbox/vector-tile-spec development by creating an account on GitHub.

proto is still viable, but once you use the core subset of features, enable lite runtime (disabling reflection), & spend a lot of time thinking about the binary representation anyway, a simple custom raw binary format doesn't look as unattractive as it would otherwise.

github.com/mapbox/vecto...

Lots of good performance tips here: abseil.io/fast/hints.h...

The protobuf section is especially solid, and lends credence to my belief that proto is full of anti-features that will bite if not actively avoided.

w3w, blockchain map verification, smart ___, geofencing, hashtag-BIGDATA/Hadoop, IBM data baby (digitwins), "spatial <is/isn't> special", cloud-native, ML-powered (RIP), realtime, every-database-gets-a GEOS-extension-and-geometry-type, BI excel map plugins w/ inexplicably blurry basemaps, map mashup

The TLDR can be summed up with this quote that I love from Carmack:

"you should be made constantly aware of the full horror of what you are doing"

With every long-running program, there is some form of a while(1) loop. Some notes on the importance of maintaining control of this structure to understand where, why, and how long your code is running:

morganherlocker.com/post/Control...

I upgraded my version of AndroidAPS + Android 16 tonight, the firmware for the open source artificial pancreas system I use. It took 2 hours to track down bluetooth issues, and I fried one insulin pump, but I got it all built from source, sideloaded, & running nominally. Feeling very cyberpunk. #T1D

I like the spirit of "choose boring technology" but disagree with the common conclusions (big databases, frameworks). Write directly for the platform and you typically end up with more efficient code and more durable skills, whether that's webdev or scientific computing. There's nothing more boring.

Map created before the first antarctic expedition that would have continuous communication back to the US over short wave radio relays. I stumbled on this in the Maritz Map Room of the Seattle Public Library.

Added an ADSB kinematics data exporter for aircraft tracking via adsb.lol. Here's an Osprey doing loops around LA.

Spent the last few days optimizing performance to support many channels. Here's me real-time tracking/searching every active satellite in orbit via celestrak.org w/ kinematics propagated at 1hz x ~100k channels. UI is super low latency and server is not breaking a sweat at ~6M updates per minute.

For better or worse, the complements of the web were successfully commodified. Linux won the datacenter, then open browser engines/ecosystems won the desktop, and now the process is playing out in AI (especially Chinese labs). Once it happens, the marginal opportunity in an N+1 project is low.

Bring back inertial navigation Going deep on Etak and pre-GPS navigation tech got me thinking about what an inertial navigation approach might look like today. Sensors have only gotten more sophisticated and having to map-match yourself onto the route really doesn’t sound like that big of an inconvenience in exchange for tossing all the surveillance potential of GPS and tower triangulation-based geolocation tech. This is the only technical idea that I actually think could be cool and useful.

this idea from @lifewinning is so cool, i had not heard of inertial navigation placing.technology/i-was-in-a-bad-mood-and-... https://en.wikipedia.org/wiki/Etak

I wrote an exporter from my artificial pancreas loop system to the database. I can monitor glucose readings, automated insulin doses, etc., along with summary stats. I use tailscale to send data from my phone to the server, and can view from any machine connected to the VPN (like my laptop). #t1d

These formats tend to trade core metrics for a long tail of features. I'm not totally convinced WASM is worth it here for most data, but could be useful for large datasets where data-to-header ratio is favorable & future accessibility is paramount (ie: census data or climate data).

"F3: The Open-Source Data File Format for the Future"
db.cs.cmu.edu/papers/2025/...

A new contender to parquet. The most unusual aspect of the format is that it can embed WASM decoders directly in metadata, aiding portability and future-proofing. WASM is optional - perf looks OK, but size is meh.

Screenshot of database dashboard with network debugger open showing 7.41KB per request

Database binary format sketch with bytes per component

I built out a binary format for the database, along with gzip/zstd compression (using gzip for now because safari is slow to adopt). A fully loaded channel is now 7.41KB per request. Can probably trim down slightly more with zstd dictionary training, but it's already very compact before compression.

Vanillajs is a thing, and it works great for me. Installing half the internet is a project-by-project problem and I expect we'll see the same supply chain attacks occur in any ecosystem with similar package governance, once they get big enough and old enough for widespread bitrot, ie: rust/cargo.

Added t-digest to the db, which allow percentiles to be estimated with a fixed memory footprint per channel. This is useful for key stats like medians, but also allows me to generate approximate CDF/PDF plots for understanding value distributions. Aiming for ~4KB total footprint per channel sketch.

I also use uplot, which has an edge in practical performance, but with less features and documentation. I find myself struggling with overlapping labels and value text formatting using either lib. While uplot is faster, the API is still memory heavy (array-of-structs data representation).

I've used observable plot for a few projects now, and can basically endorse it with a few caveats. It provides excellent charts out of the box, with minimal configuration, free of chartjunk/widgetjunk common in python viz world. It's surprisingly fast, but could be faster w/ a simpler feature set.

First pass at a batch POST endpoint; benchmarks for single batch, single channel, best of 5 samples each:

- 1 week @ 1hz: 12ms
- 1 month @ 1hz: 27ms
- 1 year @ 1hz: 221ms

The implementation is similar in timeseries features/function to Windows Task Manager, which is 5.6MB on Windows 11, vs 37KB (uncompressed) for this application - 2x smaller than the OG Task Manager for Windows NT 4.0 in 1996!

Now I'm adding batch endpoints for high throughput / high cardinality.

Added a search bar and a number of demo feeds I'm using for testing the database. Here's me searching for ISS telemetry, then checking a channel that tracks the volume setting on my macbook, which updates in real-time.

I made a video showing all aircraft within 100 miles of the EC president's aircraft during its flight to Plovdiv. One other aircraft exhibited symptoms of GPS interference at around the same time.

Put it on the pile next to "I need to pay for a fresh prescription for insulin every few months for the last 30 years" I guess.

Beautiful symbology on these! Also, TIL SF was full of horse race tracks.