/usr/bin/env executes commands with flags/subcommands, not just bare executables. Which is great if you, for example, have a script/lint that’s a Python script, and it needs dependencies from a virtualenv that isn’t active when you call it.
Just put your shebang as /usr/bin/env uv run python3 and it always runs in the virtualenv, no wrapper script needed. This feels obvious in hindsight, it’s what you expect from these tools 😃
…and musing on genies possibly teaching empathy
Anthropic has released some recordings from their Code w/ Claude event in May and the Prompting for Agents presentation’s “key principles” are basically to empathise with your agent, imagine it’s a brilliant new grad, book smart but missing all things practical at their first job: You need clear concepts, unambiguous instructions, and well-named and designed tools.
I’m more than a little amused that we’re basically coming to a point where, if things pan out with the genies, then the best wranglers will be the ones that can empathise the most with others. Then again, I always thought the brilliant asshole was the exception, they only survive if they’re in charge or are legacy to the company. And sitting in on the review meetings at work… it’s definitely the ones that help the team that we like the most, even if we sometimes need to push them to have their name on something so people don’t overlook them.
[… more]Simon Sinek on AI and the value of struggle, via Arjit:
People keep telling us life is not about the destination. Life is about the journey. But when we think about AI, we only think about the destination. And it’s remarkable ability to write the book, paint the painting, solve the problem, but we forget the importance of doing the work yourself.
And I think in our modern day and age, we have underrepresented the value of struggle. I am smarter, better at problem solving, more resourceful, not because a book exists with my ideas in it, but because I wrote it. That excruciating journey is what made me grow.
But it’s the same for love, friendships, conflict. And I think that we forget that we give up certain skills or abilities because of technology.
The struggle is the point. More people can generate a mediocre painting or write perfect English now, but they won’t understand the beauty behind either without doing the work. And it’s our prerogative to decide which struggles matter to us or if we just wanted something nice to hang in the toilet.
Went looking for that old ‘kids today don’t memorize’ quote and found an old argument against writing:
[…] They will cease to exercise memory because they rely on that which is written, calling things to remembrance no longer from within themselves, but by means of external marks. […]
One thing we’re not doing as effectively today as we’ve done in the past is to learn lessons by heart. If you don’t know things with perfect recall, how can you expect to apply them?
Socrates goes on to compare a written text to a painting:
You know, Phaedrus, that is the strange thing about writing, which makes it truly correspond to painting. The painter’s products stand before us as though they were alive. But if you question them, they maintain a most majestic silence. It is the same with written words. They seem to talk to you as though they were intelligent, but if you ask them anything about what they say from a desire to be instructed they go on telling just the same thing forever.
That last bit especially, “if you ask them anything… they go on telling just the same thing forever.” This all sounds exactly like how we’re talking about genies today, and… we’re probably going to be fine.
learning to handle expertise you didn't earn
We’ve always had to figure out who to trust for expertise, but until now, that access wasn’t universal. Used to be the bloke at the pub who ‘knew things,’ or that friend of a friend who could fix computers (me as a kid), or books if you had the patience. Rich people had their ‘real’ experts on call, though Bernie Madoff shows how well that could work out.
The internet changed things, sure. Suddenly you could reach out to actual experts, find communities, and learn from people across the world. But you still needed judgment, because you could also find a community that agreed the earth was flat, so, you know, mixed bag.
What hasn’t changed is we’ve always had to figure out who to trust. What’s changing is how we get our answers, and who gets to sound like an expert.
[… more]Drone CI has special handling for ${VAR} and will replace it itself instead of letting the shell do it. So if you have export PATH=${GOPATH}/bin:$PATH and have $GOPATH defined in your global environment key, then it’ll become a blank value. But if you do export PATH=$GOPATH/bin:$PATH it’ll work. You can escape by adding an extra dollar sign, i.e. $${VAR} will be evaluated by the shell.
This is different from normal shell where ${VAR} is the same as $VAR and it exists to make sure you can concatenate strings without issues, i.e.
VAR=m000
echo "'${VAR}est'" # => 'm000est'
echo "'$VARest'" # => ''Drone CI will not smartly skip subsequent steps if you have a when on the very first step in a depends_on chain, so you have to repeat the when condition for each step because it doesn’t realize that the first dependency is gone.
Drone CI’s when for deciding in which cases to run steps/pipelines targets the merge target branch for PRs and not the actual PR’s, also it pulls from refs/pull/<num>/head instead of refs/heads/<branch> so you can’t target the branch itself using the pull_request event (use push on the pipeline and then branch for the step instead).
In shell scripts if you do "$@" it will actually expand “quoted sentences” correctly, and if you just do $@ it will always unwrap them into single words, I thought that if you did "$@" it would combine all arguments into a single argument, and what it does is do what I thought $@ alone did.
I.e., with "$@" the arguments "one two" three will be 2 arguments, the first being "one two", and without it will become three arguments, all separated by space.
The <link rel="canonical" href="…"> is a bit like a correlation ID between services and I need also to have it on my canonical page, because if someone sends it with ?utm_source=foo it could be a different page than the one without the query string.
Python doesn’t require typing.Dict and typing.List for those types since Python 3.9, you can just do dict[] and list[].
The scripts/commands inside a shell script inherit access to STDIN when you call them, so if you have a shells script that only has cat and you do ./script.sh < script.sh then it’ll output the content of itself
You can view the webhooks that GitHub sends in your project settings, so for example Drone CI getting notified and exactly what information that goes into the payload, and when/if it was sent, is available there.
Go to Settings -> Webhooks and then click on the integration you want to look at.
You can enable the fingerprint reader for sudo on macOS, and pressing my finger on a button beats having to type the password, steps:
cp /etc/pam.d/sudo_local{.template,}/etc/pam.d/sudo_local and uncomment auth sufficient pam_tid.so.The reason for doing this in sudo_local is that this file will not get reset with system changes from Apple.
I’m trying something new here. Instead of waiting for fully-formed thoughts, I’m going to share more as I go: quick things I’ve learned, half-baked ideas, useful links. I’ve added some structure to keep things findable, but the main goal is just to share more often.
The main feed will give you everything I post, if you only want certain types of posts, I’ve also made section-specific feeds. The blog feed is what you’ve been getting if you were already subscribed.
[… more]learning to ride the AI motorcycle without crashing
A colleague recently said something that’s been rattling around in my head: “AI gives you speed, but it doesn’t give you direction.” And the more I use these tools, the more I think that undersells the danger.
I have been wondering how to think about AIs (or genies) and how computers are like bicycles for the mind, as Steve Jobs put it, and I think these tools take it further. They are more like motorcycles for the mind. They go really fast, and you better not treat them like a bike, because you need to know what you’re doing. How to handle that thing. You need to make sure you don’t try to go too fast too soon, or for too long, because you’ll get speed blind and… things will happen.
[… more]...you wouldn't wear a beanie to the beach
I was in an incident review recently where one of the problems was a human going too fast. This process is very manual, repetitive, and boring, and it rarely fails, so we skip some steps. That mostly works (see Why Do Things Go right?), except when it doesn’t. Ripe for occasional issues and likely in need of automation.
I believe we often skip steps because we don’t know why we do them. It’s not tedious for tediousness sake, it’s often there because it’s important. And until we have the automation, or maybe we’ve intentionally chosen not to automate it, we need to find some way of helping the human ’live the situation.'
[… more]be fast by avoiding work, while doing the important work
I was trying to speed up our slow CI by caching Go builds. The easy win was caching Go’s module downloads (via GOPATH), but when I added GOCACHE for the build cache, I got a pleasant surprise: the tests were caching too. 🥳
I shared the change for review, and a colleague raised a great point: “What about our black box integration tests?” These tests hit APIs and external services that Go can’t track as dependencies. If they cache when they shouldn’t, we might miss real failures: the tests would pass because they didn’t re-run, not because the code actually works.
[… more]From meeting minutes to project milestones
You’ve probably sat through your fair share of meetings where time slips away as conversations wander aimlessly, not unlike being dropped into an unfamiliar codebase, with twisting branches all alike.
A colleague asked for feedback on a meeting they ran, and after sharing my thoughts, I realized my advice about meetings sounded exactly like how I talk about planning projects. This got me thinking: the skills for running good meetings and successful projects are nearly identical.
[… more]reducing TOIL outside of your DevOps practice
I try to be aware of where I have friction in my day-to-day when working at my computer, keeping an eye out for TOIL to remove. Whether it’s from manually repeated actions, or from differing behaviors across apps and services I use. When I identify any of these I try to spend some small amount of time automating or changing how I work to improve.
All of these things don’t necessarily make a lot of sense from how much time I save, but, it also makes me happy to spend a bit of time improving my environment, and spending a bit of time to make me happy is good enough for me.
[… more]