The other week I was the MC for day 2 of CSS Day conference. It was my first time ever being an MC for a conference! I was so excited and, honestly, very nervous at the start. My hands were shaking a lot, and it's no wonder, as Bruce Lawson had been the MC of the previous day, and that's a tough act to follow. And if I can’t be funny on the spot, I will try to make up for it in other ways.

I ended the day with the following:

Throughout the day, when introducing our wonderful speakers, I've highlighted their work outside their jobs: their passion, their blogs, their writing and their voice. As an IndieWeb person, I can't stress enough how having your personal website, blogs and sharing what you've learned changes your life. But, like Kevin said on his blog post I mentioned earlier, it's getting harder for folks to keep their motivation. Your LLM of choice only outputs things because of the sweat and dedication that people in this room have put in. And yet, I still want to encourage folks not to give up.

In the last two days, we saw amazing and creative talks that are the perfect reminder to let the computer do what the computer is good at. But the things you saw that got your heart racing and pumped with excitement were human-made and human thought. So, when you have a minute in the next couple of days, say thank you to the invaluable people in our community, or even better: go build something and share it far and wide."

Brecht De Ruyte has written a lovely, detailed write-up of the day if you want more technical insight into the talks from the two days.

See you next year... very likely as an attendee!

What happens next? Well, you tell me.

When adding an email link to a document you should use the mailto: URI scheme: Email Chris That makes the browser open the associated email tool instead of opening the link in the browser. Today I found out that browsers also offer a “copy email” in the context menu that only copies the email itself […]

There's something inherently entertaining about creating real-life things out of digital stuff. Alice did this recently by turning her weekly notes into a printed and bound book, back in the day Ben took a bunch of tweets and turned them into a newspaper, and I took an online friendship group and turned it into an IRL conference LARP.

I've spent a lot of time lately digging through my own digital photographs - I was on the lookout for photos with interesting glitches or degredations - and I ended up getting sucked in to the sheer amount of photos I have of things that aren't actually worth keeping. They were blurry, had my thumb in them, were literally of just nothing (maybe the inside of a pocket?), pictures of product codes to remember for 1 minute while it was typed into an input box somewhere, or a reference to an item to track down in the IKEA warehouse. They're not good and they're not useful, and they're not pictures of things I care about. And yet, I didn't want to delete them, which I thought was a curious feeling to have about pictures of nothing.

I gathered a bunch of them up in an album and ordered physical prints and put them in a tradtional photo album, just like the ones we have at my parents' house in Cornwall, full of family past and present that I only see on special occasions and don't exist digitally.

I like it? A friend commented that each one is a bit like looking at a mystery puzzle, with a time, place and motive to solve: how did this photo come to exist.

As shared by on Simon Willison’s blog, Zig has an interesting anti-LLM policy for contributions in their code of conduct.

Zig values contributors over their contributions. Each contributor represents an investment by the Zig core team - the primary goal of reviewing and accepting PRs isn’t to land new code, it’s to help grow new contributors who can become trusted and prolific over time.

I don’t think an anti-LLM policy makes sense for most projects. But a programming language requires considerate intent and deep knowledge for changes. It’s an interesting fit there.

In addition:

If a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?

We’ve historically preferred PR contributions over issues, because it puts the contributor in the position to do most of the work. But if a PR is just a contributor prompting an LLM, is a well-written issue preferable? When writing code becomes cheaper, might as well let the maintainer get it done using their taste.