Technically the US measurement system is metric since the Mendenhall Order of 1893 reestablished all customary units as conversion factors of metric units. In 1933 the ASA redefined the inch to be exactly 25.4mm, following the lead of the British Standards Institution in 1930 (precision was increasingly important for manufacturing, and the previous value of 25.40005mm had become impractical). The international yard and pound were officially adopted by the US National Bereau of Standards (now NIST) in 1959, the Metric Conversion Act was passed in 1975, and finally EO 12770 (1991) required all agencies of the executive branch to transition to metric units.
So, from one point of view we’ve been transitioning to metric since 1893 and it’s still not done. From another, the inch is just a metric unit as its length is officially defined in millimeters (all customary units are now based on SI units), therefore the conversion is complete.
The Intuitive Machines lander issue was that no one disarmed the safety switch on the laser guidance system. (No, really!) Luckily NASA had a backup system installed that ended up working better anyway.
Not sure if it ended up working better, as it landed with nonzero horizontal velocity. Though I suppose we’ll never know how well the original system would have performed…
First thing I do on my projects is enable warnings as errors and increase my warning levels when reasonable.
Unfortunately, the same can’t be said on the projects I work on at work. Drives me crazy that we get likes 300+ warnings whenever we run the app and that we can’t change it because "they’re just warnings*.
Though, I say that as I was basically forced to accept code that was using something marked deprecated because it was unreasonable to refactoring the code in that project. And I know we’re never going to change it unless it stops working. 😭 At least I marked it as an issue on the review.
Oh yeah, I’m genuinely about to hand-in my resignation as soon as I find another job over this kind of shit. I keep being told that the business is really trying to clean-up its act when it comes to coding practices, but they keep putting some of the most incompetent people I’ve ever worked with in charge of shit (because they do promotions based on years of experience instead of actual actionable experience). It’s awful.
It’s not that we want to ignore warnings. It’s just that most warnings take time to fix.
There’s only so many hours in a day. And we have to accept technical debt in order to deliver, and then pay it off later.
My job does it well by doing a “spring” and “summer” cleaning where we can turn out 100+ warnings into the single digits. Then busy season happens again and we’re back to 200+.
Speak for yourself, I promise you the team I work on actively ignores warnings and doesn’t even want to solve them as they pop-up. Being told you can’t compare doubles (because of precision loss) and ignoring it is on the developer and isn’t even that hard to fix. Most of our warnings come from shit like that.
Like, I get it. It’s probably not worth it to hunt down every “unused variable” warning (especially in an API where we used to have a variable for it and we don’t use it anymore and we don’t want to break the existing API so we just leave it there), but there’s things that are just trivial to fix when you’re working on code that’s right next to it.
Golang won’t even compile with dead code. Unfortunately that’s too strict, you just end up commenting out the whole block instead. At least the commented out code is obvious in review, and some automated checks catch it if you have them.
On the one hand: kind of sad since this isn’t too far removed from some workplaces. The hardware and furniture could be sourced from any number of places.
On the other: hot damn. We can get the same kit NASA uses at home. Welcome to the future.
At my workplace, we have a lint rule that reports an error if @nocommit is anywhere in the file, plus a commit hook that blocks all commits with @nocommit anywhere in them. It works well and has saved me a few times.
Works pretty well, except the lint rule and its associated tests have to do something like "@no"+"commit" to avoid triggering it,
In a lot of modern work flows this is incompatible with the development pattern.
For example, at my job we have to roll a test release through CI that we then have to deploy to a test kubernetes cluster. You can’t even do that if the build is failing because of linting issues.
The test release shouldn’t have anything marked with @nocommit though… The idea is that you use it to mark code that is only temporary local debugging code that should never be committed.
Are you committing to master? I don’t see any reason why you shouldn’t commit your debugging code to your own branch. Obviously clean it up before merging
At my first job after university, we did releases every Friday evening. From 3-5pm, all you would see in the Slack channel was a flurry of everyone committing straight to master (with a bunch of merge conflict commits between). Oh and then we’d release. Fun times.
A free for all, late Friday deployment is baffling… We’ve got a strict window of Tuesday-Thursday for releases (unless it’s a critical issue), and a 2-3 day merge freeze to help mitigate unexpected changes.
We’ve got a relatively small team with LOTS of moving parts, so minimizing deployment issues is always top of mind.
I literally know multi billion dollar B2C startups doing the same. It’s got so toxic that the management regularly fires people and to fill their spots, they offer obscene amounts of money just for starter positions.
We use a CI pipeline check which prevents merges to master if the code contains a TODO. A precommit hook only works if the developer has the hooks configured.
That’s no longer a technical process issue but more of a teamcoach/HR kind of issue then. You should be able to assume good intentions from colleagues, imho.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
They did it once by mixing meters and feets, and crashed the Mars lander.
Edit: looked it up, wasn’t actually meters vs feet, but newton-seconds vs some American eagles per gun unit for force
Hopefully, the transition to metric is soon and I can stop reading this same joke every week.
Technically the US measurement system is metric since the Mendenhall Order of 1893 reestablished all customary units as conversion factors of metric units. In 1933 the ASA redefined the inch to be exactly 25.4mm, following the lead of the British Standards Institution in 1930 (precision was increasingly important for manufacturing, and the previous value of 25.40005mm had become impractical). The international yard and pound were officially adopted by the US National Bereau of Standards (now NIST) in 1959, the Metric Conversion Act was passed in 1975, and finally EO 12770 (1991) required all agencies of the executive branch to transition to metric units.
So, from one point of view we’ve been transitioning to metric since 1893 and it’s still not done. From another, the inch is just a metric unit as its length is officially defined in millimeters (all customary units are now based on SI units), therefore the conversion is complete.
it happened again with the Intuitive Machines lander that landed on the moon last week
The Intuitive Machines lander issue was that no one disarmed the safety switch on the laser guidance system. (No, really!) Luckily NASA had a backup system installed that ended up working better anyway.
Pretty much the hardware version of && false
Not sure if it ended up working better, as it landed with nonzero horizontal velocity. Though I suppose we’ll never know how well the original system would have performed…
it’s an orbiter not a lander
It was intended to be an orbiter.
Ended up a missile
Peger the term high velocity lander
rods from god
It’s guns per eagle, get it right. What would eagles per gun even be?
A gun that shoots eagles, obviously
We don’t shoot eagles in America, we shoot turkeys. Just as Benjamin Franklin intended.
Step clap step step clap
https://tenor.com/bnL9B.gif
Pound-seconds, I believe. Good ol’ LM giving imperial numbers to NASA.
deleted by creator
I feel like modern compilers would turn their nose up at that shit. “Dead code? Ewww! No way I’m letting that into my syntax tree!”
Guess what? Flight Software usually uses ancient proprietary compilers for specialized hardware running an RTOS, rip 😢
Woah woah WOAH WOAH.
So you’re saying software for the Artemis landers aren’t being built with the latest TypeScript compiler and running on a canary version of v8?!
Lol
SpaceX actually did use some kind of TS/JS chrome browser thing for their docking controls lol…
A lot of IDEs would probably throw a warning about unreachable code.
most of my (rust) projects have zero (or maybe 1-2) warnings, unless I’m in the middle of working on a feature
First thing I do on my projects is enable warnings as errors and increase my warning levels when reasonable.
Unfortunately, the same can’t be said on the projects I work on at work. Drives me crazy that we get likes 300+ warnings whenever we run the app and that we can’t change it because "they’re just warnings*.
🤢 Good lord.
Though, I say that as I was basically forced to accept code that was using something marked deprecated because it was unreasonable to refactoring the code in that project. And I know we’re never going to change it unless it stops working. 😭 At least I marked it as an issue on the review.
Oh yeah, I’m genuinely about to hand-in my resignation as soon as I find another job over this kind of shit. I keep being told that the business is really trying to clean-up its act when it comes to coding practices, but they keep putting some of the most incompetent people I’ve ever worked with in charge of shit (because they do promotions based on years of experience instead of actual actionable experience). It’s awful.
Laughs in Xamarin. Only 300?
Well, it was a year ago, is Xamarin now finally changed to the new thing (what was it’s name)?
Maui!
Right, thanks. The KDE thing.
That’s when you add
#![deny(bad_code)], making sure that nobody notices.It’s not that we want to ignore warnings. It’s just that most warnings take time to fix.
There’s only so many hours in a day. And we have to accept technical debt in order to deliver, and then pay it off later.
My job does it well by doing a “spring” and “summer” cleaning where we can turn out 100+ warnings into the single digits. Then busy season happens again and we’re back to 200+.
Speak for yourself, I promise you the team I work on actively ignores warnings and doesn’t even want to solve them as they pop-up. Being told you can’t compare doubles (because of precision loss) and ignoring it is on the developer and isn’t even that hard to fix. Most of our warnings come from shit like that.
Like, I get it. It’s probably not worth it to hunt down every “unused variable” warning (especially in an API where we used to have a variable for it and we don’t use it anymore and we don’t want to break the existing API so we just leave it there), but there’s things that are just trivial to fix when you’re working on code that’s right next to it.
Golang won’t even compile with dead code. Unfortunately that’s too strict, you just end up commenting out the whole block instead. At least the commented out code is obvious in review, and some automated checks catch it if you have them.
var foo is declared but not usedis such a pain in my asshole when doing this.They still have those control desks in modern missions?
For NASA, similar desk layout, but it does look more modernized.
https://images-assets.nasa.gov/image/KSC-20181107-PH_BOE01_0002/KSC-20181107-PH_BOE01_0002~large.jpg
On the one hand: kind of sad since this isn’t too far removed from some workplaces. The hardware and furniture could be sourced from any number of places.
On the other: hot damn. We can get the same kit NASA uses at home. Welcome to the future.
That’s what i meant, all software and plugable devices now. Those desks were prohibitively expensive.
Dude looks like Hank and Dale had a baby.
He does, nothing but propain conspiracies all day long, and a too hot wife
Dank Grill
Other dude looks like the angry teacher from Daria
It’s ok we’ll QA in prod
Isn’t this pretty much what happened with the LIDAR on the most recent commercial moon lander?
Yes but it was a physical switch
Final flight checks:
“It’s off, so I turn it on and … WALK AWAY!”
Anyone know the artist? Saw another one by them a couple days ago about brute force protection.
The source is a user on Reddit: https://www.reddit.com/r/ProgrammerHumor/comments/1ayuh4b/comment/krx0p8h/ There are a few more on their profile.
Thanks Google lens
At my workplace, we have a lint rule that reports an error if
@nocommitis anywhere in the file, plus a commit hook that blocks all commits with@nocommitanywhere in them. It works well and has saved me a few times.Works pretty well, except the lint rule and its associated tests have to do something like
"@no"+"commit"to avoid triggering it,I did the same thing with “DO NOT MERGE” back in the day. Saved some people who didn’t even know about the check.
In a lot of modern work flows this is incompatible with the development pattern.
For example, at my job we have to roll a test release through CI that we then have to deploy to a test kubernetes cluster. You can’t even do that if the build is failing because of linting issues.
The test release shouldn’t have anything marked with
@nocommitthough… The idea is that you use it to mark code that is only temporary local debugging code that should never be committed.Are you committing to
master? I don’t see any reason why you shouldn’t commit your debugging code to your own branch. Obviously clean it up before mergingMy workplace uses feature flags rather than feature branches, and a continuous deployment cycle, so we only have one branch.
I will say I really like the naming here
This got a lot of compression over less than a couple of hours!
If a TODO passes code review, more than one person fucked up.
At my first job after university, we did releases every Friday evening. From 3-5pm, all you would see in the Slack channel was a flurry of everyone committing straight to master (with a bunch of merge conflict commits between). Oh and then we’d release. Fun times.
A free for all, late Friday deployment is baffling… We’ve got a strict window of Tuesday-Thursday for releases (unless it’s a critical issue), and a 2-3 day merge freeze to help mitigate unexpected changes.
We’ve got a relatively small team with LOTS of moving parts, so minimizing deployment issues is always top of mind.
I literally know multi billion dollar B2C startups doing the same. It’s got so toxic that the management regularly fires people and to fill their spots, they offer obscene amounts of money just for starter positions.
Where’s this? I feel like I can milk the company for a little while lol.
Especially the devops team. That keyword should be caught in a precommit hook
We use a CI pipeline check which prevents merges to master if the code contains a TODO. A precommit hook only works if the developer has the hooks configured.
See this is why the devops team should do it and not me
Eh, then you just get those idiots who avoid using TODO: because it makes the code review “harder”.
That’s no longer a technical process issue but more of a teamcoach/HR kind of issue then. You should be able to assume good intentions from colleagues, imho.
You guys do code reviews?
I mean, just look at how many patches in Android are marked DO NOT MERGE, DO NOT MERGE ANYWHERE, etc, but are in mainline
Ah, the Season 4 finale of For All Mankind.
deleted by creator
If anyone is interested there is a wonderful walk about one of the apollo flight computers
Die someone already mention the Apollo 14 computer hack .
git blame