This is not something that a unit test can catch. First, this 100% coverage rule applies to the program/library code, and only to the subset that is not ifdeffed out (otherwise, you will not be able to have, e.g., Windows-specific code), and definitely not to the build system's code. Second, how would you test that landlock works, in a unit test, when this feature is optional and depends on the system headers being recent enough? You can't fail a unit test just because the software is being compiled on an old but still supported system, so it would be a "SKIPPED" result at best, which is not a failure and which is not normally caught.
The proper way would be to have a minimum glibc version (or whatever it depends on) where you expect landlock to be available and then shout loudly if it is not so that you can either fix the check or correct your expectations. This isn't just for malicious users, these checks can be brittle enough that a small change in the library or even compiler update can occasionally break something. Of course this is ideal and does not match common practice. I can't even claim of doing this consistently myself although I did start that practice before this mess.
PG has “copy” which would blow away bulk inserts. Other DB vendors have similar stuff for high-performance inserts. You would be much better off using those than using bulk inserts.
Valuations are straightforward in a world without corporate actions like splits, consols, dividends etc.
Most (all?) data providers rerate historical prices after corporate actions that affect prices and this is not really the correct way to do continuous valuations using the restated prices.
Some of them allow you to view adjusted vs. current pricing. Some of them also leave it up to the user to figure out if it's adjusted, so it does take some homework to figure out at times.
I didn't say we should ignore splits. To reiterate: most third-party data providers include splits by restating historical prices. This only works if you want to analyse performance at individual stock level by ignoring holdings. But if you want to do performance analysis for your own portfolio of stocks, relying on restated prices is incorrect.
Eg.
If you bought say 10 stocks at the old price, you cannot take the restated historical price with your 10 stocks and you cannot take the units held of 10 stocks with the new prices. You have to account for this via transactions to increase your holdings (for splits) by leaving the prices historically the same.
ORMs and NoSQL were a direct result of the desire to have an object-oriented data worldview in a programming landscape dominated by OO languages. They were not introduced because programmers didn’t want to learn SQL (implying incompetence etc).
LOL. I'm not sure what you mean? He called me up on the phone and asked if I wanted to buy a lot of Beanies. When I went to meet him at his house it was obvious he was legit. I only paid cash on delivery. I got whatever sealed boxes I got. He didn't have the ability to pick and choose which pallet I got and I don't know if we ever figured out what was in each box from the outside.
