Although it goes against certain opinions AND if you set a norm for their use, signals are the way to go.
You can either decide that signals code will live in the app where the objects reside or the app of the target objects and that's it. A built-in and simple interface between objects.
I've decided to play it simple albeit "old school" (because Docker seemed to add its own set of headaches - also not every project needs to do micro services or work with clusters or scale):
- Vagrant (so you don't have to worry about runtime executables) with the stack matching that of the production server (you can even ask ops to provide you with the provisioning script and remove the parts that you don't need - otherwise learning to provision your dev. VMs won't hurt you)
- Virtualenv
- pip
Then simply point your IDE (I only use Vim under duress) to the remote Python interpreter (the one you installed in the Vagrant VM).
It does add processing overhead but it worked with my 2010 MacBook Pro until it died and still works (only ten times faster) with the 2016 model. Your only limitation would be the RAM (I would recommend at least 8GB and if you plan to run multiple machines communicating together as much as you can afford - I do believe that Docker has less overhead, but again, for my use, not needed).
The best practice is what works for you, not the latest trend.
Does Duckduckgo makes a browser now? Or do you mean that like most of non geeky folks you access websites not by typing an url in the address bar of a browser but instead by going through a search engine (in this instance Duckduckgo)?
Because the I/O performance sucks, there's an AV process that goes haywire whenever anything is compiled, the terminals suck, I've not found a non-bad way of SSH'ing into WSL remotely, it's about as clunky as using Wine on Linux some years ago, there's spyware and ads on the enterprise install of Windows 10, software I can't remove by using the tools to remove all other software (installers for Office and the like), but above all, when I'm running the NT kernel, it's mostly to run software that only runs on the NT kernel. I've not run NT on bare metal in a while, but looking at the struggles of people around me, I don't intend to in the near or long term.
It is its own silo on Windows. Yes, it is native from an implementation standpoint, but does not play well (yet) with the rest of the Windows environment.
Install Visual Studio Code, the usual Windows version.
Explain to VS Code that it is really a good idea to use the Linux subsystem as its command-line environment. Not only interactive sessions like Bash on its integrated terminal, but also for git, compilers, Node, etc.
Once you have got that set up and your development workflow going ok, try setting up the same on Linux or macOS.
Which one would you prefer?
The Windows Subsystem for Linux is brilliant. PowerShell is brilliant. The dotNET universe can be brilliant.
I'm in exactly the same situation. I just wish it had coffee lake, 32gb of ddr4 and a modern gpu - e.g. an upgrade. Who cares if it's marginally thinner and lighter?
With Ubuntu 18.04, Linux is more usable than ever... already runs my desktop and I'll be switching my laptop to Linux as well unless Apple releases something more suitable for power users this summer.
My beloved matte-screen 2011 17-incher failed unrepairably a couple of months ago. I decided to get a new 2017 15-inch model rather than take my chances getting another 17-inch one off of eBay. I had read lots of complaints about the keyboard, so I was prepared to possibly hate it, but it's okay, though not quite as good as the old one. The Touch Bar and larger trackpad seem like gimmicks to me. Well, the Touch Bar has its moments of usefulness, but against that, I hit it accidentally too often, and it's sensitive to the slightest touch.
Overall, I'm not unhappy, really. It is faster than my old one was, and much lighter, and has better battery life as long as I'm not doing anything CPU-intensive. Would I have been happier with the older 15-inch model they're still selling? In retrospect, I don't think I would have been any less happy, and I would have saved some money.
>Smaller but hi-dpi, and with far greater color accuracy and brightness. Also, you can hook up an external monitor, apparently lugging 17" beasts around wasn't popular enough to carry the models forward.
Size on the screen does matter, I'd rather the screen do the work than my eyes.
With a 17 inches I don't need to hook up an external monitor. I am able to work at full proficiency anywhere.
>Actually way way more. Less varied ports (basically 2 types: 4 USB-C and 1 headphone), but way way more I/O power and connectivity.
If you don't mind paying for and carrying around a dozen dongles. Also no ethernet port. And you're forgetting about the ExpressCard slot...
You can either decide that signals code will live in the app where the objects reside or the app of the target objects and that's it. A built-in and simple interface between objects.