FYI token speed is somewhat irrelevant for agentic development. You let it run, then you come back. The whole point is that it's asynchronous. If it takes 4 hours, 8 hours, 16 hours...who cares?
Using Pgsql for everything shows you've been drinking the internet kool-aid. And that site is like a creepy shrine saying pgsql is the alpha and omega.
Like any tool, it works until it doesn't. And when it doesn't it takes a herculean effort to unwind it.
I looked at the first entry and yeah, just say no to moving your business logic into your database. Because change happens...and don't you want that happening in something more plastic than your RDBMS? But it's a great way to bind your solution to Postgres forever.
As an aside, I've used oracle, sybase, informix, mysql, postgresql, rdb, db2, mssql, and a few more that I can't remember. And the idea that pgsql is always the answer is the wrong answer to probably the wrong question.
Certificate expiry is less severe than an untrusted issuer or a host mismatch.
The former is most likely an administrative error (ie: someone forgot to renew, or the auto-renew is failing). The latter is more likely to be an MTM attack.
I'm not sure how you would use an expired cert as an attack vector. By loading in an old cert into an expired domain so you could spoof older content?
"nobody should be renewing their certificate within 90 minutes of expiration"
You obviously haven't worked with hardware guys.
"I mean, what's the point of those last 30 days if you need to renew it 30 days before expiration? Why not just renew it before it expires? If I'm required to renew it 30 days before the expiration date then the expiration date is a lie, isn't it?"
Anything that might fix brain plumbing would be welcome.
Over time, everything breaks down. If this actually fixes some plumbing issue that would be great. Of course, it probably will lead to another downstream plumbing issue, but one thing at a time.
"Epubcheck does basic CSS checking of course, but it can’t validate CSS against a renderer which is fundamentally broken!"
According to the author, Kobo uses CSS from 2013. A quick check with an AI says RMSDK supports CSS 2.1 and parts of 3.
So it's not that the renderer is broken, it's that he believed that epubcheck actually checks against devices and the versions of CSS that those devices support.
This is exactly the issue with test tools: the test tool tests to a spec, but the platform is the gold standard. If you don't like it tough shit.
Power on after a power failure has been a Mac feature for decades. Did it stop working at some point?
Of course, it didn't work if you set your Mac to shut down if the UPS is running out of power, which was always quite annoying. You want a clean shutdown, but you also want it to come back up. I think I got around this by using shutdown hook scripts to unmount everything then just stop.
The article buries something interesting at the bottom:
"Herd size is down, but U.S. beef production is steady"
So the author talks about all this stuff, but probably the three big cost drivers are:
1. Input costs are higher
2. Possible price fixing by meatpackers
3. Lack of Mexican imports due to screwworm. Although it sounds like Mexican imports would increase the herd size, not the amount of beef on the market.
Not sure why people haven't been importing more beef. The article mentions tariff cuts for Argentina, but there are other places that export beef. Possibly the market is tight all over the world?
You don't really need clickhouse in this pipeline. And it's interesting (but obvious once said) that you can replace kafka with s3...at least in the "scalable and reliable destination for lots of data" dimension.
The only thing I can think of is to ask the AI "why this instead of that?"
Every architectural decision is a tradeoff between something and another. Every technology choice is also a tradeoff. If you understand the reasons for the choices you'll start understanding architecture.
Sometimes it starts with requirements (ie: what you're trying to do), or what your deployment environment looks like, your hosting provider, or even what technology static you'd rather use.
For example, I'd never use Java for a project ever again; it's unclear what it really brings to the table, and it's more difficult to deploy on AWS. And if I was going to use Java I wouldn't pick Spring or any other dependency injection framework because they inevitably lead to impossible-to-debug performance issues. I wouldn't use an ORM for the same reason. No Ruby as well, due to issues with migrations and active record. No postgres unless there was a specific feature of it that works better than other, due to RDBMS management overhead and inconsistencies.
Of course, now that I write this my next project is going to be some random Java/Spring/pgsql thing with a Ruby engine attached (aargh).
What helps actually is reading the "why you should use this tool" parts of each tool. You can start building a mental model/checklist of the good/bad things of each one and why would you use one instead of the other. There's almost always more than one tool available, and the way you deploy/scale/manage/backup each one will tell you a lot about when you would (or wouldn't) use it.
In general don't worry about scale until you're at the point you can test for scalability. I mean, some architectures are better than others, but all of them will be performant at 10 users. Even flat files, a bash web server, and bash-based CGIs can handle 10 users.
Be nice to them and they'll be nice to you back.