Ran into a situation last week that got me thinking about how most teams handle visual changes in production.

We pushed a CSS update that was supposed to fix button alignment on one page. Looked fine in staging. Looked fine in the PR preview. Got merged, deployed, and broke the card layout on three other pages because of a shared utility class.

Caught it about four hours later when a customer mentioned it in a support ticket. Not a great look.

What we tried

After that incident we talked about adding visual regression testing to CI. Looked at a few options:

• Percy — solid, but the pricing gets steep once you have more than a handful of pages and multiple PRs a day

• Playwright screenshots in CI — free, but you need to maintain baseline images and the diffs are noisy. Every font rendering difference across runners triggers a false positive

• Manual spot checks after deploy — what we were doing. Obviously not sufficient

We ended up going with Playwright screenshot comparisons but with a pretty generous diff threshold (0.3%) to cut down on false positives. It catches big layout shifts but ignores sub-pixel rendering differences. Good enough for now, but not ideal.

The production monitoring gap

CI-based visual testing only covers what happens before deploy. It doesn't catch things that break after — CDN caching serving old assets, third-party scripts injecting unexpected elements, A/B test variants rendering wrong.

Some teams run synthetic monitoring that takes periodic screenshots of production pages and compares them. That covers the post-deploy gap but it's a separate system to set up and maintain.

Curious what others do

How are you handling visual verification in production? Specifically:

• Do you run any visual checks post-deploy, or only in CI?

• If you use screenshot comparison, how do you deal with dynamic content (dates, user-specific data, ads)?

• Anyone running continuous visual monitoring on production pages on a schedule?

Feels like there should be a simpler answer than "maintain 200 baseline images and pray the CI runner has the same font rendering as last time."

Would be a terrible shame if lots of people opted out.

If you are a EU citizen you might also want to write a complaint to privacy@huggingface.co because they are collecting your personally identifiable information in machine-readable form which they are distributing to third parties.

I've been meaning to make new dev projects for a while. But finding the time to sit down to just code is difficult for me these days. However I wanted to make a watch face for my new watch and I just said screw it.

Through a mix of using the Pebble SDK documentation, and referencing a few AI chatbots, mainly GPT-OSS I'm running in Alpaca, I was able to make it, make it run, and since it's in C, I was able to have no memory leaks (according to the logs).

I've uploaded the source code to Codeberg if you want to look at it, I've yet do document it, so hopefully it's not too hard to understand and not a spaghetti mess.

https://codeberg.org/the16bitgamer/poketech-dx

** Notes on my experience using AI to aid in coding **

When I was taught to coding, Google-fu was the goto way if/when the documentation fails you. However with both how old, and incomplete the Pebble SDK docs are, Google-fu wasn't helping since the info it would pull was about a decade or older and mostly out of date or hard to decipher information on Stack Overflow. I would almost say using an AI along with the actual documentation and tutorials was a necessity for me to even finish this project.

The AI wasn't perfect, endlessly gas lighting me, telling me to do over the top things for functions I already implemented, and putting me down rabbit holes going no-where. But compared to what I could get from Google, and it's ability to try and break down what the code is doing, it was a lot more helpful than I thought it would be.

In Brief:

• Two motions regarding "artificial intelligence" and Large Language Models (LLMs) were voted on among Codeberg e. V. members and passed.
• We are promising to not use any of your data to train LLM and explain what the planned Terms of Use change mean for 'vibe-coded' projects.
• We believe that LLMs endanger the free/libre software ecosystem as a whole.

The blog/news post then goes extensively into where Codeberg understands itself to be in the development landscape, and their voting results. They present their interpretation of the current software development and hardware landscape under the influence of LLMs, and the consequences they take. And how it changes not only development in general, but FOSS collaboration and projects specifically.

To us, it seems ridiculous to see projects with a single developer and virtually no users consuming as much or even more resources than some of the largest community projects on Codeberg, which operate frugal with CI/CD and storage resources. We do not believe it is reasonable for Codeberg to invest our precious donation money into hosting of large ghost projects.

Now that there's way more trash out there it feels irresponsible not to check for client side security

cross-posted from: https://programming.dev/post/54023908

Hi!

I've never read any of Uncle Bob's books. But I have taken interest in "Clean Architecture" as it seems like a good solution to make mid to large sized projects simple to understand and maintain.

I think MVC gets too much coupling and fails at larger projects, same with n-tier. But I'm not sure about anything right now (software design is a very complicated problem after all).

So I was wondering if you friends who have used Clean Architecture in production can share your knowledge and experience with me about this design?

Is it actually good and worth investing in?

Footnote:

I'm especially weighing this architecture because Uncle Bob's writings are really hit and miss. I don't see him as a master or guru so I take everything he says with a grain of salt.

DSCI is simple yet super flexible pipeline engine to write CI code on regular programming languages, integrates with Forgejo using web hooks. Intended for small teams hosting Forgejo on single VM VPS and willing to create pipelines on regular programming languages