• 13 Posts
  • 2.04K Comments
Joined 3 years ago
cake
Cake day: July 7th, 2023

help-circle


    1. How many grep-like ops per file?
    2. Is it interactive or run by another process?
    3. Do you know which files ahead of time?
    4. Do you have any control over that file creation?
    5. Is the JSONL append only? Is the grep running while the file is modified?
    6. How large is very large? 100s of MB? Few GB? 100s of GB? Whether or not it fits in memory could change the approach.
    7. You’re using files, plural, would parallelizing at the file level (e.g. one thread per file) be enough?
    8. How many files and how often is that executed?





  • that assumes

    1. the user does have access to a production db;
    2. the agent has access to a terminal from which they can reach the production machine (not in a container, different network, or similar);
    3. access does not require interaction (like entering password);
    4. the agent deliberately decides to access a production database to solve a development problem, and that was not the user requesting it;
    5. the agent manages to find the database credentials in production;
    6. the agent is left unattended.

    Possible? Sure. It’s also possible that I drink half a bottle of vodka on a Friday night and mess up with production.




  • I’ve never worked on a codebase where using ORMs wasn’t better than rolling your own queries. What are people writing that they actually need the marginal performance gains? And even if that’s worth it, why not just use raw queries in your critical paths?

    Every time I have to write or modify raw SQL it feels like I’m throwing away all my static checking features and increasing the chance of bugs, because I have no idea of the query matches my schema or if it’ll blow up at runtime.


  • I’ve done it quietly 4y ago, only told some closer relatives. It was kind of funny when relatives I wasn’t talking to told my closer ones that we were keeping in touch on WhatsApp, not even aware I wasn’t in the platform for over 6 months at that point.

    Now after years and leaving 2 family groups, politics, and a whole lot of drama behind, I feel it was a great decision, and the only regret was not doing it earlier.





  • The way I see it, for any code review there are going to be different levels of recommendation regarding the comments. When I review, I try to make it clear what’s optional (/ nitpick) and what I’d really like to see fixed before I can approve it.

    So even making some assumptions, I can’t choose between 4 and 5 because optional and “less optional” changes are often in a same PR.

    The only one I haven’t done much of is #3. That one looks better if one has questions about code that was already reviewed, merged, and it’s likely in production.


  • As with a lot of things in life, it depends.

    I use 1-5 depending on the repo, who made the change, what the change is about, and how involved I am in the project.

    Though the “time-frame” idea of #4 is usually replaced by conversations if it’s a coworker, as it’s more effective.

    Q: about #3, do you mean on code that is already merged / committed to the default branch?