• 0 Posts
  • 461 Comments
Joined 1 year ago
cake
Cake day: June 17th, 2023

help-circle



  • The basic idea behind the builder pattern is to ensure the main thing can only ever exist in a valid state, no half valid values letting you call things in weird ways that break.

    Here AppSettings is not the thing you care about, the App is. So you can think of AppSettings as a builder for the App. A final call to it should construct a valid App and you should not be able to do that when the settings are invalid.

    If there are one or two required fields the having those on the new method of the AppSettings or the final build method that constructs the app is a good approach. If there is a set order things need to be created in then the generic state pattern or multiple structs can be used instead to limit what functions are available at each stage.


  • I have started using work trees recently as well, but have a different flow to the author and everyone else. I typically use two work trees, one on main that I do all my work on. That is work and create commits directly on the main branch.

    But then to push I have another clean work tree that I use to create and switch branches on then use that to create working sets of changes by cherry-picking from master into different branches to push and create PRS from. And never edit files on this work tree so that I never have to stash anything.

    Then just git pull --rebase=interactive origin/master to remove merged commits from master as they get merged upstream. This let’s me build on pending PRs or switch to other tasks at will and just sort them into separate PRs as required.

    I like this as when working on a feature I often find a refactoring I need to do, so can isolate that refactoring and create a PR with only that change while continuing to work on the feature on top of the PR.

    Or have some temp debugging stuff locally that I want to use across changes that will end up in different PRs without having to copy paste them between branches.




  • Ideally yes. All core files would be handled by nixos. Except I doubt that is how crowedstrike would work on nixos if it existed on nixos.

    Crowedstrikes downloads and manages it own definition file that gets updated multiple times per day. It is this file that was malformed causing the driver to break. This needs to be updated regularly, more then other packages and so would very likely not be something managed by nix package manager but more treated as application data and outside the scope of the nix package manager.

    This is how updates to steam and discord are handled in nixos. Only the core updater is packaged and the rest of the application is self managed. So there is a precedence for this behaviour on nixos (although these won’t break your system if a bad update happens as the files are in your user dir).




  • You don’t share code between monorepos, the whole point of a monorepo is you only have one repo where all code goes. Want to share a library, just start using it as it is just in a different directory.

    Submodules are a poor way to share code between lots of small separate repos. IMO they should never be used as I have never seen them work well.

    If you don’t want a mono repo then have your repos publish code to artifact stores/registries that can be reused by other projects. But IMO that just adds more complexities and problems then having everything in a single repo does.



  • nous@programming.devtoLinux@lemmy.mlNot really sure I get Wayland
    link
    fedilink
    English
    arrow-up
    13
    arrow-down
    2
    ·
    18 days ago

    Closed source drivers are not really the issue. But competing graphics APIs are. With the move to Wayland open graphics drivers were updated to support the GBM graphics API which if one window manager wants to support then it gains support for all graphics drivers that use that api. But nvidia created its own api, eglstreams that to support required all window managers to write extra code for. Some refused to do that or took a long time to do.which gave shoddy nvidia support.

    Some did support nvidia slowly, but then nvidia also switched to support the same api as everyone else (poorly at first but I assume it has improved over the years). Nvidia have also partly released their drivers as open source which has also helped.


  • Your battery drains more the more you activity use the device. Shocking…

    If it is your phone just uninstall those apps, then you cannot use them. If the devices main point is those apps like gaming on the switch what do you expect? I think the only real problem here is the switch’s lack of customizability so you have no trade off between game quality and battery life like you can on something like the steam deck.



  • So, if you just use the system API, then this means logging with syslog(3). Learn how to use it.

    This is old advice. These days just log to stdout, no need for your process to understand syslog, systemd, containers and modern systems just capture stdout and forward that where it needs to do. Then all applications can be simple and it us up to the system to handle them in a consistent way.

    NOTICE level: this will certainly be the level at which the program will run when in production

    I have never see anyone use this log level ever. Most use or default to Info or Warn. Even the author later says

    I run my server code at level INFO usually, but my desktop programs run at level DEBUG.

    If your message uses a special charset or even UTF-8, it might not render correctly at the end, but worst it could be corrupted in transit and become unreadable.

    I don’t know if this is true anymore. UTF-8 is ubiquitous these days and I would be surprised if any logging system could not handle it, or at least any modern one. I am very tempted to start adding some emoji to my logs to find out though.

    User 54543 successfully registered e-mail user@domain.com

    Now that is a big no no. Never ever log PII data if you don’t want a world of hurt later on.

    2013-01-12 17:49:37,656 [T1] INFO c.d.g.UserRequest User plays {‘user’:1334563, ‘card’:‘4 of spade’, ‘game’:23425656}

    I do not like that at all. The message should not contain json. Most logging libraries let you add context in a consistent way and can output the whole log line in Json. Having escaped json in json because you decided to add json manually is a pain, just use the tools you are given properly.

    Add timestamps either in UTC or local time plus offset

    Never log in local time. DST fucks shit up when you do that. Use UTC for everything and convert when displayed if needed, but always store dates in UTC.

    Think of Your Audience

    Very much this. I have seen far too many error message that give fuck all context to the problem and require diving through source code to figure out the hell went wrong. Think about how logs will be read without the context of the source code at hand.