Zwift recently released a new set of routes on a made-up island called Makuri. Different from some of the other maps, this one has a ton of cross-roads, and there’s a lot to see. It’s pretty. So, of course, instead of cycling there, I thought it would be a fun exercise to find the shortest path that lets you see everything at least once.
Without further ado, here’s the optimal path:
Making a hardware button that connects to wifi and sends a request off to a server is possible using Arduino. Light switches are (almost) immediate – but simple wifi switches easily take 8-10 seconds to connect & switch. How do you get that time down? Here’s my approach.
Measure end-to-end - what’s the default time? Is it really that bad, or just sometimes bad? Split into parts Measure the parts Determine which parts should be optimized, and try options Combine the best options Debug why it doesn’t work and try again The computer we’re using to run on is an ESP8266, model ESP-01.
Collection of random things that ended up needing to be cleaned up.
Redirect “popular” pages from Search 404’ing Search Console, Performance report, max timeframe Export to Google Sheets Copy top N (your pick) URLs to clipboard Open Screaming Frog Mode -> List Upload -> Paste … oops
It’s May 2021, time for a new site, right?
Thanks for dropping by!
If you’re curious, I have a bit about the site written up here. I thought my blog had gotten a bit stale, so I might as well make it completely static. Then, in putting together the static version of the site, I ended up writing a bunch of new posts. … and also realized that there were various other things hangout around which would be nice to include.
Anyone can act like a bot just by using the Googlebot useragent in a request. Sometimes crawlers do that to see what other bots might see. Sometimes it’s to circumvent robots.txt directives that apply to them, but not to Googlebot. Sometimes people hope to get a glimpse at cloaking. Whatever the reason, these kinds of requests can be annoying since they make log file analysis much harder.
Motivation for this excursion:
Having to choose between “too loud” and “too quiet” sucks. Unfortunately the Spotify web UI has an annoyingly short volume slider. Fortunately that’s easy to fix with a bookmarklet.
Drag this bookmarklet to your browser bookmark bar, and click on it to expand the volume slider. The code is pretty straightforward, it just changes the CSS slightly.
Just a collection of command line tweaks. These work on Linux, probably mostly on MacOS too (and who knows, with things for Windows probably).
(content irrelevant, just adding an image)
Basics General command-line tips Todo: find some other sources
Pipe tricks: | more - show output paginated (use space to get to next page) | less - similar to more, but with scroll up/down | sort - sort the output lines alphabetically | uniq - only unique lines (needs “sort” first) | uniq -c - only unique lines + include the number of times each line was found (needs sort first) | sort -nr - sort numerically (“n”) and reverse order (“r”, highest number first) | wc -l - count number of lines Searching for things (more grep options)
After a USB keyboard with an ATTINY85, a try at one with ATMEGA 32u4, I’m now at revision 2/3 for the ATMEGA 32u4 single key, USB keyboard.
Overview Same as before:
a simple USB keyboard with 1 key reprogrammable tiny mechanical keyboard key cheap enough to give away actually works debuggable The “cheap” aspect was mostly to justify making & buying some :).
Hardware design Since the previous design mostly worked, I tweaked to make two versions.