walrus1066

Here's the technological aspect of how China oppresses the uighur community: https://www.theguardian.com/news/2019/apr/11/china-hi-tech-w....

Terrifying stuff, it literally is straight out of a black mirror episode.

"But of course, the CCP is ideologically opposed to self-representation."

Don't think it's to do with ideology, just desire of a small cabal of people to have absolute power and control over a country and everyone who lives in it.

The ideology is a pretext.

In my view, accidents aren't the main issue, it's more the disruption caused if an AV, with no human driver, encounters the 'freezing robot problem' (I.e. When traffic lights not working, with policeman directing traffic) & gets stuck in a busy city centre, blocking traffic all around.

I'm not aware of any fallback remote takeover mechanism that can be used to recover AV's on this situation.

EDIT: I'm convinced, that until we majorly overhaul our road infrastructure to be more 'robot friendly', it's hard to see _fully_ autonomous AV's work in major cities I.e. electronic beacons on lane dividers, electronic signals on traffic lights, vastly stronger GPS network or replacement thereof, six nines level mobile network coverage at high bandwidth.

I'd honestly just walk out if a company asks this stuff, yet the actual work is maintaining a CRUD app.

"AI is the phrase behind which magic hides and people love magic. Everything that has the aura of “humans don’t fully understand how it works in detail” will be used by charlartans, snake oil salesmen and conmen."

100% this!

How does a profitability dial work for companies like uber, which don't have the network effect monopoly that the Amazon's, Facebook's etc have?

Hike prices for passengers -> passengers leave platform & switch to local/regional alternatives

Cut wages for drivers -> drivers move to do more shifts for better paying competitors

"Uber/Lyft do have a VCs-will-not-race-to-the-bottom-with-them moat, and tomorrow they might as well raise their prices to turn profitable."

That's the multi billion $ question, if they hike prices to become profitable, will customers swallow it, or jump to local alternatives. My feeling is the latter, I don't think you get economy of scale for running a taxi business, because your biggest cost is paying local drivers.

I presume it's because they're contracting? It's the way to cash out in software in the UK, I believe in most companies, contractors get to sidestep the HR/salary budget hierarchy, usually because the company is really desperate, and they tell themselves "they're only temporary, so won't apply salary banding on them"

"10 teams of 3 each owning their own little slice of the pie sounds like an organizational nightmare; mostly, you can't keep each team fully occupied with just that one service, that's not how it works. And any task that touches more than one microservice will involve a lot of overhead with teams coordinating."

I guess that's where the critical challenge lies. You'd better be damn sure you know your business domain better than the business itself! So you can lay down the right boundaries, contracts & responsibilities for your services.

Once your service boundaries are laid down, they're very hard to change

It takes just one cross-cutting requirement change to tank your architecture and turn it into a distributed ball of mud!

I think other professions emphasise past experience and referrals more. That and official credentials, especially in certified professions (I.e. Medicine).

That said, I think all interviews have an element of silliness to them. I know a financial consultant who was quizzed over articles published in the days financial times newspaper. Also know one of our analysts makes candidates do long division on paper! Don't forget the infamous how many golf balls can you fit in a jumbo jet kind of thing.

Personal experience on this. My degree (physics) was nearly completely orthogonal to my career (software engineer).

But I have no doubt it helped me get not just my first job, but also subsequent ones, probably due to 'his code/tech talk could be better, but he seems smart and has a physics doctorate from a prestigious institution'.

Think software hiring+quality would be much better if we had an apprecticeship culture, instead of based on perceived prestige from excelling at University.

"The ways engineers are terrible managers non-technical managers are often terrible too. In addition to that, they also know less about work itself and are more likely to be insecure about that."

I would put that as another human/personal trait, the ability to openly acknowledge ones limitations and delegate/defer when someone else has more expertise than you. For example, when making a technical decision, deferring to the tech lead & individual contributors.

If anything, a technical manager whose tech skills are/have slipped away is more likely to be insecure than someone non technical.

"Non technical management - this should speak for itself. I've done it before to much regret."

I wouldn't put this as a con, I've seen lots of engineers turn into terrible managers, because the skills are completely orthogonal, they also then lose touch with the tech - because that's what happens if you stop coding for even a few months.

Vice versa, I've worked with lots of good non technical managers, who respect and defer to you for technical decisions, planning etc

And of course the other way round, also seen good technical managers and bad non technical ones.

In summary, technical experience of a manager is not an indicator for me, what is are the human factors, do they micromanage? Are they happy to cede control and delegate? Do they give realistic deadlines instead of death marches?

I understand anther part is, they can't afford to have unemployment either, especially in the restive uighur and Tibet regions.

Having millions of unemployed young men, without a political channel to air their grievances would surely spell trouble for the regime there...

What's this got to do with Richard Feynman?

I'm not sure it's easy for a software engineer to develop a model, it's quite an orthogonal skill, you need a solid grasp on mathematics and especially statistics.

Must have been really exciting time to be particle physicist in those days. SLAC & other colliders enabled a revolution in physics, culminating in the formulation & verification of the standard model - a truly unparalleled feat of scientific progress.

https://www.symmetrymagazine.org/article/november-2014/the-n...

I always understood that the Stress–energy tensor in general relativity has a momentum component, so two electrons whizzing past each other at near the speed of light would exert a stronger gravitational pull between them, in all frames of reference, than if the electrons were 'at rest', relative to each other? I admit I didn't study GR so happy to be corrected!

Minor clarification. The standard model does not describe gravity. It ignores it, which is fine at LHC energies because it's orders of magnitude weaker than the other three forces.

At the planck energy scale, this is no longer the case, the relativistic mass of particles becomes so big that gravitational interaction is too strong to be ignored, and the SM loses it's ability to predict how particles interact, decay, combine etc

So you're guaranteed to then see 'new physics'.

Indeed, I've never in my career (in high level businesses, I.e. Finance, advertising) seen such a thing as a proper 'specification'.

It's more the business has a high level, rough idea of a change/feature to improve the business, and we figure out together the exact details, some of which surface during implementation, and then verify it gradually in the wild.

We could have spent x10 time instead drawing up a formal spec up front, but it would have so many assumptions baked in, that it'd get invalidated in the wild anyway.

Imagine that's part of the challenge. Since python is dynamically typed/duck typed, it's hard to audit all usages of a variable. I.e. If I see a py2 string declared, how can I be 100% sure I don't break downstream components by making it a bytes or py3 unicode string? Some might be using it as the former, others the latter.

You'd need insane test coverage, of all possible code paths, to be 100% confident.

That's the energy scale where the force of gravity becomes strong enough to influence subatomic particle interactions.

Currently, our model of nature at subatomic scales (the 'Standard Model') does not include gravity. This is fine for LHC energy scale, because gravity is so weak compared to the other three forces (electromagnetism, strong & weak nuclear force), that it can be ignored. The mass of quarks, electrons etc is tiny, you can make precise predictions on stuff like 'particle X will decay into particles Y & Z at this likelihood', without accommodating gravity.

But at the planck energy scale, gravity is too strong to be ignored, and the Standard Model breaks down, it can't make predictions. So this is why the planck scale is where you're 100% guaranteed to see 'new physics'.

https://en.m.wikipedia.org/wiki/Planck_units

EDIT: think the reason gravity becomes stronger at higher energies, is because the _relativistic mass_ of particles increases with their velocity.

So if you bang two electrons a&b together at nearly the speed of light, the effective mass of electron a from the frame of reference of electron b will be orders of magnitude greater than the 'rest mass of electron a'. Because strength of gravitational interaction is proportional to mass of particles involved, electron b will feel stronger gravitational pull of electron a (and vice versa).

So if the electrons are traveling at planck scale speeds, the strength of gravitational interaction becomes comparable to the electromagnetic interaction between them. Then all standard model predictions of how the electrons interact goes out of the window, because SM cannot model gravity.

https://en.m.wikipedia.org/wiki/Mass_in_special_relativity

Ktor, it's working really well, only downside is limited openAPI/swagger support, i.e. Schema first or code first code/schema generation.

Kotlin, our company had recently turned into a java shop, and I was literally tempted to throw in the towel because I'm used to C# & python, so the boilerplate was really unpalatable.

Then one of our team wrote a service in kotlin, and we never looked back, I had my type inference, extension methods & null safety back, along with really strong immutability features, pure functions to boot.

It is such a pleasure to work with, it's in my opinion the pinnacle of traditional statically typed OO language (C#, java etc)

EDIT: now, all new services in our company are written in kotlin, it got grass roots adoption in every team (bar one which came from a much more old-school java background)

It'd have to be a really heavy planet to see obvious gravitational lensing effects (I.e. Sun size).

We detect planets in other systems by seeing them pass in front of the host star, or we detect them radiating IR, or if exoplanet is really big, with small orbit, it's gravitational influence on the host star (I.e. see it 'wobble').

In all cases, exoplanet is quite close in orbit to star.

By contrast, if a big planet is orbiting sun, but really far away (>x100 earth-to-sun-distance), it'd be to cold to detect it radiating any IR, it'd be too far to see obvious effects of it's gravity.

You can compose queries, using the queryAPI in SQLAlchemy, without touching the ORM.

Cool stuff.

The computation side of the LHC is really impressive. For a full software trigger, you have 25 nanoseconds in which to load all the raw collision data, reconstruct 100's of particle tracks, calculate their momentum, join them up to figure out their decay vertices etc etc, and then, decide whether to store the event.

I recall LHCb could afford higher trigger-rates than CMS/Atlas, an LHCb event is smaller (~100 kB vs 1 MB for CMS) because the detector only covers 300 milli-radians from the collision-axis, in one direction, whereas CMS/Atlas have full coverage.

Absolutely, also worth adding the detectors also have 'minimum bias' triggers, that store a small fraction of events without applying any selection criteria. I recall this was mainly used for calibration and verifying stimulation data. So we still have many petabytes of collision events that did not have any selection criteria applied.

'During experiments, the LHC creates about a billion proton-proton collisions per second. … The events are filtered in real time and discarded unless an algorithm marks them as interesting. From a billion events, this “trigger mechanism” keeps only one hundred to two hundred selected ones. … That CERN has spent the last ten years deleting data that hold the key to new fundamental physics is what I would call the nightmare scenario.'

I don't know what the author is proposing. We don't have enough storage to persist all collision events, that would require zettabytes of disk space. The detectors are bottlenecked to store a few hundred events a second. Therefore they need to filter out the majority of the 40 million collision events per second that occur in the LHC.

Even then, I recall around 1% or so of the stored events were saved via a 'minimal bias' trigger, one that doesn't apply any filter criteria. This was mainly for calibration purposes, and cross checking stimulation data. So we still have petabytes of collision events that didn't have any selection criteria applied.

Who would be held responsible? Coder? QA? Code reviewer? PM? person putting pressure on PM?