qrohlf

Not sure if you're looking for paved or unpaved backroads, but if it's the latter I recently shipped a feature at my day job (https://ridewithgps.com) that highlights all unpaved backroads, visible up to zoom level 8 (above zoom 8 we start running into tile size/data limitations).

May be useful to you or others in this thread. We lean pretty heavily into the "cycling power user" market segment, the feature set isn't always the most discoverable but it's quite comprehensive if you put in the up-front time to learn the tooling (similar to a lot of other specialty mapping apps out there - caltopo, fatmap (rip) etc)

Prior art here would be relive.cc which pretty much built their whole business on this concept applied to the cycling market

There’s some regulation here to contend with that mandates these EV sounds have to include a 1khz-4khz tone which is probably what you’re noticing since it’s on the higher end of the usual urban audioscape. The Verge did an interesting piece on this recently – https://www.theverge.com/24182348/ev-sounds-low-speed-survey...

Definitely reminded me of the classic Mickens usenix login;logout columns! Just overall a very engaging communication style for adding some entertainment value to what might otherwise be pretty dry to read in one sitting.

While it's not particularly surprising that the location of a piece of radio hardware that broadcasts a static identifier is trackable, it is pretty interesting how the location awareness and ubiquity of modern smartphones are effectively creating a massive distributed sensing network. The focus on this piece is mostly on how apple (by designing their api in a way that avoids apple computing your exact location on their servers, presumably in an attempt to _preserve_ user privacy) inadvertently gave public access to that sensing network. I'd love to read a piece that also games out what exactly a red team or attacker could do with _privileged_ access. I.e. "if somebody was able to compromise the location services servers, but not iOS, what exactly would they be able to do with that"...

renew it and cancel it immediately

This is the way I use most subscription products. There are a lot of pieces of software that I think do actually make sense to charge a subscription for rather than a one-time payment; almost all the software I use daily in 2023 has some kind of server-side component or ongoing maintenance/development costs and I don't mind paying for that. It's the auto-renewal aspect and all the dark patterns associated with cancellation that I really despise.

One thing that I do now is try to use iOS to initiate subscriptions as much as possible, since the Apple-mandated subscription mechanism there lets me easily and immediately cancel auto-renewals for a new subscription as soon as I sign up for it.

I don't love that the walled garden approach seems to be the only way to restore sanity here and would love to see something standards-track and cross platform emerge for signing up for, listing, and cancelling software subscriptions in one place as part of the functionality provided by your OS. Basically, "passkeys for subscriptions". Maybe someday!

I’m also curious to see some examples – I used to work at a well known software company in the outdoor recreation / fitness space that made a really big deal about social justice both internally and externally. You would think they’d also be strong on the environment given the market they operated in but the minute you brought up conservation or environmental justice in an all-hands q&a they would immediately shut the line of discussion down hard.

I’m guessing it’s a much more significant hit to the bottom line to take a hard stance on environmental stuff vs DEI/social justice etc, which kind of surprised me but I can’t think of another explanation. It’s not like they were afraid of alienating market segments due to political alignment, since their (good imho!) stance on antiracisim was definitely just as politically charged as taking a strong stance on sustainability would have been…

I’m curious what their best-case outcome is here. It’s fully transparent at this point that Apple has no appetite for a third party iMessage client on any platform and will take whatever technical steps needed to prevent this from happening.

I’d wager heavily that even if Beeper plays cat-and-mouse to the point where they’ve exhausted Apple’s budget for blocking them and somehow managed to avoid Apple’s legal team putting a stop to things via other channels (very unlikely), Apple’s next move would likely be to release some kind of official iMessage Android client rather than cede control of the space to Beeper.

It’s easy to read this as a pure publicity stunt on Beeper’s behalf, but that’s not what I’m getting from the tone and content of these announcements. And I also don’t think the market for a paid all-in-one chat app is large enough to justify the expenditure that this iMessage for Android project represents, if the endgame is ultimately a PR stunt.

They seem too smart to realistically think that Apple is going to just shrug and let them continue unbothered after a few rounds of back-and-forth, so what are they playing at?

Early versions of Trianglify supported noise addition using feTurbulence but I ultimately removed it because of some of the rendering inconsistencies mentioned in this thread, alongside performance issues on certain platforms (you would think that generating 2d monochrome noise would be pretty cheap in this day and age, but it must be part of the SVG stack that never saw much optimization because it would absolutely lock up rendering for several hundred milliseconds when applied to even moderately sized viewports).

Of course, this was all back in ~2015 so the landscape has definitely improved, but not quite to the point where I would consider adding support back in.

https://mela.recipes/ does this with its built-in browser/parser thing (and it has a bunch more incredibly useful stuff).

Highly recommended, it's from Silvio Rizzi of "Reeder" fame so it's a one-time purchase built with extreme care by a solo dev with excellent product instincts. Huge fan of his work, this kind of high-craftsmanship software is just so pleasant to use.

I know some folks who are doing this in the food blogging space, see https://tastytango.blog/

It's hard to pin down exactly what I find so unsettling about the practice – it's almost like the uncanny valley, but for written content that apes human expression instead of imagery?

For anyone else who follows along in this domain, there's an interesting competitor in the space I stumbled across recently: https://felt.com/

Pretty nice looking product and robust feature set. Love to see GIS tooling becoming more accessible.

You want "Unauthorized Bread" [1]? Because this is how you get "Unauthorized Bread".

[1] https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-...

We were adding in new features like huddles, canvases, lists, and others into a UI system that was originally designed solely for messaging capabilities. Meanwhile, research showed users on the biggest and most active teams were struggling to stay on top of the basics.

"Our telemetry says that the random stuff we're bolting onto the product (like a document system (?) to go inside our chat app) is making it less usable and less good for users. So instead of listening to that feedback and telling management that our projects weren't actually helping users, we decided a better way to get promoted was to do a redesign."

Operationalize transparency to build alignment

"We spent a bunch of money on a huge all-company onsite/whiteboarding session, then we proceeded to ignore the feedback from everyone who wasn't middle management or higher."

As a fun and instructive exercise, read through this, then read through Slack's post-Salesforce-acquisition Glassdoor reviews[1].

[1] https://www.glassdoor.com/Reviews/Slack-Reviews-E950758.htm

This exact SSD failed on me in a similar way. They also recently had a firmware issue that borked a bunch of drives, and they only released a fix tool for Windows users (I guess macOS/Linux users can pound sand?)

I will say that the warranty service was quite good, but given the below-zero level of trust I have in SanDisk post WD acquisition, the replacement drive is going to be basically fulfilling the role of “paperweight and very oversized temporary USB drive for ephemeral sneakernet transfers”.

Bought a pair of Samsung T7’s to replace it, no issues with them so far.

Before you attempt to do anything, first try to assess whether your organization and/or management has a strong “don’t rock the boat” culture. In my experience, an isolated contributor moving super slow might be down to the individual, but a whole team moving slow is usually due to systemic factors.

Attempting to create accountability or meaningful changes to velocity in a “don’t rock the boat” org is usually a one-way ticket to workplace politics hell. If you value building things, small-startup style, you will likely want to avoid this.

Finding a good manager who is willing to give you special-mission style projects to execute on quickly and effectively is often a far better strategy than trying to deal with widespread molasses speed dev culture. Even better, typically, is moving to an organization where the culture and peers match up better with your desired speed and quality of execution.

Have a peek at https://doingmiles.com/hike-sf/ for some longer itineraries like this. Lots of options if you're willing to do a little stealth camping (please be ethical/considerate [1])

[1] good writeup from the same authors https://doingmiles.com/techniques-stealth/

I solved the response-time problem in a different way, but that would be one option you could use to cut down how much a notification pipeline contributes to your time-to-claim-permit latency.

You can browse the site and look at the network traffic in your browser's devtools. There are some radically different response structures for the various different land management agencies.

The complexity comes in the fact that there are different data formats and rules in play for almost every single management agency's permit/reservation system on Rec.gov - the JSON responses for, say, a trailhead in National Forest in Inyo Country, CA are different from a trailhead in National Forest in Deschutes County, OR. And those are both different for the JSON response format for a trailhead in the King Range National Conservation Area. Which is different from a trailhead in any National Park. And so on.

And all of these different permit systems trigger different forms, agreements, vehicle information collection, etc. once you move to the checkout stage. It truly is a massively complex system - if not technically, then logistically, by the sheer quantity of requirements-gathering and accommodation of hundreds of different individual land management agencies' unique systems for managing user access. I've read some of the source code for the web client (last I checked, they were still publishing source maps to prod) and it's a pretty impressive feat that it works and holds together as well as it does.

As you can tell from my comment above, I'm just as incensed about the business model as you are. It is highway robbery. Taxpayers subsidized the creation of the site, and now we're being doubly ripped off as a huge portion of the profits collected are being funneled straight back into the pockets of Booz Allen (and, no doubt, also being channeled into lobbying efforts designed to maintain this monopoly through the renewal process for the Federal Lands Recreation Enhancement Act this October).

However, I don't think that unfairly diminishing the technical and organizational achievement the site represents is going to help with trying to find a solution to the economic grift that it also represents.

This is something where every single person who appreciates public lands should be mad as hell, and letting their elected officials know.

For a more in-depth analysis of the dubious legality of the whole situation, see Matt Stoller's excellent article "Why Is Booz Allen Renting Us Back Our Own National Parks?" [1]

Also, as someone who runs a private, substantially more aggressive availability monitor than outdoorstatus.com (updates every minute rather than every 30 minutes), the unfortunate reality is that the permit scarcity has created something of an automation arms race.

Looking at my analytics for today for a few examples, I see 1 permit availability for the Enchantments that was snagged in less than 5 minutes after being posted, some availability for Lost Coast that disappeared in under 4 minutes, and finally 5 different availabilities in Yosemite's Upper Pines campground that disappeared in under 60 seconds. A 30 minute update rate is, sadly, not going to do you much good if you want to be competitive at reservations for any popular site near the Bay Area on a weekend.

In a lot of cases, the latency of the Twilio -> SMS process is long enough that by the time I get a notification of availability, it's already been claimed by someone else's bot.

This is depressing because, while I have the knowledge and tools to play in this adversarial sandbox of permit acquisition, the majority of people in this country do not. Your access to public lands should not be contingent upon your network programming skills or how many IP addresses you're able to stripe your requests across to avoid ratelimiting.

While I expect to see many more pay-to-play services like Outdoor Status, Campflare, Campnab, Campsite Monitor, etc. pop up over the next few years, what I'd really like to see is a service that disrupts Booz Allen Hamilton with a business model that eliminates its monopoly and the junk fees that are central to how it profiteers off its role as the Ticketmaster of public lands access.

[1] https://mattstoller.substack.com/p/why-is-booz-allen-renting...

Yeah, exactly. THAI_SPICY_HOT was just one of many signals that I got that the MonkeyC project could have very much started out as an intern project or similar.

The list of languages the documentation claims MonkeyC takes inspiration from also denotes a certain type of programmer background:

C, Java™, JavaScript, Python™, Lua, Ruby, and PHP all influenced the design for Monkey C

(source: https://developer.garmin.com/connect-iq/monkey-c/)

If I asked an embedded hardware expert to design a novel programming language for my highly resource-constrained wearables platform, I would be very surprised if these were the language touch points they used as their references in the design brief.

My sense, as someone who has written more than one CiQ app is that Garmin got caught completely by surprise with the popularity of 3rd party apps on wearable platforms and MonkeyC graduated from “interesting side project” to “critical ecosystem capability” in the space of a couple months, years ago. The early CiQ SDK versions had some truly insane conventions like using constants named “THAI_SPICY_HOT” for font sizes, and the development platform (as others have noted in this thread) has always been a barely functional tool chain with minimal error handling, no compiler optimization, no debugger, simulators that don’t match the device ROMs, etc etc.

For a long time this didn’t really matter since the Apple Watch and Garmin devices really appealed to two very different market segments - Garmin had a huge moat in first party fitness capabilities, maps, and battery life, and Apple had a huge moat in UX, their app ecosystem, the screen quality and device style, and smartwatch functionality.

Now, both companies are closing the gap in both directions on many of these aspects. It will be interesting to see what effect (if any) this will or will not have on the CiQ tooling and the CiQ ecosystem.

The funny (unfortunate) thing is that this used to be the opposite - years ago, Chase's in-house travel service was as close as you'd get to a white glove phone support experience in this day and age.

Then they outsourced it to Expedia, and the hold times went up and the efficiency and sanity of the whole process of dealing with any minor adjustment to your flight or travel plans degraded precipitously.

It seems like in 2021, they bought the company that was providing the backing technology for the in-house version of the service and have ditched Expedia again, so maybe this has gotten better since my last stint of big international travel?

The problem is the duty cycle, not screen real estate - if you show a relative time, it needs to update frequently to remain accurate.

If it's 5:27 right now and the BART comes at 5:38, I need to update once per minute if I'm showing a "+11m" for that relative time to remain accurate. Since the display takes more than 30s to refresh and isn't readable while it's refreshing, that means it's useless > 50% of the time I try to glance at it.

Whereas with my current setup, I only update it once one of the BART arrival times is no longer in the future. So, right now it's showing arrivals at 6:23, 6:29, and 6:44. Which means the display will update at 6:23, 6:29, and 6:44. There's a little extra optimization added to only show BARTs that are at least 5min in the future, since the BART is a 5min drive from the location where the display is. Depending on the BART schedule, all this works out to roughly ~8min update cycle on average, meaning that the display is only unreadable due to refreshing about 6% of the time, which I find to be very acceptable.

They’ve offered this product in 5.7" and 7.3" sizes for at least a year.

I have one in the 5.7" size that I use to show realtime BART departures for the station near my house. It's useful but the 30sec refresh time means I'm limited to showing arrivals in wall-clock times (i.e. "5:38pm") rather than the more useful relative time format ("11 minutes from now").

If I was going to upgrade, I would probably ditch the color support, use a Banana Pi Pico for the controller (cheaper, has USB-C instead of MicroUSB) and go with a higher resolution monochrome display with a 1sec refresh, like this one: https://www.waveshare.com/6inch-hd-e-paper-hat.htm

Yep, exactly. My personal vehicle is a 2000 model year Toyota. It has an incredibly good, stable, and modern CarPlay head unit from Sony, because back whin the car was made we had standards like double-DIN head units and you could just plop in a new stereo. Which is exactly what I did, and now I have a "golden age" mechanically reliable, nigh-un-killable Toyota with a modern carplay head unit.

And as a bonus, I can adjust everything about the car (climate control, volume, overdrive, 4wd, ECT mode, etc) with real buttons and tactile feedback while going down a washboard track, without ever having to take my eyes off the road.

If anyone out there starts making EVs with the same bare-bones attitude (analog knobs and dials, no flashy infotainment system, double-DIN head unit slot, modern safety features and a simple ultra-reliable EV powertrain), sign me up. It'll probably never happen because there's not really an economic incentive right now to try to hit lower price-points in the EV market, everyone's going upmarket. But I'd still love to see somebody try.

I was recently an owner of a Merced-Benz commercial van, and the software was by far the worst part of that whole experience.

It had obvious race-condition type bugs when it came to the user interface layer, but most frustrating was its tendency to succumb to some kind of memory leak on long drives where the entire head unit would just lock up and crash to a black screen after 6-7 hours of being turned on. Because the vehicle kept the computer system "warm" for up to 30 minutes or so to avoid doing a full (and slow) bootup process every time you stopped for fuel, this was a real problem on long trips and couldn't always be solved by power cycling the vehicle.

Had a dealer try to update it twice, which didn't seem to meaningfully impact the system stability at all.

Then there were multiple other, non-head-unit related glitches like the lane assist and cruise control features being incompatible with the state of Nevada (if the system fails to detect any other vehicles for a period of more than about 90 minutes, it assumes that there is a sensor fault, and refuses to operate [1]. Unfortunately it is quite easy to spend hours on the road alone in many southwestern US states, triggering this failsafe mode)

Suffice it to say that I am very skeptical of any software coming from Mercedes these days.

[1] https://www.winnieowners.com/forums/f265/2019-sprinter-cruis...

privacy.com does this and it is quite good. You do lose the ability to collect rewards points on purchases though.

I also wrote my own system for pretty much this exact purpose, although instead of emailing me reminders, it just lets me record notes on a map and then I skim that map whenever I am planning a trip to a given country or region.

It's online (but registration is invite only, let me know if you want to play with it) over at https://scoutmaps.io/ – at one point I was going to attempt to commercialize it, but eventually decided I liked it better as hobby software so that I can write features that better serve my current userbase of one :)