beingflo

Don't know where you got those numbers from. Check old prices here: https://web.archive.org/web/20260907112235/https://api-docs.....

Input tokens are around half the cost, output only slightly cheaper.

We probably have max 50 commits a day in our team spread across many areas in the application. So when breakages occur it's typically easy to tell which commit caused it.

But I agree, if you have a large team or a large monorepo you probably want to know about breaking changes already at the PR stage.

Thanks for the example of a Playwright report page. I agree that getting browser tests (not even just visual tests) to work reliably is considerable work. I built out a suite at work for a rather complex web application and it certainly looks easier than it is. A couple of notes:

- I disagree that you need a powerful VPS to run these tests, we run our suite once a day at midnight instead of on every commit. You still get most of the benefit for much cheaper this way.

- We used BrowserStack initially but stopped due to flakiness. The key to getting a stable suite was to run tests against a local nginx image serving the web app and wiremock serving the API. This way you have short, predictable latency and can really isolate what you're trying to test.

Ah forgot to mention it in the post. This comes built in by Playwright. Normally, you invoke the test suite by running `npx playwright test`. This fails your test if a screenshot is missing or if it differs. By running `npx playwright test --update-snapshots` you tell Playwright to just overwrite the snapshots and not fail tests.

I only use the built-in diffing by Playwright. It comes with a nice overview page [0] that shows all the failed tests including traces and screenshots. There you have a pixel diff. If you have some notion of irrelevant changes that shouldn't warrant a test failure, I wouldn't know of a way to pull that off.

[0] https://playwright.dev/docs/trace-viewer-intro#opening-the-h...

Direct link for anyone interested: https://go.rest.quest/

updown.io also has a relatively new feature called cron monitoring[0] that allows you to regularly check in to signal success. If there has been no check-in in a configured time it will alert you. For backups you could add a simple curl somewhere into your backup process to do just that.

[0] https://updown.io/doc/how-pulse-cron-monitoring-works

I know, but I prefer fair pricing over free in situations like this. There are plenty of stories going around of CF forcing users to upgrade to an enterprise plan due to their usage. When there is a price tag, at least I know that won't happen to me (not that my usage would be on CFs radar anyway, it's the principle of it).

1€ / TB egress is extremely attractive, though. Most other "budget" providers charge at least 10 - 20$.

I've been eyeing DuckDB for a metric collection hobby project. Quick benchmark showed promising query performance over SQLite (unsurprising considering DuckDB is column oriented), but quite a bit slower for inserts. Does anyone have experience using it as an "online" backend DB as opposed to a data analytics engine for interactive use? From what I gather they are trying to position themselves more in the latter use case.

I built it for myself primarily, some coworkers also started using it. No one has used it without my guidance at this point so I'm not surprised ;)

Regardless what you pressed, you should always get back to the help / start screen by pressing 'h'. (Make sure not to have focus on an input field)

I built my own tool: https://go.rest.quest

It's a simple flat list of links that you annotate with a description for better search. The killer feature is that it works with Firefox's keyword search. I can enter `go gith prof` in the url bar and hit enter. Since there is only one entry that matches (with description 'github profile'), I'm immediately redirect to that link.

I really enjoy using Observable Plot (https://observablehq.com/plot/). Made by the author of D3 but way simpler to use.

I think you have to be careful not to stretch your learning budget too thin. Coincidentally, I recently started tinkering with embedded as well and decided against using Rust (not new to me) for it because I prefer the well trodden path when first getting started in something. There is plenty of opportunity to venture out later.

I've only started load testing my applications until after I switched to Caddy, so I don't have a comparison. But I'm easily seeing ~7'000 r/s when serving a static frontend (don't have reverse proxy numbers on hand) on a small hetzner machine. That's without looking into what the bottleneck is. Against localhost I've seen ~50'000 r/s. Good enough for me.

Caddy [0] has been an absolute joy to work with. I switched this year from nginx for my sideproject-hosting VPS. Just letting it handle the SSL certs and configuring a static site or a reverse proxied route in literally 3 lines of config is really nice.

I'm planning on adding Authelia [1], Prometheus and Grafana Loki to the mix soon, which should all integrate nicely :)

[0] https://caddyserver.com/ [1] https://www.authelia.com/

In a moment of weakness I bought a soldering iron and this kyria kit [0] and soldered my own. I promise it sounds more crazy than it is and I've been very happy with it.

[0]: https://splitkb.com/collections/keyboard-kits/products/kyria...

Is my understanding correct that Affinity Photo doesn't have any photo management capability? If you want to edit a series of images similarly, do you create a custom preset that you then apply to the other images and just reopen the editor for every image?

I have recently been looking to try some creative coding / generative art. I've found that most libraries focus on interactive or animated applications, whereas I would like to generate a static image for print. Are there any recommendations for this specific use case? E.g. maybe svg-based libraries like Paper.js are more appropriate to generate high quality files instead of canvas-based ones like P5.js?

Full agree. And further I think frontend complexity has grown quite a bit lately. People love to go on about framework churn etc. when it's just a difficult domain in general. As someone who used to have snobbish opinions on frontend work, I've completely come around since diving into it. For modern fullstack applications I believe the frontend often has more complexity to it than the backend.

Hi HN,

I challenged myself to get a small webapp built and launched in 16 hours of work from start to finish. This is the result: A tiny, very opinionated todo list application. The feature set is tiny, but it lends itself to keep track of stuff to do for the day, things to get back to etc.

Since it keeps its state in local storage, you can just visit the website and start using it without any signup.

To keep the state synchronized between work and home, I built a very simple S3 integration. This keeps the state between devices in sync via the S3 bucket.

You can find the code on github: https://github.com/beingflo/rest.quest

Apparently the sdk doesn't play nice with vite. And it's way to heavy for my use case anyway. After looking further I found this library that is perfect for my needs https://github.com/mhart/aws4fetch.

It's only intended for techies (and friends thereof I suppose). It's really a tiny project that I've set out to finish in 16 hours as a challenge. So far the progress is great but those S3 libraries are throwing a wrench in my schedule. Because of that tight time budget I think oauth would be out of scope as I've never done anything like it.

Getting into this I was under the impression that uploading a file to S3 was as simple as chucking the api key into the Autorization header of a post and off we go. That's the type of ease of use I'm looking for. Turns out its not quite as trivial with a whole signature process etc.