kailanb

Unrelated to the content: I was really pleased to see that this site defaults to the bare minimum for cookie consent. I reflexively clicked "Reject all" only to see that it was already the default, which threw me off.

Surely you've noticed that the vast majority of engineers are using LLM-powered tooling such as Claude Code to assist their development process nowadays.

Adding a Markdown file to the default project structure that will significantly improve the experience for this majority of developers seems like an obvious win, and doesn't make me feel like anyone is trying to "force LLM crap" on me.

I understand your reluctance to engage with this stuff (I held a similar position for a while) but your comment here reads as "old man yells at cloud".

They launched this with one of the most memorable TV adverts of all time, in my opinion: https://www.youtube.com/watch?v=YYEcZh2QtwA

Transport for London does the same. If you add your (real, CPAN) card number to the "Contactless and Oyster" web service, it will also add all of the DPANs you have tapped in with on their network as separate cards.

It’s called out later in the article.

it's back!

worth noting that anyone can remix the project :) https://glitch.com/edit/#!/wobble-clock

The team over at Swift Cloud are making it run on the edge.

https://swift.cloud/

I recently discovered PocketSmith[0] which is not free nor open-source, but I have found it to be the easiest to keep up to date. It automatically pulls transactions from most banks and credit providers, which I've been unable to replicate with other solutions.

[0]: https://www.pocketsmith.com/

A nice write-up, however it looks to me that the Compute@Edge tests were being run on a free tier service (adding a credit card to Fastly account does not upgrade your service automatically, I know because I work at Fastly).

I'd love to see results from the same tests run on the full version of the platform.

Mozilla are not the only ones doing this [0][1].

[0]: https://www.wigle.net/ [1]: https://support.google.com/maps/answer/1725632?hl=en-GB

Forgive me if I'm misunderstanding, but this looks like an end-user authentication system that you would implement in your own app rather than a corporate directory like Okta. Different use cases.

Sorry, I was trying to clarify in my comment but failed to put it through clearly. When I say "We ran our own benchmark" I mean Fastly ran a benchmark on a Fastly Compute@Edge service.

does the language that you use matter when the real goal is to serve a webpage to the end user in the shortest time possible?

To clarify, Fastly did not perform any benchmarks on Cloudflare's network. We ran our own benchmark, comparable to the one that Cloudflare ran on our platform, and compared those results to the ones that Cloudflare published as part of the original blog post.

The Cloudflare terms prohibit benchmarking without their explicit permission.

Vicious attack? Or defending your place in the market?

It definitely comes down to the language — JavaScript is an interpreted language, which requires an engine. Rust is statically compiled and runs by itself.

For context see https://news.ycombinator.com/item?id=29288393

An unfortunate comparison at the start there, considering that the "native" and recommended language for performance on Fastly Compute@Edge is Rust. JavaScript support is in beta.

Try the experiment again with a Rust service compiled to WebAssembly and I'm sure the results will speak for themselves.

I am a big fan of Fig. Some of my favourite specs are `docker` and `git`. No longer do I need to list containers or commits before performing an action, the autocomplete provides all of these values for me.

I'm excited to see more command-line tools provide metadata about commands close to the source code. Our CLI at Fastly provides JSON output in the help command, so it was really easy to generate a Fig spec automatically: https://github.com/kailan/figly

Source code: https://github.com/justinliew/DOOM

Demo: https://developer.fastly.com/solutions/demos/doom/

The domains are likely in the whitelist as their report-uri was getting spammed with reports from users that have adware/malware extensions in their browser.

These extensions inject their own scripts into the page which will then fail based on the CSP and send a report to the server. In an ideal world you would just 'ignore' these reports server-side instead of whitelisting the domains.