Honestly, the mac approach makes much more sense from an ease of use perspective for non-experts. On other platforms, you have to know the layout to choose and hope things work until you do or have a second keyboard that's close enough tl the default to get by. On Mac, it just figures it out based on the information you tell it when the keyboard is connected. Much less error prone in the majority of cases.
yeah, this is no go. What you want is a way for the cat to be in a box front and center. So an underdesk keyboard tray that doesn't have room for a cat to sit on, but is big/deep enough for your hands, keyboard, and mouse and a "box" on the desk proper that the cat will naturally gravitate too. Of course, this works best with desktop machines or external monitors and keyboards instead of just a laptop.
There are a number of cases where this is not really possible. For some classes of updates, the structure of the underlying application and the type of update being made requires that you do an "all or nothing" type of update in order to get a buildable result. I've run into this a lot with Large Java applications where we have to jump several Spring versions just due to the scope of what's being updated. More incremental updates weren't an option for a number of time/architectural reasons and refactoring the application structure (which really wouldn't have helped too much either) would have been time and cost prohibitive... Really annoying but sometimes you just don't have another option to actually accomplish your goals.
My experience with AI code reviews has been very mixed and more on the negative side than the positive one. In particular, I've had to disable the AI reviewer on some projects my team manages because it was so chatty that it caused meaningful notifications from team members to be missed.
In most of the repos I work with, it tends to make a large number of false positive or inappropriate suggestions that are just plain wrong for the code base in question. Sometimes these might be ok in some settings, but are generally just wrong. About 1 in every 10~20 comments is actually useful or something novel that hasn't been caught elsewhere etc. The net effect is that the AI reviewer we're effectively forced to use is just noise that get's ignored because it's so wrong so often.
This is something I've noticed on academic vs "practicing" coders. Academics tend to build in layers, though not always, and "practicing" coders tend to build in pipes give or take. The layers approach might give you buildable code, but is hard to exercise and run. Both approaches can work though, especially if you build in executable chunks, but you have to focus on the smallest chunk you can actually run.
This is actually what I'm talking about .. Why do I need a whole new python environment rather than just scoping the dependencies of an application to that application? That model makes it significantly harder to manage multiple applications/utilities on a machine, particularly if they have conflicting package versions etc. Being able to scope the dependencies to a specific code base without having to duplicate the rest of the python environment would be much better than a new virtualenv.
This is still a complete pain to work with. Virtualenv in general is a "worst of worlds" solution. It has a lot of the same problems as just globally pip installing packages, requires a bit of path mangling to work right, or special python configs, etc. In the past, it's also had a bad habit of leaking dependencies, though that was in some weird setups. It's one of the reasons I would recommend against python for much of anything that needs to be "deployed" vs throw away scripts. UV seems to handle all of this much better.