~ / cmdr2

• #findstarlink
• #performance
• #ops

The migration of findstarlink.com to Cloudflare Pages hit an issue (that I can’t describe here), but I had to roll it back for “reasons”. Would’ve been a nice cost-saver, but for now it’ll stay on S3. But the overall infrastructure of findstarlink (various components) is now quite streamlined, and pleasant to develop-for again. I also hit an issue when trying to optimize the loading time of findstarlink.com’s homepage on slow internet connections. On such connections, it takes a long time to download and parse cities.js (600 KB uncompressed, 300 KB compressed). And the UI thread is blocked while that’s happening (often for 10+ seconds).

• #cities
• #findstarlink

Released cities-db, a database of ~32,000 cities (cities in the world with population > 15,000), compressed into a format suitable for auto-complete on web pages (~283 KB) or mobile apps. The data is fetched from GeoNames.org, and processed into a custom format. Why? This library was created for findstarlink.com. It would be pretty expensive to use the Google Maps API for auto-complete, or host a dedicated API endpoint. And I don’t see why we need a remote service for this.

• #worklog
• #findstarlink

Migrated findstarlink.com back to S3 (from Cloudflare Pages), and started rewriting the website to improve loading speed.

• #satellites
• #findstarlink
• #sat-timings

sat-timings library released Released sat-timings, a Javascript library for predicting the optimal time to see a given list of satellites in the night sky. This library powers findstarlink.com and has served millions of satellite visibility predictions over the past 6 years. It’s written entirely in Javascript and is pretty fast.

• #findstarlink
• #ai
• #llm

I spent some time today doing support for Freebird, Puppetry and Easy Diffusion. Identified a bug in Freebird (bone axis gizmos aren’t scaling correctly in VR), got annoyed by how little documentation I’ve written for Puppetry’s scripting API, and got reminded about how annoying it is for Easy Diffusion to force-download the poor quality starter model (stock SD 1.4) during installation. The majority of the day was spent in using a local LLM for classifying emails. I get a lot of repetitive emails for FindStarlink - people telling me whether they saw Starlink or not (using the predictions on the website). The first part of my reply is always a boilerplate “Glad you saw it” or “Sorry about that”, followed by email-specific replies. I’d really like the system to auto-fill the first part of the email, if it’s a report about Starlink sighting.

• #findstarlink

Following up on yesterday’s post, there’s now full automation for the conversion of provisional NORAD IDs to the official one (once they’re available in Celestrak). This automation is still waiting to be deployed, because it needs to be tested with the official NORAD IDs for yesterday’s Starlink launch (G6-77), once they’re assigned next week. This automation has been now been deployed. So now, the only processes still done manually are (a) selecting a new leader for a train, if the current leader drifts away from the train, and (b) removing old trains that have spread out completely.

• #findstarlink

Spent two days automating some of the processes around findstarlink.com, and updating some of the code that had started bit-rotting. Most of FindStarlink’s operations run as individual AWS Lambda functions, that are triggered periodically by CloudWatch Events (and Schedules). But a few processes are still done manually, mainly due to a mix of laziness and also being a bit tricky to automate. I also needed to migrate the existing automations to a newer NodeJS runtime in AWS Lambda, since the current runtime was nearing end-of-life support.