soren1
At the time, I recall finding one or two tools on GH, none of which seemed suitable. There was also a 3rd party service for calculating tax which integrated with exchanges, but it didn't sit well with me for privacy reasons.
Eventually I felt I had no choice but to build a tool to calculate capital gains from an input CSV of transactions. I wanted to keep it simple, so it puts the burden on the user to download transactions from exchanges and get them in the correct format, which it then processes.
I finally submitted some very late tax returns, and the tax office was kind enough to withdraw the late interest penalty after I explained the effort involved.
It was still a lot of work aggregating trade histories from various exchanges into a standardized schema, but I took some comfort in understanding the process. I also avoided the need to share exchange API keys and trading data with 3rd party accounting tools.
If you discover any bugs, please don't tell the tax authorities.
In my recent experience working with collections containing million of documents, each containing a geoJSON-style polygon/multipolygon representing a property (i.e. a block of land), I found invalid geometries to occur for about 1 document in 1 million. For a while, I suspected the data-vendor was the cause, however it became more puzzling when other geospatial software confirmed they were valid. Eventually we traced the issue to the 2d-sphere index.
A very clever workaround was suggested by a colleague of mine, inspired by [1]. It preserved the original geometries. In each document, we added a new field containing the geometry's extent. A 2d-sphere index was then built on the extent field instead of the original geometry field. Invalid geometries were no longer an issue since we were dealing with much simpler geometries that were substantially larger than the max precision of the index.
When running geoIntersects queries on our collection of millions of documents, we did so in 2 steps (aggregation queries):
1. GeoIntersects on the extent field (uses the index).
2. On the result set from the last step, perform geoIntersects on the original geometry field (operates on a much smaller set of records compared to querying the collection directly)
[1] https://www.mongodb.com/docs/manual/tutorial/create-queries-...
Specifically regarding cold starts of lambda instances, I recall this excellent article from Jan 2021 which measures cold start latencies for a variety of AWS lambda runtimes:
https://mikhail.io/serverless/coldstarts/aws/languages/
I would love to see a 2022 update.
I've seen others (and have myself) supported costly features of questionable value. Sometimes a few conversations with product managers and customers have resulted in us entirely dropping a feature.