It does pretty well, but you need to iterate. I was trying to get it to disallow internet access for non-DHCP clients, and in the end there were so many limits to what was possible that it wasn't worth it. But it did it, and when I was testing I found them.

So like everything for best results you need to know what you're doing so you can test effectively...but it saves you from learning the syntax etc.

The repeating patterns on carpet are an artifact of mass production.

Be nice to them and they'll be nice to you back.

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.

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?

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?"

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.

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.

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.

Since the pool identifiers are static, how do you actually fail over?

Oh, you need a custom domain that presumably routes if the primary dies.

I have to look a bit, but it could probably replace Cassandra now as well.

"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?

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.

Who's buying? It could be their customers were boomers, who are dying. What are they doing to bring in new customers?

The answer: nothing.

The book industry is surprisingly bad at marketing, given how big it is/was.

In golf, strength is overrated until you get to the pros.