Thank you for Caddy! Going from a complex nginx setup to the delight that's the Caddyfile was a breeze.

And a special call-out to your dedication to providing amazing documentation. Caddy is what all projects should aspire to be.

Caddy is amazing. I accidentally wiped my fairly complex nginx configuration (yay apt-get purge) and have been so spoiled by Guix that I did not care about etckeeper or ansible on my one Debian server.

Anyway I decided to try Caddy to quickly get up and running and had a good setup in minutes including certificates for multiple domains. Even added wildcard certificates which I never figured out with Lets Encrypt, just because I could.

Thanks for this amazing software :-)

That's awesome! Thank you for the experience/feedback.

Thank you! We try very hard (collectively, as a community).

Having a visual way to configure this makes it much more accessible to non-programmers, with error checking available through the host (Excel, in this case), while also reducing the eng effort in building this.

At Google, many internal tools use Sheets as their source of truth for config data, and it works really well.

> Having a visual way to configure this makes it much more accessible to non-programmers

I agree completely but thats not the point he appears to be making. He never stated this was the use case and he reiterated that it was a bad idea which should never be done.

Regardless, I’m saying those arent really unique advantages to excel. They just look unique compared to json, toml, yaml, etc.

I can't think of any data entry method more easily understood by non-programmers than an Excel spreadsheet (or Google Sheets etc). Repetitive data in particular is a breeze since you can drag-expand and use formulas. We use GSheets at work for configs created by non-programmers, and it works great.

What is your point? You can see from my previous comment I already agree excel is user friendly for non programmers.

The user-friendliness is a unique advantage of Excel.

It's actually refreshing to see end-user documentation and answering the basic questions of “what can this do” and “why should I care” in the readme. Most projects jump straight into how to build it locally, with not even a screenshot of what they’ve created.

Future generations are going to refer to today’s architectural style as the “HOA-approved” School or something equally silly.

I'm putting the finishing touches on the post-HOA-approved design movement.

The reaction to the over meetification of the manufactured world.

Our aesthetic terms are currently going through the final round of testing and we should have something to announce shortly.

Android as an OS does not support rollbacks. It can only upgrade apps in monotonically increasing `versionCode`s. The simple reason is that client side data may have been upgraded by a newer release to a format that is now incompatible with the old version. Sqlite databases follow the same policy.

This is well-known to anyone who has been doing Android development for a while.

Totally understand that a roll-back is more complex, but it doesn't explain why pulling back/pausing/deleting/yanking a release is not possible either - customers who got the newest faulty release can uninstall & install to get the previous version back (no need to worry about incompatibilities here) and the ones who did not get the updated version yet can stay using the old one until a new fixed version will be released.

This is exactly what staged rollouts are for. The author ignored that best practice. You can halt any release as long as it is in progress. Once you mark it complete (defined as rolled out to 100%), you can’t roll it back.

Each track in Google Play (alpha, beta, canary, prod) can hold up to one release at a time. It would get really confusing if it allowed more than one. And with the other rollout safeguards provided decelopers, it’s quite possible and very easy to do exactly what you’re asking for.

"may" is the reason why not supporting rollbacks at the OS level is baddesign

Thank you for creating this! I’ve been looking for an alternative to Jekyll locally, while also sticking to the Jekyll repo format to use with GitHub Pages. (Because the repo format is good enough, and trying to migrate to Hugo was a nightmare on each of the three attempts I made several months apart.)

Try using Jekyll via Docker. The whole stack is managed without mucking around the rest of the system, and trivial to update.