ivix

Network infrastructure for Bluetooth: https://blecon.net

You have written this as if this doesn't routinely happen to every auto manufacturer. Why?

Been like that for decades. Only recently can you buy quality ice cream in supermarkets.

I'm surprised that you're surprised. Why on earth would government not be migrating to the cloud?

It's not an government agency. The post office is a completely private company.

They are right. Mercurial is better than git for 99% of usecases. But we lost this one.

The opinions of developers about low code solutions are not very relevant.

Low/no code solutions exist for when there isn't enough time or budget for a developer created solution, which is to say, pretty much all always. In the real world of business problems, almost nobody has access to a professional developer.

Think about how lightning exists, and you'll see why this is not an issue.

I suspect as with most things in education, they focus on small self contained problems because it's easier to teach and easier to grade. These toy problems end up being all students know and therefore are what employers select on.

Land cables are usually considered classified/sensitive information, so no not generally.

Cooling the stations is not an engineering challenge. It's a budget challenge. Installing and operating huge chillers is a solved problem.

Why on earth would you live your life by a sub single digit percentage swing in an abstrusely calculated macroeconomic statistic?

It's not the reverse. Nobody in the UK was calling this tree ancient.

They gave them the propaganda number.

If it's a detail to them, they might be looking at a bigger picture than you are.

Totally untrue. i know this for a fact.

Concluding that the planning in London is poor because you can't find manufacturing space is certainly...an opinion.

I think this is the correct answer.

To fix technical debt you often need a sexy sounding cover story.

I'm a little confused by this comment. It feels like you are complaining about the problems that are solved by configuration management and infrastructure as code, yet you seem to reject it as too complicated.

All the problems you raise are solved by infrastructure as code.

To understand how ancient this is, the Worshipful Company of Carmen's history began in 1272.

For US audiences, this operated as something like the DMV, hundreds of years before anyone had thought of such a thing. Over time obviously, these functions were taken over by a national government agency, but as the Worshipful Company of Carmen had had hundreds of years of history until that point, the traditions were kept in ceremonial form.

I find a lot of people conflate both service separation for human factors and service separation for technical factors.

Unless you have multiple independent development teams you do not need to worry about the human factors. Addressing them fully is always going to come at a technical cost in terms of things like latency and complexity.

Separation for technical reasons (generally scaling) may well be a factor but easily addressed without building 'true' microservices, for example with serverless functions.

Don't let the purists sneer at your architecture because it's not true microservices.

I think this is the answer for me. You kind of want friends, but at the same time you don't want to have to put any obligations or effort in and definitely don't want to feel forced to hang out with them.

I think we want the kind of friends who would be fine with a quarterly meetup for a fun activity, and little contact or obligation outside of that time.

What I find absolutely mystifying about Meta's VR experiment is that they did not leverage the colossal advantage they have in that for facebook users, they know your friend network and interests.

Why is the Meta product so catastrophically naff? What went wrong?

These days when perl enthusiasts say things like 'its terse' and 'there's more than one way to do it' and 'you can find a quick and short way to do interesting things' the reaction is more of faint nausea than anything else. Probably not what they were going for.

You have just described the whole software industry.

When in a serverless environment it's easy to get into a situation where you need to commit to deploy and test anything. Then git squash is essential, unless you're the only developer.

I have started to use lambda for serving an API backend and VueJS for the frontend.

Although there's a lack of nice frameworks, Lambda is great, being incredibly cheap and almost no scaling worries.

However for me developing a SPA front end is far more complex and problematic than in the Django days.

The cost of a fusion plant will be a small fraction of the cost of a fission plant, where the extreme safety requirements makes it expensive. People are now testing fusion in small regular industrial facilities.

That's why when you are using a polished product, all that detail is hidden from you, and not explained or mentioned at all.

It's just how it is, take it or leave it. To get away with this you need to have sufficient authority and agency however.

The trains serving London are carpeted, and it's not an issue.