throw156754228

You can't wish the complexity of business logic away. If it is vast and interconnected, then so is the code.

And have a dozen versions of the same logic leading to subtle bugs in production.

If only I had a pound for every discarded vape canister littered on the ground I've seen in London over the past few years. Will the ban fix this? I barely even know what a vape is.

> I don't think the government applying such levers to change how the market allocates capital probably won't be a win for economic output or quality of life.

We've got China cheating with their massively deflated currency, so how the market allocates capital is already screwed.

Who said I want my own data centre if I don't want to use AWS/GCP/Azure?

>It wont be easy or painless but it wont be impossible either.

With data egress costs, all the security infrastructure built up is all bespoke to a provider, not to mention engineers relearning the new provider's APIs and all its warts. The cost would be HUGE. Would be something that would go to a board for approval.

No this argument is not analogous. I worked for a bank that upped and moved offices on a commercial lease renewal. Let me know when you hear of a bank migrating Cloud providers and I will reconsider. It is 100% vendor lock in, no escape.

I like this, package.json starts to look really ugly when you build up lots of scripts that need to run interdependently. For example some stubbed back ends, front end, some auth service, etc. You end up with ugly long npm scripts with &&s everywhere. However for this sort of thing, personally I'd rather use docker compose, dependencies are explicit and declarative, like this I guess. You can define health checks for services with docker compose too.

I feel like Slack is 80% of the problem. Honestly I'd like to get rid of it at our company, and just have everything come down/go back up through my manager. I realise some of you probably have never experienced this.

>bit off more than it could chew

The fact that Dmitry was still pushing changes on the aeroplane, although he seemed to frame this as a positive, doesn't exactly inspire a lot of confidence in their professionalism, viewed from the outside.

Great discussion following the article in the comments. Bunsen was a legend.

The OP's article says Cadmium is not well absorbed from the gut. So even less reason to be concerned.

OP learnt about idempotency in http the hard way. However the post reminded me that I don't particularly like this hydration step of NextJS apps where there is javascript executing that is difficult if not impossible to step debug.

Follow the Ruby on Rails getting started guide and build a toy Rails web app. It has conventional http semantics baked in, you'll learn a lot.

It is indeed slow. It's a library written by non-developers for non-developers and it shows in the APIs.

Also their other well known problem: you lose the program state if an exception is thrown in the monad above.

I don't want to be relying on another flaky LLM for anything mission critical like this.

Just fix the original problem, don't layer an LLM into it.

No not test harder. You should be testing anyway.

What I mean is this code should be tested like any other, using visual testing suites like playwright or cypress.

Read my message again, I'm not saying 'just don't do that'.

The model of a word to a vector breaks down really quickly one you introduce the context and complexity of human language. That's why we went to contextual embeddings, but even they have issues.

Curious would it handle negation of trained keywords, e.g "not urgent"?

What is 'it' here in your sentence above?

I think in a nutshell you are saying a developer could accidentally hit tab one too many times. Just test against any visual regressions, it's not hard.

Honestly I always had a soft spot for haml. If someone wrote a haml plugin for React I would be in heaven. It's JSX that is an ugly hot mess in mature codebases, not html.

>The NODE_OPTIONS were only applying to the yarn process, not the underlying Next.js server that was being invoked by yarn.

Doesn't make sense. All child processes should get that env var.

I see it just strips the typings. So if I attach the debugger I'm still going to see javascript right?

TLDR last I written as a J.

It's even worse than the author writes. As the 'parameter' side of the equation gets trained on more and more scraped AI-spam garbage, summarising will actually get even worse than it already is.

A typical commercial change control process exists to factor in human error. There's a cost to setting it up. This company never set it up, but ended up paying another way.