You can use their CLI and registry for free. I agree that their paid offerings are crazy expensive, but it's simple to just commit your protos in your monorepo (or a proto repo), install buf, create buf.gen.yaml with a few language plugins, and you're up and running. All the pain of protoc is handled. It's been a massive improvement in usability since they came along.
> The government mandates that cars get safer every year and fatalities are down 78% from the 1960s. Whenever government regulates things to benefit people, people tend to benefit.
On some metrics. On affordability, new cars are considerably more expensive. Whether that's a worthwhile tradeoff is beside the point. The GP's point is that there's no free lunch, and your example doesn't address that.
Funny, I just bought one of these last week. Agree with the article. Mine came with storage and Debian preinstalled. If you buy one from Amazon, keep an eye on price. I bought, then the next day the price dropped $150. Ordered another one and returned the expensive order.
Those sort of flaky or non-deterministic steps are written as activities, not as part of the deterministic workflow. The orchestrator will retry the non-deterministic activity until it gets a usable output (expected error, success), and record the activity output. If the workflow replays (i.e. worker crash), that recorded output of the activity will be returned instead of executing the activity again.
Brave has a subscription tier that offers storage rights. But it's ~9x the cost of their normal Pro subscription. I have a hard time imagining that the cost works out in their favor (discounting the possibility of a special arrangement) with how long the query stream tail is in web search.
Try a short story collection. Ten page chunks are easy to consume and you get to tell yourself you’re reading literature. It’s a good way to get back into reading on paper if you’ve been away and want to start small.
Because if you send marketing emails through SMTP, your delivery rate will be approximately 0.00%, or if you're leveraging a third party SMTP, they will ban you.
Sounds to me like what you meant to say is that your criteria for determining whether someone's profession is "serious" is whether they use metric or not.
Is there a list anywhere of trustworthy sites for product reviews? The article mentioned Tech Gear Lab, and though I haven't heard of House Fresh, that seems reasonable? Consumer Reports of course, but are there others?
On the other hand, vanilla PHP effectively "hides" HTTP from the programmer. I taught myself PHP in middle school and high school as my first programming experience, and had no concept of a thing called "HTTP" for a very very long time. I knew the pieces of it that PHP gave me. I knew what $_POST, $_GET, $_SERVER, $_HEADER, set/getcookie(), were and how to manipulate them, and I knew the rules (setting a header after "echo" made it complain), but I didn't understand how that all hung together as a thing outside PHP called HTTP.
When I did learn about HTTP, it was very easy, since I already knew it without knowing I knew it, so maybe that's in favor of your point, but there's much to be said for the actual understanding that I didn't have at first. When I started interviewing people for PHP entry-level jobs, asking about HTTP was one of the ways I gauged how well applicants understood their work at a conceptual level.
Shown in the article but not called out specifically, I recommend avoiding implicit tables entirely when using clickhouse materialized views. We use clickhouse for similar purposes, and there are several cases where views are listening to tables populated by another view. So [table] "events" -> [view] "mv_events_to_view1" -> [table] "view1" -> [view] "mv_view1_to_view2" -> [table] "view2". If you use implicit tables, the 2nd view will never receive data.
The differences are a) you don't lose notable range in cold weather (and your car continues to reliably tell you your remaining range), and b) there's always another gas station a block down.