![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/8140dda6-9512-4297-ac17-d303638c90a6.png)
I don’t see why you need a separate builder when you are trying to build the app, even if the app is a third part thing you can still build it as part of the final method. Assuming there are no other options needed.
I don’t see why you need a separate builder when you are trying to build the app, even if the app is a third part thing you can still build it as part of the final method. Assuming there are no other options needed.
And cherry-pick commits done on different work trees without syncing them first. Or rebase or mergeworkk done on one work tree with others. Or check commit logs or diff them.
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.
I have never had git get into a state I cannot get out of. Even if that is a reset, checkout or clean. And those are very rare. How are people breaking things so often.
Learn the tools you use daily, it saves you a lot of headache in thelong term.
Where did you get that from?
https://small-modular-reactors.org/smr-cost-estimates/ suggests the opposite:
$2,000 to $6,000 per kilowatt for SMR vs $4,000 to $9,000 per kiliwatt for large scale ones.
Plus they don’t take 10+ years to build, and each one is not a bespoke construction leading to better scalability as the more you can build the cheaper things become.
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).
That assums the file is not stored on a writable section of the filesystem and treated as application data and thus wouldn’t survive a rollback. Which it likey would.
Nixos still let’s discord and steam download their core files independently of the configuration. These get stored in the users home dir but are effectively not part of the immutable promise. I believe that the crowdstrike problem was caused by a file updated in a similar manor. So would have been an issue on any distro. That is one big problem with a driver relying on files outside the package managers control. At least with steam and discord they cannot take your whole system down.
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.
Redhat have done a lot for Linux in the past. And that will likely continue for some time yet. But they have done some seriously questionable things ever since IBM bought them out. I don’t like the direction they seem to be heading in as withmany of IBM products.
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.
You lose information when DST kicks in - which is not great. It is trivial to convert to any timezone so there is little point in logging in anything but UTC and keeps everything consistent. Especially when comparing dates from servers in different timezones.
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.
The first actual sentence in the article clears that up.
Schools will be told not to teach children any form of sex education until year 5, when pupils are aged nine, according to reports, with some topics being delayed until pupils are 13.
Though that could have been the title and tagline…
(I don’t know why jamstack has taken over that site, but the list itself seems to be intact.)
Not really taken over, more just a rebranding. Both are owned by netlify, started off as a list of static site generators you could use with netlify (aka all of them they could find) but then they just rebranded the site and gave it a fancy name like you have with all the other web stacks you have these days.
It is a digital signage display (ie in store ads, menus, displays etc) - not meant for desktop use.
I think their though process is more along the line of:
Hey, Microsoft is getting all the bad attention ATM, let’s see how much shit we can sneak in while people are distracted.
That should not break things though. Maybe get a merge conflict that you need to sortout at worst. This is essentially the constant state of working with other people on a project.