Coincidentally, when I moved to the UK, I had arranged for a taxi from the airport that never showed up. But Simon’s did, apparently. I sat there at a coffeeshop and stared at a taxi driver with a sign for Simon Oxley for a jetlagged hour or so while I waited for mine. I had hoped to catch him for a chat but apparently missed the connection.

More recently, we chatted about one of his designs that I adored and I had asked him about using it for an open source project that I had in mind. He graciously offered me to use it for noncommercial purposes. I got busy with, well, life, and didn’t pursue that. I’m feeling now like I should dust it off and see if it’s useful.

Godspeed, Simon.

At some point, I stopped trying to drag my pre-teen schoolmates along with me, but I still have my original hardback and re-read it regularly.

Your book taught me many things - perhaps most importantly, that one can educate about complex topics in engaging and understandable ways. And now I’ve landed in a job that focused on security.

One of the things that I’ve been doing in this job is, well, trying to educate about complex topics in engaging and understandable ways. I’ve thought about your book in every blog post I’ve written lately.

Thanks, again.

Comments URL: https://news.ycombinator.com/item?id=39590533

Points: 6

# Comments: 0

I'd love to jettison our hacky custom code and use something off-the-shelf instead.

More interesting than the food, though, is the background. Those who aren’t familiar with Cambridge will see King’s College in the background, across the street, which many may know from the BBC’s Carols from King’s.

To quote Wikipedia:

> In American English, "cottage" is one term for such holiday homes, although they may also be called a "cabin", "chalet", or even "camp".

In other words, calling a multi-million pound property a “cottage” would rankle an American ear.

But I suspect that you might be comparing Upstash's per-command pricing for _regional_ requests ($0.20 per 100k) to Vercel KV's? In fact, Vercel KV is multi-region, so the more apt comparison is Upstash's pricing for _global_ requests ($0.40 per 100k).

I tweeted a bunch of photos: https://twitter.com/ethomson/status/1109880552360951810

Basically, you set up your GitHub webhook URL as the proxy server (for example, smee.io). Then you run a client on your local machine that connects to the proxy server. When a webhook is fired, it will be sent to the proxy, then delivered to the connected client, which will then pass it along as a webhook to whatever machine you've configured.

There's disadvantages to having all this stuff running, of course, so I think that handling this at the networking layer instead of putting a proxy just for webhooks into place is an interesting strategy. Certainly, it sounds like the right solution if you're already using OpenZiti.

In the past, I've had good luck using a webhook proxy. I've mostly just used https://smee.io/ which is simple and lightweight although seems to be mostly abandonware at this point. I dockerized it so that it could be used in a Kubernetes cluster, which was very useful for my GitHub Actions build cluster: https://github.com/ethomson/smee-client

There's also Hookdeck, which I haven't used in production, but have played around with, and it seems conceptually the same, but can be made more Enterprisey. Whether that's a bug or a feature is probably up to you.

Comments URL: https://news.ycombinator.com/item?id=31284979

Points: 1

# Comments: 0

As for the cache, we doubled it at the end of last year to 10GB. https://github.blog/changelog/2021-11-23-github-actions-cach..., but I can see how multi-arch images would be very large. Have you considered putting images into GitHub Container Registry instead of putting the layers into the cache? I'd love to understand if that is appropriate for your workflow, and if not, what the limitation there is.

Appreciate the rest of the feedback, I'll pass it along to the appropriate teams.

We're always welcome to feedback, and we're continuing to invest and improve on the product, so I'm hopeful that we can address the features that you're missing.

This is impressive work. I've used the MSCCI API on several projects - MSCCI is the old version control interface for Visual Studio.

MSCCI is the "Microsoft Source Code Control Interface" and was built to integrate Microsoft Visual SourceSafe into Visual Studio. This was because VSS had a checkout/edit/checkin model by default, so files needed to be explicitly checked out from the server (and were locked) so that they could be modified. MSCCI allowed you to paper over this - as soon as you started typing in the editor, you'd get a MSCCI event and you could do the check out.

Unfortunately, the API is really focused on VSS integration. Trying to bring another version control system into this API is... painful. This was - always - the worst part of the UI to work on in SourceOffSite and Vault.

Thankfully, more modern versions of Visual Studio dropped MSCCI (by "more modern" I mean 2005 - adding Team Foundation Server integration to Visual Studio meant that MSCCI was finally deprecated and a new API was added).

However, legacy development projects exist for older Microsoft platforms and using older Visual Studio versions. So I'm both surprised to see that this exists, and am rather heartened by its existence. (But I still feel sorry for anybody who has to use it.)

    frood: noun
    
    (in dogs) a thickly furred section between the forelegs, covering the upper upper surface of the hind legs; a hindleg
    "a ferret with an astonishing, yet brief, frood"