Skip Navigation
InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)NP
nigel_peters @lemmy.nz
Posts 0
Comments 5
Will we see mass adoption of Apple Vision?

  • I'm pretty sure I'll be getting one, but then again I'm an iOS developer and will likely be playing around with developing apps for it.

    I can definitely see myself using this in the (home) office and around the house. Purely for productivity this looks like it'll be amazing

    •
    What does your merge/code review process look like?

  • Yeah it's probably one of our more hotly discussed issues at eng. catch-ups. A few newer starters come from more startup backgrounds and find it super frustrating.

    Pros & cons as with any process 🤷

    •
    With feedback from the community and internal discussion I present the final iteration of the new Mlem icon!

  • This is cute af. I love it

    •
    Modest Mouse - Float On

  • I love this song. I never really checked out any of their other stuff though

    •
    What does your merge/code review process look like?

  • Ours is pretty intense - large bank, 60 or so iOS engineers actively contributing to a mono-repo:

    1. We have about 15 CI steps that pick up on anything from basic linting to security concerns (SonarQube). Unit tests, UI tests, etc.
    2. We have a template that PR authors follow to add descriptions, test plans, devices tested on.
    3. Reviewers are automatically assigned using a round robin system
    4. Reviewers obviously review the code, but also execute the test plan, which includes accessibility testing.
    5. All PRs require 2 approvals.
    6. A bunch of other stuff (uploading artefacts, generating gRPC protos) that probably isn't worth going into detail.

    It's intense, and PRs on average take a week or so to get merged. In saying that, it is the highest quality and most well-architected codebase I have ever worked on.

    If I were in your situation I'd push for the following:

    • all PRs have one approval, preferably two depending on team size
    • code is tested by someone else before being merged to main
    • use linters, Danger, etc to pick up on trivial shit
    • a few manual checks like ensuring code is unit tested
    • a Github PR Reviewer guide describing common issues to look for, tone of messaging when leaving comments ("be nice", "make it clear when you are adding optional nit-picks", etc)
    • encourage authors to add review comments to their own PRs for any bit of code that isn't immediately obvious
    • stretch goal: look into generating code coverage reports on your PRs, add quality gates