• 3 Posts
  • 114 Comments
Joined 1 year ago
cake
Cake day: October 6th, 2024

help-circle



  • I agree, storing in a consistent unit is the way. That doesn’t solve conversion/rounding issues, but it does simplify things.

    Though you can run into floating point errors when editing in one unit vs storing in another. For example, maybe the user entered 2 in unit A, then it’s converted to unit B and stored in the db. However, when it’s converted back to unit A, it’s 1.999999. Fortunately rounding fixes this. We say unit A and B get 2 decimals of precision, and 1.999999 becomes 2.00.


  • You think timezones are annoying? Try handling metrics that use imperial and metric, need to be rounded to different precisions across a large system, and are sometimes recorded in a different unit than it’s viewed in. Slap some floating point error on there, and you got yourself a fun time.

    I spent all day working on bug where backend was categorizing 19.9999 as falling between <20, but frontend was rounding it to 20 and categorizing it as >=20.

    Edit: just to be clear, I don’t really think this is more difficult than date/time. But it does remind me a lot of solving date/time issues.















  • I don’t think this will work within the context of a feed of posts. You would have to make at least 1 additional comment for every post in the feed to fetch the comments for a post. So if you fetch a feed of 50 posts, you will have to make 51 requests. If a post has too many comments to fetch in one page, you will have to iterate through all the pages until you have all the comments. So it’s actually >=51 requests. Though I suspect you could get a good idea of a posts comments by fetching just the first page of comments.

    PieFed seems to have tags, but I’m not exactly sure how they work. But that might be a better place to start.