sgarland

44 ms·

781.
by sgarland 1y ago
It's very hit or miss. Claude does OK-ish, others less so. You have to explicitly state the DB and version, otherwise it will assume you have access to functions / features that may not exist. Even then, they'll often make su
782.
by sgarland 1y ago
This doesn't make sense. From a schema standpoint, table `orders` presumably has a row per order, with columns like `user_id`, `status` (as you stated), `created_at` (same), etc. Why would there be a `count` column? What does that repr
783.
by sgarland 1y ago
I think that honor still belongs to "Did you win the Putnam?" [0] but this is definitely still in the top 5. [0]: https://news.ycombinator.com/item?id=35079
784.
by sgarland 1y ago
So don’t do that? Send data to workers as primitives, and have a separate process that reads the results and serializes it into whatever form you want.
785.
by sgarland 1y ago
Well don’t use Fargate, there’s your problem. Run programs on actual servers, not magical serverless bullshit.
786.
by sgarland 1y ago
OK, but this was from Twitter.
787.
by sgarland 1y ago
Just use multiprocessing. If each job is independent and you aren’t trying to spread it out over multiple workers, it seems much easier and less risky to spawn a worker for each job. Use SharedMemory to pass the data back and forth.
788.
by sgarland 1y ago
> Instead, many reach for multiprocessing, but spawning processes is expensive Agreed. > and communicating across processes often requires making expensive copies of data SharedMemory [0] exists. Never understood why this isn’t used m
789.
by sgarland 1y ago
Indiana has one of the most fucked-up TZ delineations in the country. Northwest corner: America/Chicago. Southwest corner: America/Chicago. Everywhere else, including directly North/South of those two quadrants: America/
790.
by sgarland 1y ago
Or, you know, UTC. It is always baffling to me when large, global companies allow the use of anything else, especially in anything incident-adjacent.
791.
by sgarland 1y ago
Agreed. I would hellban their entire company permanently, and devote time and effort to write tooling to catch future signup attempts. This is utterly despicable.
792.
by sgarland 1y ago
I would not personally build a TSDB atop MySQL, though I worked at a place that did, and it worked OK. I don't remember their schema, though. If I had to, I'd probably do something like this (haven't tested it beyond validati
793.
by sgarland 1y ago
Unfortunately, most places go with hardware first, so the problem grows larger and larger. When they do finally hire someone who knows how to address it, it’s a monstrous undertaking that dev teams are reluctant to do, because it’s a length
794.
by sgarland 1y ago
Because MySQL got a (rightfully so) bad rap before it adopted InnoDB as the default storage engine, and then tech influencers happened. I love Postgres, but I also love MySQL, and 99% of the time I see people gushing about Postgres, they ar
795.
by sgarland 1y ago
That’s not the fault of the DB, though, that’s bad schema design. Avoiding JOINs is rarely the correct approach.
796.
by sgarland 1y ago
Two. Run one in warm/hot standby, optionally with synchronous commits if you want (nearly) guaranteed zero data loss, and can tolerate the increased write latency. Technically you’ll need a third server to perform the failover, but it
797.
by sgarland 1y ago
Agreed. Devs usually do a double take when I tell them that their table with 100K rows is not in fact big, or even medium. Everyone’s experiences are different, of course, but to me, big is somewhere in the high hundreds of millions range.
798.
by sgarland 1y ago
Yes, global read replicas can be helpful, though the replica lag needs to be thoughtfully considered. IMO, one of the worst offenders is places with microservices, who absolutely do not need microservices, and are doing reads-after-writes.
799.
by sgarland 1y ago
I just ordered a ZSA Moonlander in the hopes it will help, because it’s been getting progressively worse for me. I have an Uplift desk (which admittedly I never use in the standing position; it’s just a great desk that I could precisely pos
800.
by sgarland 1y ago
There are multi-master Postgres options like BDR (I think it’s since renamed; whatever EnterpriseDB calls it now), yes. Most people don’t need it, even if they think they do, and they also usually are in no way capable of dealing with the o
801.
by sgarland 1y ago
It is forever enraging to me that ORMs turn SELECT * into each individual column, mostly because people then post the whole thing and it’s obnoxiously large. Similarly maddening, the appalling lack of normalization that is simply taken for
802.
by sgarland 1y ago
For food and drinks, I agree, but when I’m ready to go to bed, I don’t want an adventure, I want a comfortable and quiet room that I’m already accustomed to.
803.
by sgarland 1y ago
I have stayed at many hotels of varying degrees of quality all over the U.S., and I have never, not once, seen the laundry being used. It’s always been available.
804.
by sgarland 1y ago
You’re right, and I shouldn’t necessarily blame devs for the idea, though I do blame their CTO for not standing up to it if nothing else. Though it’s also unclear to me in this particular case why they couldn’t collect commands being issued
805.
by sgarland 1y ago
Yep. I’m a DBRE, and can confirm, it’s almost always the DB, with the explicit caveat that it’s also rarely the fault of the DB itself, but rather the fault of poor schema and query design. Queries I can sometimes rewrite, and there’s not
806.
by sgarland 1y ago
IMO, the prime offender is simply not understanding fundamentals. From simple things like “a network call is orders of magnitude slower than a local disk, which is orders of magnitude slower than RAM…” (and moreover, not understanding that
807.
by sgarland 1y ago
Correction: devs have made the mistake of turning everything into remote calls, without having any understanding as to the performance implications of doing so. Sonos’ app is a perfect example of this. The old app controlled everything loca
808.
by sgarland 1y ago
I’m sure you know this, but a reminder that modern devices cache a hell of a lot, even when you “quit” such that subsequent launches are faster. Such is the benefit of more RAM. I could compare Slack to, say, HexChat (or any other IRC clien
809.
by sgarland 1y ago
Yes, it’s easy to accidentally or purposefully do. An example of what I’m talking about is “I’m going to cause an N+1, row lock contention, and slow writes by looping over a list of IDs while holding a transaction open, retrieving informati
810.
by sgarland 1y ago
I don’t generally blog about it, but I may at some point. For specific discussions on what I wrote about, I recommend (other than reading Postgres’ docs, of course) this [0] and this [1], and anything else on those sites. If you like techni

More ›