Exactly! You actually CAN have 50 people finish something 50x faster, but it takes a shitload of planning, and that equals time and money no company I have ever worked for, or even known of, would allocate to something that isn’t generating immediate income.
Take the Hoover Dam for example: Dsigned over 3 ish years and built in 5, at a time when nothing that huge had ever been made before, at less than a billion in today money, and 2 years ahead of schedule. It’s 90 years old.
Yes, you need to push back on those people. They’re the type that get high on code golf and end up writing unmaintainable one-liners measured in kilobytes for fun.
JavaScript: :wide eyed and smiling: Sure why not! You’re the boss!
Python: Sighing and downing half a bottle of Advil: Sure. Why not, you’re the boss.
The scripting language formerly known as Java.
that’s amazing.
Where’s all the “solar panels and batteries are just as bad as oil” people.
Tabs are a dark pattern confirmed.
The war is over, long live spaces.
I’m going to rename my NAS “online discussions” in your honor.
It’s two separate statements. We don’t live in a post scarcity world. Power grids have physical limitations regarding power in and power out.
The person you’re responding to is talking about physics, not economics.
That’s why the cat is smug. It knows you know this.
…and I hope not, bleh.
A repo dedicated to non-unit-test tests would be the best way to go. No need to pollute your main code repo with orders of magnitude more code and junk than the actual application.
That said, from what I understand of the exploit, it could have been avoided by having packaging and testing run in different environments (I could be wrong here, I’ve only given the explanation a cursory look). The tests modified the code that got released. Tests rightly shouldn’t be constrained by other demands (like specific versions of libraries that may be shared between the test and build steps, for example), and the deploy/build step shouldn’t have to work around whatever side effects the tests might create. Containers are easy to spin up.
Keeping them separate helps. Sure, you could do folders on the same repo, but test repos are usually huge compared to code repos (in my experience) and it’s nicer to work with a repo that keeps its focus tight.
It’s comically dumb to assume all tests are equal and should absolutely live in the same repo as the code they test, when writing tests that function multiple codebases is trivial, necessary, and ubiquitous.
The worst part of it is most big companies are forcing RTO to either justify the leases they don’t want to pay to break, or to satisfy tax incentives agreements they made with municipalities.
In both cases, they’re deciding it’s better if you pay - in time, gas, car maintenance, mental health, productivity, and stress - for their business decisions that went bad instead of paying money out of their own bloated pockets.
I see a dark room of shady, hoody-wearing, code-projected-on-their-faces, typing-on-two-keyboards-at-once 90’s movie style hackers. The tables are littered with empty energy drink cans and empty pill bottles.
A man walks in. Smoking a thin cigarette, covered in tattoos and dressed in the flashiest interpretation of “Yakuza Gangster” imaginable, he grunts with disgust and mutters something in Japanese as he throws the cigarette to the floor, grinding it into the carpet with his thousand dollar shoes.
Flipping on the lights with an angry flourish, he yells at the room to gather for standup.
If you want to do web requests/ use API’s, use ‘requests’
graphs/reporting, I’ve used ‘bokeh’ before, it was nice.
I’ve never used PyDroid, so I’m not sure how you’d install things, but these are both available via pypi, python’s package repository.