Squash-merge PRs. You can configure this in GitLab, GitHub, and Azure DevOps. Your private commits can be whatever you want and they get rolled up to a single PR commit when your working branch is merged to trunk.
"Every commit is deployable" isn't at odds with merging multi-commit MRs, provided that the submitter actually did their job well. I find squash-merging to be an ugly workaround, not a proper solution. Good non-trivial merge requests should usually consist of multiple commits that improve readability, revertability, cherry-pickability and blamability ;)
Native interop in .NET has always been via what they call "P/Invoke". On .NET Core, P/Invoke is cross-platform and you can also call .so/.dylib functions on Linux/MacOS just like you could always call .dll functions on Windows on .NET Framework before we had .NET Core.
I'm curious to know what you needed to do with native libraries. I've been programming with .NET around 20 yrs and find it fairly rare that I need to use P/Invoke... But I'm sure it depends on what you're building.
I maintain a thingy written in C# that does cool things with keyboard backlights on System76 machines in Linux. Like make the left-third respond to CPU usage, right third blink when you have unread notifications, etc. The biggest one was turning off the keyboard when the screen blanked[1]. Almost all of the fun stuff requires native interop.
You end up using P/Invoke any time you need to control hardware. In the last few months I needed to use P/Invoke to control cameras, motors, and compute FFTs with the GPU.
You need to use them if you need to control raw GDI objects like bitmaps.
From what I've seen, the biggest issue here is that you cannot transfer purchased Google Play Store purchases. Even without the G Suite thing, this is a problem.
For example, I have a fairly unprofessional primary Google account that I created when I was young and dumb(er). I would like to transfer the hundreds of dollars in purchases I've made under that account to another, more appropriately named, account but it does not seem possible.
They could solve this part of the problem for the affected G Suite deprecated users as well as people in positions like me by having a way to do this.
My understanding now is that even if you let the forced Google Workspace account lapse, the underlying accounts will continue to function as Google Accounts. You will not have access to Email, Documents, Photos, Calendar, etc. but you will still be able to login to Google and use Play Store purchases.
In my mind, "consulting" is knowledge work. Your role is to lend knowledge and expertise, help with strategy, architecture, tool/platform selection, etc.
"Contracting" is high-skill grunt work. Your role is to code your fingers off, deliver-deliver-deliver, typically according to someone else's (possibly ill-conceived) plan.
The former is an activity and the latter is a business relationship, so they're orthogonal. Many consultants are contractors but not all are. Many contractors sell consultancy but not all do.
You got the types of consulting right, but the terminology wrong. Yes, one type of consulting is lending your expertise, another type is lending a pair of hands. Either of these types of consulting work can occur under "contracting", "freelancing", or other types of business relationships. Often a "pair of hands" consult is hired "until further notice", so it's not always contracting.
> "Contracting" is high-skill grunt work. Your role is to code your fingers off, deliver-deliver-deliver, typically according to someone else's (possibly ill-conceived) plan.
Not at all. Contracting, in itself, is just the business agreement but most of the time contractors are experts and have plenty of autonomy.
No, you've got the distinction right. Many folks don't understand that difference. Many consultants crank out a lot of code, but they also do advising, planning, recommending, analyzing,...
I understand what you are trying to say but it is also a form of master-slave dialectic, you don't like something and feel above it and try to organise your social life with strict rules to isolate you from it. It's not even always a bad thing to do, like I an a coder who tries to avoid working with people who think like you.
From what I've read, the Koch method combined with Farnsworth timing is the best way to learn to hear Morse code.
Koch method is about using full-speed dits/dahs from the beginning and gradually adding a couple to the set of characters being trained as you learn to identify them by their sound.
Farnsworth timing is about controlling the overall speed by putting pauses between the characters while training instead of slowing down the dits/dahs of the actual characters.
I don't know the science behind it, but I've spent a few hours training this way. Each set of tones that makes up a character starts to sound like its own word, or phoneme at least. It feels like it's stimulating the subconscious language bits of the brain rather than the logical/conscious ones as if you tried listening and counting the dits/dahs.
It's better than nothing, but one of the values of UUIDs for identifiers is that you can create new ones client-side while offline. These "sequential" UUIDs will fail standard UUID validation because of the byte swapping and, in my experience, when used offline-capable apps, will result in sparse clusters of sequential UUIDs that yield an unpredictable improvement over truly random UUIDs.
I think it depends on if you see the browser for content or as a runtime environment.
Maybe it depends on the application architecture...? I.e., a compute-heavy WASM SPA at one end vs a server-rendered website.
Or is it an objective measure?