Why are people using "learnings" as a word, when "lessons" already fits all its use cases? It's quite jarring.
Readit NewsYourDadVPN commented on Learnings from our years of Kubernetes in production medium.com/@.anders/learn... · Posted by u/jonsson101
I wonder if they had accelerometers recording exactly what happened as it touched down and ended up on it's back?
It was meant to use a rather odd "two-step" landing procedure where it first touches down on the lunar surface on it's rear/primary landing gear, then pivots forward/falls under gravity to also touch down on the front/secondary landing gear.
Presumably this landing procedure was simulated under lunar gravity, but it seems there are multiple potential failure modes:
1) After rear "leg" touchdown, over-rotate forwards over front leg (ending up on back), OR
2) After front "leg" touchdown, bounce/recoil backwards off front leg, flipping onto back, OR
3) Front landing gear hits rock on one side (left or right), thereby flipping it sideways onto back
The whole procedure seems to rely not only on having correctly simulated under lunar gravity (and with correctly simulated stiffness of the vehicle) to avoid scenarios 1) & 2) (which would be different under earth gravity), but also the softness of the landing site being uniform and as simulated - otherwise if landing site surface was harder (rock) or softer than expected, or uneven, then this type of pivot and bounce/not landing would not go as planned.
NASA seems to have done a better job in designing fool-proof landing mechanisms, from the bouncing ball of the first mars rover, to the sky-crane landing of the latest one (which appears over-complicated, but no doubt was chosen at least in part because it is in fact more predictable than the alternatives).
Considering they knew these failure modes in advance, would it not have been prudent to put some sort of self-righting mechanism on the lander? Something like the mechanical arms you see in Robot Wars.
Coverage is necessary but not sufficient, your tests also need to be good and test the right things. What's your proposed alternative - that we don't even try because our tests aren't guaranteed to be perfect?
Well, almost. I use a lot of assertions to check the obvious (value out of range, null pointer, etc.) and test the happy path(s) to prove the code at least works in the cases I can anticipate. I add unit tests for complex algorithms, and to prove a reported bug is what I think it is and that it has been fixed. Otherwise, I think using unit tests to find bugs is mostly busywork.
For even a fairly trivial piece of code, the search space for bugs can be vast or even infinite. Writing unit tests to find bugs within that space is like throwing darts at an infinitely large wall and trying to hit an unknown number of invisible targets. You can only write tests for the potential bugs you anticipate - if you could anticipate a bug, you wouldn't write it, right? You end up with dozens or hundreds of tests that probably never failed, except when you have to change something. Such was my experience when I tried to maintain high code coverage. When I switched to writing assertions and acceptance tests, my rate of bug reports did not change, and I was more agile.
By getting good at testing. I worked on a project with a 100% coverage requirement for a few years, and it forced me to learn how to test things that I normally wouldn't bother with. It also forced me to deal with the consequences of maintaining my tests.
I've discovered that the usual buckets used to categorize tests (unit, integration, etc) can mislead people into writing tests that make refactors painful/impossible. If you test each "unit" in isolation, then you limit your ability to change how the units interact (even if the user-facing behavior isn't changing at all.) You end up needing to change/rewrite the tests for each "unit".
Instead of units, I think about supported interfaces and tricky dependencies. Ideally, I'd test using the user-facing interface. That way, the test only changes if the user-facing (supported) behavior changes. Then I swap out any tricky dependencies (mainly slow/nondeterministic operations) for fakes/stubs/mocks. In the end, the tests look like "integration" tests, but they fit into your CI pipeline in the same place unit tests would.
This testing strategy makes me much faster and more effective. I can start writing tests before I've worked out how I'll organize the components. And if I change my mind halfway through, I don't need to rewrite any tests. If done right, those tests can survive years of refactoring with little maintenance.
There's more to good testing and being a great programmer than this, of course. But this is the lesson that has had the biggest impact on my "greatness" at programming.
What is your opinion of code coverage requirements now? I have been in a "phase" of seeing them as "code quality theatre". Considering that a function which takes a single 8-bit integer as an argument already has 256 unique inputs, and may bug only on 1-2 values, 100% statement coverage can be very misleading. A typical function has billions or trillions of unique inputs and 100% statement coverage could be very nearly 0% state space coverage. I'm 5y into my career (but 15y into programming) and aware that my opinions will change and develop as I progress. This one has been stable for a while though.
I think the best way to achieve this is by providing an OS API that results in the files always being created in the same place. Applications/libraries could still choose their own filenames and syntax, just the location would be OS controlled. I think there is room for a new desktop/laptop OS to emerge and one good idea from mobile OS design I would like to see is having everything be an API call that allows the OS to impose standardisation, permissions and user preferences rather than the free-for-all desktop OSes have (though I propose letting the user run non-compliant applications, and not porting the iOS app store only model into the OS).
13 years old is old. I don’t know why people are always this revisionist and pretend children aren’t sentient.
By 13 you’re mostly developed. You lack life experience so you’re a little naive and you lack the final development of the brain but you’re basically a finished person.
There’s no way that at 13 you don’t understand that spending 64k is wrong. That’s an absolutely absurd amount of money. It’s like when people like you say they don’t know murder is wrong. You don’t have to be 25 to know stealing 60k is wrong.
At 29, I don't feel like I was "basically finished" until 25 or so, and feel significantly more mature than I was even a year ago. I'm very interested to know why you think 13 year olds are mostly finished developing.
YourDadVPN commented on Apple reveals Vision Pro, a AR/VR headset unlike any other arstechnica.com/gadgets/2... · Posted by u/thx-2718
I mean, I don't think most of us commenting here are Apple ads. I think we're all hoping that if Apple is jumping into VR, then finally it'll be good enough for us all to adopt massively, the same way we all have smartphones. That's an exciting prospect, even if we don't necessarily "like" Apple.
But at $3500 for one, I think they've blown it. I'll wait for the reviews, and if it really does deliver on all the promises, then that'll be nice. Somehow, I doubt that it'll happen though.
I was talking about the posts/linked articles rather than the comments. I counted six in the first 20 posts, and the titles are mostly quite ad-like.
While I was initially interested by the announcement, the size, lack of internal battery and price makes this a hard no for me. Idk what they were thinking - doesn't anyone remember Google Glass? That was half the price and size and nobody wanted it.
YourDadVPN commented on Apple reveals Vision Pro, a AR/VR headset unlike any other arstechnica.com/gadgets/2... · Posted by u/thx-2718
Wonder how much Apple paid for all these ads.
Why was Bitcoin an option?