Yep, I’ve bought a few thermal printers recently and webusb support (marketed as Chromebook support) was a major deciding factor. Thermal printers aren’t well supported by built in printer drivers, so it’s nice to not have to install some questionable driver software with access to my whole computer and instead have a sandboxed chrome extension with enumerated permissions. I’ve also poked around the extensions’ minified js source out of curiosity and as a basic security audit
It was also nice trying out some RTL-SDR apps as soon as I got it without having to figure out how to build and install the Debian packages from source first.
It drives me nuts every time I have to switch from Firefox to Chrome to use webusb or webserial.
How does the security of userspace drivers compare to having drivers within a sandboxed web environment with access to only the devices you’ve explicitly allowlisted?
It's about the same. People will blindly click allow on a webpage in the same way that they blindly run libusb binaries with `sudo` that they copied from some webpage. Security is possible in all of these scenarios, but always undermined by the users.
GitHub seems entirely uninterested in improving the code review experience (except maybe the stacked PRs thing if that ends up shipping) for well over a decade now.
Things that I’d consider table stakes that Phabricator had in 2016 - code movement/copying gutter indicators and code coverage gutters - are still missing, and their UI (even the brand new review UI that also renders suggestion comment diffs incorrectly) still hides the most important large file changes by default.
And the gutter “moved” indicators would be more useful than ever, as I used to be able to trust that a hand-written PR that moves a bunch of code around generally didn’t change it, but LLM refactors will sometimes “rewrite from memory“ instead of actually moving, changing the implementation or comments along the way.
Yeah, Tesla gets to blame the “driver”, and has a history of releasing partial and carefully curated subsets of data from crashes to try to shift as much blame onto the driver as possible.
And the system is designed to set up drivers for failure.
An HCI challenge with mostly autonomous systems is that operators lose their awareness of the system, and when things go wrong you can easily get worse outcomes than if the system was fully manual with an engaged operator.
This is a well known challenge in the nuclear energy sector and airline industry (Air France 447) - how do you keep operators fully engaged even though they almost never need to intervene, because otherwise they’re likely to be missing critical context and make wrong decisions. These days you could probably argue the same is true of software engineers reviewing LLM code that’s often - but not always - correct.
The US commercial aviation industry did not get to its excellent safety record by simply shrugging and accepting a “no-fault accident”.
There are always systemic factors that can be improved, for example working on street design to separate dangerous cars from children, or transportation policy by shifting transportation to buses, bikes, and walking where the consequences of mistakes are significantly reduced.
Cars are the #2 killer of children in the US, and it’s largely because of attitudes like this that ignore the extreme harm that is caused by preventable “accidents”
"No fault" does not mean "no cause" and air crash investigations always focus on causes, not fault. When you understand causes, you can think about how to prevent them happening again.
I’ve found that adafruit usually includes a cuttable solder pad for the power led when there’s real estate available. Just cut one of those traces this week in fact!
How do I use a laptop while standing on a train each day? It sounds like a laptop is sufficient for you, but I suspect (based on myself and other responses in this thread) that a laptop is not always viable for many people; this tutorial appears targeted toward those people.
I’ve actually considered a neck/shoulder support for a laptop in the past but decided against it because it’d be cumbersome and make me a theft target.
As for AI, personally speaking I use AI coding tools to allow me to continue enjoying some hobby side projects with less free time available with a kid. It’s been a massive boost to my happiness in a generally low stakes area. I’m curious to see if I can get a similar unlock on my short and interrupted commute times as well, which is why I (personally) find this article interesting.
dont try to code while standing on a train. one of many antpatterns a wise engineer should learn to avoid, as part of polishing our craft. also: dont juggle chainsaws, etc ;-)
but also dont try coding on a laptop. use a proper desktop, or better yet, get time on a mainframe. the problem has been solved forever, juat do work from the workplace at a dedicated terminal, built for doing that work at.
Not coding on a laptop is actually good advice?! My argument would be that you shouldn't be doing any work without plugging your laptop into a full size keyboard and mouse at least. And, ideally, at least one external display of some form (I recommend 2 or 3, but it depends on exact setup/total resolution/etc.). But it's your body, not mine.
Regarding terminals, how often does this requirement occur in practice? Assuming it does, you can probably use your laptop for it, in which case, see above.
It’s a simple idea but one that hadn’t occurred to me yet.
I spend hours each week riding transit, and use Claude for a bunch of side projects and have Tailscale set up already, so looks like I’ll be giving this a try this week!
Doom coding might be doomed while I’m in the transbay tube though, with awful cell service…
How’s the diff review? I rely heavily on the vs code integration for nice side by side diffs, so losing that might be a problem unless there’s some way to launch the diffs into a separate diff viewer app on the phone.
I would guess a phone is way too small for side by side diffs, and a simple `git diff` would probably be more useful. If you want better syntax highlighting you could setup bat[0] as your difftool. If you insist on a side-by-side view (neo)vim has a diff mode with the -d flag. It is also possible to setup as the difftool that git uses.
Heh, many years ago I actually started writing a dedicated diff viewer app for Android [0] that specifically had synchronized horizontal scrolling between the two sides, and I remember finding it relatively usable in landscape, and I’m sure modern phones with larger and higher density screens would be even better.
But yeah, you definitely need a native experience to make side by side diffs viable on mobile.
[0] https://github.com/scottbez1/superdiff — I wish I had recorded some videos of the app back then. My code review workflow back then eventually stopped including diff attachments on code review emails, so I abandoned development on it.
Let me know how it goes! From the comments above, seems like you can use tmux to keep persistent sessions when you lose Internet connection - but I haven't tried myself.
Diff review is alright. I'm an amateur programmer. Sometimes I don't look at the code claude generates, but when I'm troubleshooting a bug, I'll ask claude to output all recent changes - which satisfies my untrained eye.
I don’t compile from my phone but I do write code using it. I use fossil for version control. The in browser editor is good enough to get ideas down. It has great diffs which is also nice. I will check in code and move it to a branch then revisit it when I’m home.
Similar for cooktops - I’ve seen IR-reflectance-based touch controls go haywire due to dimmable overhead lights, and heard of frustration with capacitive controls going haywire from liquid splatters.
There are some very real benefits to touch interfaces in cooking (primarily ease of cleaning a solid flat surface, and manufacturers don’t need to worry about moisture ingress), but it’s pretty hard to make one that actually consistently works in a way that won’t accidentally burn your house down when your cat walks across the cooktop in the middle of the night. I’m personally going to stick to knobs and buttons in the meantime.
> it’s pretty hard to make one that actually consistently works in a way that won’t accidentally burn your house down when your cat walks across the cooktop in the middle of the night.
Regardless of how the controls work, you can make a cooktop that, functionally, will not set your cat on fire: use an induction stove. Unless your cat ends up in a pan or your cat is ferromagnetic, the stove won’t heat it :)
It was also nice trying out some RTL-SDR apps as soon as I got it without having to figure out how to build and install the Debian packages from source first.
It drives me nuts every time I have to switch from Firefox to Chrome to use webusb or webserial.
reply