glenjamin

That’s how you’d expect it to work, but that’s not how pod deletion works.

The pod delete event is sent out, and the load balancer and the pod itself both receive and react to it at the same time.

So unless the LB switchover is very quick, or the pod shutdown is slow - you get dropped requests - usually 502s.

Try googling for graceful k8s deploys and every article will say you have to put a preStop sleep in

The fundamental gap in my opinion, is that k8s has no mechanism (that I am aware of) to notify the load balancing mechanism (whether that's a service, ingress or gateway) that it intends to remove a node - and for the load balancer to confirm this is complete.

This is how all pre-k8s rolling deployment systems I've used have worked.

So instead we move the logic to the application, and put a sleep in the shutdown phase to account for the time it takes for the load balancer to process/acknowledge the shutdown and stop routing new traffic to that node.

The fact that the state of the art container orchestration system requires you to run a sleep command in order to not drop traffic on the floor is a travesty of system design.

We had perfectly good rolling deploys before k8s came on the scene, but k8s insistence on a single-phase deployment process means we end up with this silly workaround.

I yelled into the void about this once and I was told that this was inevitable because it's an eventually consistent distributed system. I'm pretty sure it could still have had a 2 phase pod shutdown by encoding a timeout on the first stage. Sure, it would have made some internals require more complex state - but isn't that the point of k8s? Instead everyone has to rediscover the sleep hack over and over again.

This strikes me as something that could be done for the highest traffic packages at the backend, rather than be driven by the client at pubish-time.

This matches my experience - I was intentional about not saying that a project manager was important - just that project management (the practice) is important.

This is called project management, and in my experience seems to be a practice/discipline that's often overlooked or ignored at startups and scaling tech companies.

Generally in my book projects should only be assigned to teams, and managing that project to completion should be part of that team's way of working.

Doing this in an agile manner generally means smaller projects, one at a time.

Having a proportion of the team act as triage for issues / alerts / questions / requests is a generally good pattern that I think is pretty common - especially when aligned with an on-call rotation. I've done it a few times by having a single person in a team of 6 or 7 do it. If you're having to devote 50% of your 4-person team to this sort of work, that suggests your ratios are a bit off imo.

The thing I found most surprising about this article was this phrasing:

> We instruct half the team (2 engineers) at a given point to work on long-running tasks in 2-4 week blocks. This could be refactors, big features, etc. During this time, they don’t have to deal with any support tickets or bugs. Their only job is to focus on getting their big PR out.

This suggests that this pair of people only release 1 big PR for that whole cycle - if that's the case this is an extremely late integration and I think you'd benefit from adopting a much more continuous integration and deployment process.

A question for both you and the parent: If you are heavily performance and memory constrained, why are you using a language that gives you relatively little control over allocations?

How do you handle errors when reading from a channel?

I think that’s the safest approach, but it’s inconvenient for the common case of an index that’ll be quick enough in practice.

The approach I’ve seen flyway take is to allow detecting / opting out of transactions on specific migrations

As long as you always apply migrations before deploying and abort the deploy if they time out or fail, then this approach is perfectly safe.

On the whole I think flyway does a decent job of making the easy things easy and the harder things possible - it just unfortunately comes with a bunch JVM baggage - so a Go based tool seems like a good alternative

The key here is that in production it's almost always not safe to actually apply a down migration - so it's better to make that clear than to pretend there's some way to reverse an irreversible operation.

This looks excellent!

The go tools for managing DB schema migrations have always felt lacking to me, and it seems like your tool ticks all of the boxes I had.

Except for one: lack of support for CREATE INDEX CONCURRENTLY (usually done by detecting that and skipping the transaction for that migration). How do you handle creating indexes without this?

Do you mean in TypeScript or in another language?

In TS the `Omit<T, K>` type can be used to remove stuff, and intersection can be used to add stuff

This post is pretty much a paraphrasing of the "Foundations: Why Britain Has Stagnated" essay, which was discussed a few days ago and apparently ultimately got flagged.

https://news.ycombinator.com/item?id=41600388

I’ve been asked to review massive PRs that were produced by a pair plenty of times.

If you want people to adopt your system, you should aim for it to be easier to adopt than whatever their alternatives are.

So I would look into where they're losing time because they need to deal with repeated or inconsistent UI stuff, and make those the priority for the library to deal with first.

If you're forcing work on them for no benefit, then you're not going to get any takeup - so I would also budget plenty of time for the kit-owning team to do a lot of the initial rollout until you can get enough of a critical mass.

To find out what’s going on in their lives and to arrange to meet up socially?

The Go standard library makes use of a number of “optional interfaces”, which it uses to detect when a type implements a higher level action in a more efficient or specific way

This can be thought of as duck typing.

Examples can be found here: https://blog.merovius.de/posts/2017-07-30-the-trouble-with-o...

Something that strikes me about Go's approach here, and the explanations in many of the posts on this page, are that they're all focused on what is happening under the hood: What memory are we pointing at, what's being copied, is it a pointer etc etc.

Whereas if we start from a point of view of "What semantics and performance guarantees do we desire?", we might end up with a more coherent user-facing interface (even if internally that leads to something more complex).

Personally, my mental model is often influenced by Python - where a name is distinct from a variable, but this distinction doesn't seem to appear in many other languages.

I think people's concept of how many items in a spreadsheet you can work through is often miscalibrated.

Does the author of this piece post their dataset? That would allow people to cross-check the results from GPT and see to what extent they think it got it right or wrong.

Categorizing 200 films based on ~10 attributes by reading their wikipedia overviews feels like it would be not significantly more work than building the fancy scrolling visualisation itself.

If there were 1000 films being analysed then I'd definitely be looking for some sort of tooling to help (or crowd sourcing the analysis)

I think a great takeaway from this article could be "standardization is not inherently valuable or desirable".

Standardization, like almost anything, has costs and benefits and tradeoffs and so on.

So when you're pushing to standardize something - consider what it is you're gaining and what it is you're losing, and decide whether that's a tradeoff you're ok with.

If you've ever tried to read data from an XLSX file, you'll find that streaming XML parsing is quite beneficial

And the world runs on Excel files.

Oh nice, I've recently been looking into streaming XML parsing in Go without a CGO depdency and found the available options pretty lacking.

Great to see this sort of thing!

Are you suggesting that most americans have a good grasp of how much water a cubic mile is?

Surely the standard unit for this sort of thing is multiples of well known large lakes or seas?

I think a lot of the more recent issues with gov.uk are the result of some defanging of the central service, leaving departments with more rope to do their own thing and believe that they know best.

Identity in particular is a complex subject, AIUI the original Verify project had to exist in the shadow of the No2ID campaign, which led them to avoid a centralised ID system. This then led to a much more complicated approach that was unable to cater for the needs of some of the departments.

For example, HMRC needed individuals and companies to be able to log in, and for whatever reason this was deemed unworkable with Verify, and thus they build the grandly titled "goverment gateway" auth system - and then I would assume that other depts saw this and decided that meant they could or should build their own auth systems too.

This is incorrect, the primary job of an on-call rotation is to satisfy customers.

It’s usually much better ROI to publicly acknowledge an issue if the resolution is not going to be single digit minutes, as it massively reduces the incoming query/support burden

Given that the token says it only allows reading of content and assets of this particular article for 1 month, it seems like this is an intentional feature for allowing subscribers to share paywalled URLs

A key datapoint not mentioned in the article is "Can this be used on AWS RDS?" - to which I believe the only option that meets that criteria right now is `pg_repack`

Related to this, there is quite a large variation across Postgres versions about whether a particular DML query will take an exclusive lock or not.

Is there a good way to analyse a query and be informed of what sort of lock it will take?

I’ve always resorted to re-reading docs when I’m unsure.

This is neat, but your implementation does seem to allow duplicates sometimes