This person's personal website is glorious. We need more sites with crazy animations and autoplay music.
608 karma · joined April 19, 2024
Broadly I agree with Nolan, though. Web components have enough rough edges that they're not going to take over the world in the current state. But, they are pretty nice for certain use cases.
I'm not sure what he means by not playing well with server side rendering though. I've been doing that without issues.
For some of the operations, the method I was using required marshaling the inputs to JSON before sending them over the wire. And that's nicer in a non SQL programming language. But both db's ultimately do have json_build_array/json_build_object for PostgreSQL or json_array/json_object for SQLite3.
The most useful part is doing set intersection operations on JSON array's. Probably the second is extracting a value by path across both.
It's not crazy to implement, SQLite was the harder side. Just a bit of fiddling with `json_each`, EXISTS, and aggregate functions.
I hope SQLite3 can implement SQL/JSON soon too. I have a library of compatability functions to generate the appropriate JSON operations depending on if it's SQLite3 or PostgreSQL. And it'd be nice to reduce the number of incompatibilities over time.
But, there's a ton of stuff in the release notes that jumped out at me too:
"COPY .. ON_ERROR" ignore is going to be nice for loading data anywhere that you don't care if you get all of it. Like a dev environment or for just exploring something. [1]
Improvements to CTE plans are always welcome. [2]
"transaction_timeout" is an amazing addition to the existing "statement_timeout" as someone who has to keep an eye on less experienced people running SQL for analytics / intelligence. [3]
There's a function to get the timestamp out of a UUID easily now, too: uuid_extract_timestamp(). This previously required a user defined function. So it's another streamlining thing that's nice. [4]
I'll use the new "--exclude-extension" option for pg_dump, too. I just got bitten by that when moving a database. [5]
"Allow unaccent character translation rules to contain whitespace and quotes". Wow. I needed this! [6]
[1] https://www.postgresql.org/docs/17/release-17.html#RELEASE-1...
[2] https://www.postgresql.org/docs/17/release-17.html#RELEASE-1...
[3] https://www.postgresql.org/docs/17/release-17.html#RELEASE-1...
[4] https://www.postgresql.org/docs/17/release-17.html#RELEASE-1...
[5] https://www.postgresql.org/docs/17/release-17.html#RELEASE-1...
[6] https://www.postgresql.org/docs/17/release-17.html#RELEASE-1...
This applies to business analysts, scrum/agile people, communications people, and other non-technical project staff, too.
I've observed an arms race at play in my department. Our team used to be 4-to-1 developers to business people. But we've increasingly needed to hire more business people just to defend ourselves against political scheming.
College students in Austin, Texas, have dwelled in windowless rooms for years − here’s why the city finally decided to ban them
But my mistake that aside, I appreciate your reply. I saw in another comment thread that you added that you have a blog post in the pipeline on building the new billing system. So I'm really looking forward to reading that. I've enjoyed reading other billing/payments content. And I'm sure your post will also be insightful and highly detailed.
I think it's so so fascinating that this feature is consistently solved at the contract/legal and customer support "layer" of the stack. That's really unpleasant to me, because it is a lot harder for me to wrap my head around the specifics of how different edge cases will play out.
Like as a programmer, I've built up all these skills on reaching technical documentation, understanding systems, their limits, and complex interactions. But instead of using that muscle memory, I have to try to talk with a human and deal with the seemingly intentional vagueness of the legal system.
It feels to me a lot like the story from Mitchell Hashimoto about dealing with the bank for his startup, where he was dodging calls from his account executive and generally behaving in a way that the bank is not used to from enterprise clients. [0]
I'm ready to admit my behavior is anti-social and irrational here. But, it is what comes natural to me.
This is meandering now. But, I just want to sneak in a bit more info on my use cases, since you also mentioned that people are wearing you down and you just might implement this if forced to.
I build and run internal tools (think CRUD & reporting/analytics) for a small department in an extremely large enterprise. Our stuff is on the order of 99.9% available. So not particularly great but not not terrible. But, others are extremely bad. For example, one vendor has over 36 hours of scheduled downtime per month. And that system is way more critical to the business than mine.
So the standard that my coworkers in the department have come to expect is very low. If the tool is down, they just continue with their day doing some other task.
Many of the systems I manage are also purely background jobs. And no one would even notice if they were down for 12-24 hours.
Lastly, we have external backups for everything (on a different provider) and every system's deployment is automated from creating the VM's, networks, and block storage all the way through to installing system dependencies, the app, and data.
So, if a system were to magically get deleted some day, I'd get paged and have it back up in about an hour. And this is totally fine for our business.
On the other side though, there will be dire consequences for my career if we go over $25k annual spend. Even if the bill arrives and we have to contact support, it will give my management a heart attack and they will absolutely remember come review time.
Given this environment, I'd really appreciate the ability to protect myself against misconfiguration or leaked keys causing me to get possibly fired. The data will be fine. And systems can be restored quickly. But the damage to my reputation, compensation, and future job can't be restored quickly.
[0] https://mitchellh.com/writing/my-startup-banking-story
> Many of the systems I manage are also purely background jobs. And no one would even notice if they were down for 12-24 hours.
What would it take for providers to listen to real customers here?
I have $25k in cloud spend that we absolutely cannot go one single cent over due to the politics of internal budgeting. That's my reality. If you want my $25k, I need to ensure that I don't spend more than this amount.
As is, my solution is to use old-school pre-rented, long-term contracted commitment VM hosting providers. This is really the only way to guarantee that you are paying an exact amount and no more.
But, I really would like to use a more scalable system that didn't require pre-provisioning. And, I wish people would believe the customer when they say something and not continue to gaslight us.
Providers say it's impossible, but I don't see how it would be so hard. Here's my sketch of how it could work:
The main component is a system that monitors billing events and watches for the slope of the bill to ensure that there is enough runway to stay under the cap. Optionally, they could implement rate limits on resource creation to ensure that a sudden surge doesn't outrun the monitoring.
You also need notifications for when the projected spend exceeds the cap. Optionally, you could implement a soft cap, where no new resources can be created.
And finally, you need the hard cap where things start to get deleted. If they're feeling generous, the provider could implement a period where VM's/lambda's/etc are shut off, blob storage is not accessible, and so on so that the account holder has some time to fund the account and/or fix whatever is causing the overage.
That set of features are all totally within the competency of a cloud provider. Knowing how much things cost, billing for them, and turning them on and off is their main business. And I can't believe that they expect us to believe that it's impossible to do that tracking.
This is how I do system migrations. There are escalating warnings until one day the service is shutoff for an hour and turned back on. That wakes up any laggards that missed the dozen or so communications over a three-to-six month period. Finally, after a few more days, the service is shutdown for good and then data is deleted a week after that. Though I almost always keep a copy in cold storage. But that isn't necessary as a provider with a limited relationship to the client.
We showed our lawyers that we were using the FOSS version. But, they didn't care and demanded we remove their product (despite being FOSS) immediately on all our systems.
That was a crazy crazy week.
You can say that's a problem with our lawyers. But still, who wants to go to court even if you know that you'll win eventually? It's expensive and incredibly annoying as an engineer to have to deal with lawyers.