I am super curious to know what kind of software magic they did to bring the NDL system as the primary navigation system after their own system failed to function prior to landing .. From what I understood listening in to the broadcast, NDL was only a demonstration project and folks somehow managed to bring it up on demand and use 2 of the sensors on it (?) iirc .. Like how !? Was NDL set up in the same orientation as their original system ? If not, they updated their guidance system on the fly too !?? Simply amazing
Yes it sounds like they had to do some MacGyver level stuff at the last minute. As I understand it NDL (Navigation Doppler Lidar) was a NASA project bundled aboard the craft as a non-mission-critical demo but when the main naviagation failed they had to send a patch to the craft (about two hours before landing) to activate NDL and use it as the main navigation. Hoping more details come out about this.
I doubt they had the time to pull MacGyver stuff. This scenario was most likely already predicted and tested and it was a matter of changing configurations.
Why? Here the asset used as collateral is a commitment to return the money if the loan isn’t repaid. Imagine I bought gold back when gold was 100$ , it’s current price is 1000$ and now I use it as collateral to get a loan . How is it fair that I have to pay taxes on 900$ of unrealized gains ?
No they didn’t because until the loan is repaid you can’t use whatever gold you put up for other purposes can you. What became tangible is what you used the loan for , that is what can be taxed.
Does the iPhone 14 still have the battery glued to the back? Couldn't figure it out from reading the article. I recently replaced the battery on my old iPhone 6s using the ifixit repair kit. Of all the steps I found removing the tape attached to the battery was the flakiest/hardest operation. After many attempts I did remove it but I also ended up cracking the battery a bit :sigh:. Any changes that make the removal of the battery easier would be a great win for repairability.
You have pq(original number) and (p-1)(q-1). You could get (p + q) = pq+1-(p-1)(q-1). Then we know p and q satisfies x^2-(p+q)x+pq=0. You could solve this quadratic equation using quadratic formula to get p and q.
Adding some more related articles. this was mostly a result of me trying to find some more useful articles to better understand and it was lost in my browsing history.
>What if, instead, we take a position that rather than enhancing components, we replace them. Then the best way to know when something needs to be replaced, is when it doesn’t do what it says on the tin.
This is something that I have had trouble reaching a balance. Replacing components could be costly and therefore it makes sense to design components that are extensible (and seem over engineered) especially when the requirements aren’t known completely? What are your thoughts on this
Not the author, but I'd prefer rewriting the code as the requirements become clear rather than building something unspecific. In my experience the benifits to code reuse are vastly overstated and the costs of added complexity vastly understated.
You've replaced a "could be costly" (rewrite if we need to) with a always costly (over engineer for expansion).
Also, when you don't know the requirements completely is the prime time to do/write as little code as possible. You can't know future and guesses are more often wrong.
You should really push back on teams managers that ask you to write code without telling you what that code should do.
Learned over 25+ years of professional dev xp. Coding for 39yrs.
Thanks @njharman , how does one consider between rewrite vs expand when it is known that some requirements will be true not for the current release but 2 or 3 releases down the line. Would you still prefer rewrite vs expansion? The reason I ask is I got severe pushback recently where I proposed building generic enough components and infra to go along with it that could have satisfied the requirements for the next 2 or 3 releases
In my experience, reality is unpredictable enough that no one actually know what the requirements will be two versions down the road. In practice you end up with code that is more complex than what the current problem needs, trying to solve a future need that you presume will happen but you don’t really know what it is and when it will happen.
