I can confirm that you are completely right about Vietnam mobile networks. I could only reliably work after getting a real viettel sim. Even viettel branded stores sell some bootleg sim to tourists that work terribly.
The problem with eSIM is that usually there is no way to judge the quality until you buy one, so people sort by price and choose the cheapest. If your solution offers the best network in the country then I’m interested, because even at x2 or x3 price it doesn’t matter much compared to the other expenses when traveling.
Not sure how you can convince customers outside the hn bubble.
I sometimes use left join to protect me against errors somewhere else.
Let’s say you do an inner join in insert into … select statement to find some other entity which 100% should be there. If something else is screwed up you might silently filtering out rows. With left join you keep everything, but not null constraint on the table protects you and turns it into an explicit error.
Yes, I was a bit unclear, but that was my question exactly. I hoped that there is some trick I don’t yet know. Dropping and creating these massive views is my nightmare.
I haven't read the source code, but how does it handle materialized views? Views refer to source tables by relation id, not by name, so by default you end up with views pointing to old tables, which also means can't drop them.
My use case is somewhat different. I have ~400M row tables which are not updated live, but I rebuild them from new source data, because it is faster that way (lots of columns, indices and FKs). There are also materialized views based on these tables, similarly with multiple indices.
I wrote some sql scripts using information_schema, which prepare new tables for data import, rebuild indices, FKs and then swap tables. After that scripts recreate materialized views from definitions and swap them. All happens without ACCESS EXCLUSIVE lock, so it can be still used by the backend. It sucks, though. I wouldn't mind if there was a way to have views use table names, so I could just refresh them after swapping tables.
Maybe the difference is cultural/environmental? I live in Europe in a city with organic street layout and I find Ikea easy to navigate. Unlike typical grid layout store, I can remember location of every section because they are more distinct. Also shortcuts feel natural just like when driving in the city. I always use them to skip 70% of the store. In a grid layout store I'm always lost, because I can't remember the aisles despite visiting them much more often.
I had to use the CTE trick few times to solve same nasty query plan in Postgres. While it worked well for me I would still prefer query hints. They are explicit, so the intent is obvious: “Dear future developer/me mind the execution plan”. A CTE might get removed by mistake or not be reevaluated if it’s still needed after Postgres version/statistics/index changes. Also as mentioned if you are still before pg14 there is this issue that you will have to materialize your CTE to keep the hack working.
I remember that the most irritating brownout I got due to a query plan change was when a 50 millisecond query started to use a seq scan, but on a table under 10 million rows, so it wasn’t obviously hanging like in the article, but took like 2-3s. It was just enough to fly under radar for our monitoring, but to make some important process much slower.
Indeed, he definitely could do his protest in a way which wouldn’t inconvenience billion dollar companies or even anyone.
Just like BLM could protest in a remote location or do an online petition. Except that no one would give a fuck about that. The same about a message during the build.
You call it a DoS attack, I call it a brownout warning about unsustainable open source funding. After all old versions are unaffected. No hidden RCE there. Only ones who opted in for pulling a new version without due diligence (aka free shit lovers) experienced a minor inconvenience. He didn’t do anything a malware author would do with such distribution channel.
I would definitely do it some other way, but can’t blame him. If he had put a notice during the build, no one would see it. If he added an unskippable five minute timeout to that message it would a DoS attack as well.
I suffered a similar “DoS attack” myself. By Microsoft. They did one hour brownout of Devops pipelines still using windows server 2016 or something, to warn about unsustainably of supporting them (striking similarity). Right at the moment we had to deploy an urgent hot fix for our client. If there was a notice somewhere, I didn’t read it. No one does. Which is why they do brownouts. He didn’t put an early warning, but that might be a difference between a multibillion company and some random guy on the internet.
He is unprofessional, but well, don’t expect professional behavior from people you don’t have professional relation with. Who I would call unprofessional, are the developers who expect free working shit from some random internet guy and have audacity to complain when he intentionally releases a broken version to protest taking free stuff without giving back.
I’m mildly entertained by the uproar caused by his protest. Reverting to an older version of a library is not an end of the world. I think it is not caused by the minor inconvenience he caused to the lazy devs, but by the threat of the end of relying on free work from open source devs.
We will have to do it ourselves or pay for it. Like in any other industry.
The problem with sql is what happens when you fall off the SELECT FROM JOIN WHERE GROUP BY HAVING ORDER BY LIMIT cliff. The simple stuff in sql reads like English, but for that case ORM would generate a pretty efficient query anyway. The complex stuff in sql looks terrible in my experience and ORM bail out quickly. Once you can’t get the result with a simple SELECT then sql stops being declarative. Instead of writing what you want to get, you write something like a postmodern poem while having a stroke, just to convince postgres benevolent spirits to give you something almost right. Complex UPDATEs and DELETEs with joins are even worse.
Also lack of syntax sugar doesn’t help. SELECT list could support something like “t1.* EXCEPT col1, col2”. Maybe JOIN ON foreign key would be nice. IS DISTINCT FROM for sane null comparisons looks terrible. Aliases for reusing complicated statements are really limited. Upsert syntax is painful. Window functions are so powerful that I can’t really complain about them though.
We use a lot of sql for business logic, but some code I have to reread from zero every time I need it. Maybe we modeled our data wrong or there is some inherent complexity you can’t avoid, but I mostly blame sql the language. Unfortunately I have no idea how it could be improved.
Anyway I think the sql cliff is real. Once you take a step outside the happy path prepare for a headache. For me sql definitely is in some local maxima, after all I use it every day at work.
I love how you describe this as “pushing malware to random servers”.
Maybe if he included a backdoor in previous versions and now dispatched infinite loop from his C&C server, sure. But he published a new version of his library, which was literally pulled by the affected parties.
I’m pretty sure that was illegal in the US, but that’s multiple-felonies-a-day-land anyway.
It would be great if it worked both ways. Let’s say an employee who is forced to work unpaid overtime (two jobs amount) could use power imbalance to threaten the company into paying one year of their revenue.
If his work quality is really that bad, why not fire him already? What if he was simply super lazy but with one job, why not make an example of him for other slackers?
I have never tried AWS managed elasticsearch, but Azure Search doesn't have many knobs. Most of the time it's just instance size, replica and partition count.
The downside is that the service is probably called "Azure Cognitive DeepMind Quantum DevOps Search" by now.
I think that the problem is when you have a materialized view which takes hours to refresh. We are lucky that 99% of our traffic is during 7-19 on weekdays, so we can just refresh at night, but that won't work for others.
I don't know much about how postgresql works internally, so I just probably don't understand the constraints. Anyway as I understand, there are two ways to refresh. You either refresh a view concurrently or not.
If not, then postgres rebuilds the view from its definition on the side and at the end some internal structures are switched from the old to the new query result. Seems reasonable, but for some reason, which I don't understand due to my limited knowledge, an exclusive access lock is held for the entire duration of the refresh and all read queries are blocked, what doesn't work for us.
If you refresh concurrently, postgres rebuilds the view from its definition and compares the old and the new query result with a full outer join to compute a diff. The diff is then applied to the old data (like regular table INSERT/UPDATE/DELETE I assume), so I think you get away with just an exclusive lock and read access still works. There are two downsides to this, first that it requires a UNIQUE constraint for the join, second that the full outer join is a lot of additional work.
I never had the time to test Materialize, but it seems to do what I want with its continuous refresh.
I also thought about splitting the materialized view into two, one for rarely changing data and another one for smaller part of the data which changes daily. Then I would only have to refresh the smaller view and UNION ALL both materialized views in a regular view. Not sure how well will that work with postgres query planner.
Yeah, using revolut for that is ironic, fighting scummy companies with another scummy company. It is the only way to get disposable cards or sane conversion rates in many markets unfortunately.
> We need to be able to see each other in the eye.
No, we don't, why would you think that?
We never have camera on and work is going smoothly. Nobody ever suggested using it. I don't even know how the new hires look like, but it doesn't matter, because I can treat them like humans without attaching a mental representation of their physical form. I got this skill from an experience called 'phone call'.
I wonder if it is a culture difference. I'm from eastern Europe and no one I have asked uses camera, outside those forced due to working directly with the US. People who can't stand not being able to judge their coworkers faces, where are you from?
Anyway, put your camera on if you want to, I can get used to ignoring it. Please don't force your preferences on others.
We couldn't technically make it stop exactly at $150.00, but only at $167.89 or whatever, so we are letting it run to $15k.
For catastrophic cases it doesn't matter. If it saves a person from an unexpected $15k bill then it works. Even for many businesses it would be ok to drop everything - I know some which can withstand being offline for a day, but not a $250k bill.
Maybe they are not upset about not winning, but that a fun to play game is now no fun at all? If there is an imbalance/glitch which renders most of the game depth obsolete I'm not leaving because I'm salty, I'm going to have actual fun elsewhere instead.
The problem with eSIM is that usually there is no way to judge the quality until you buy one, so people sort by price and choose the cheapest. If your solution offers the best network in the country then I’m interested, because even at x2 or x3 price it doesn’t matter much compared to the other expenses when traveling.
Not sure how you can convince customers outside the hn bubble.