Preface
Previously I've written about how to develop "like a pro" on Windows with various tips and tricks about how to get your work optimized and solve common problems. Then I wrote Aperture Control to automate some of the common setup tasks for Windows.
Standard development environment for Windows
Now, using Aperture Control and based on the tips, I've set up a repository to configure what I could consider a fairly standard development environment for Windows.
It's trying to not be too opinionated, but provide a good base to start from, and suggest some tools and configurations not everyone might be aware of yet that can significantly benefit a lot of developers. Most of all, it's aiming to be easy to take into use and customize as you see fit.
There's all kinds of things from package managers, programmer fonts (DejaVu), CygWin, placeholders for autorun cmds, to configuring local bin folder similar to ~/.bin a lot of *nix users have set up and configuring some sensible defaults for Windows and e.g. Git.
Usage should be simple: Fork / otherwise clone the repository, tweak to your liking (e.g. based on the recipe collection), and run on the machines you want to keep synced with your settings. When you have an update to make - push it to the repo and it will be automatically updated to your other machines as a scheduled task checks for updates hourly.
Discussion topic
What do you think should and shouldn't be part of a standard development environment? What are you missing, what do you not want "poisoning" your machine?
Any good practices you've come up with your folder structures, or settings for Windows or other software that you'd like to share and see spread?
Do you have a wishlist for things that you'd like to still see while developing in Windows? Maybe someone else knows how.
My personal wish: getting my terminal to support emojis and other such things properly. I like writing scripts that output 👍 for success and 😢 for failure, yet I just end up with various rectangles and other such things on my screen when I try to use them. The beta UTF-8 support does not seem to really help, and causes some additional issues for me as well.
Top comments (3)
I'm not really sure how this would work, because your idea of "Fork / otherwise clone the repository" relies on some kind of basic system being installed already, like WSL or Git Bash (full disclosure, I've never used Git Bash but people go on about it like it's good).
After that, everything that's standard on other OS will (should) work the same way, and everything that's Windows-specific will need a whole different kind of installer.
Well, you should maybe read the usage guide then.
Of course you can't just write a set of scripts to install any OS, be that Linux, Windows, or anything, without any tools. If all you have is a terminal prompt with no internet access, and no editor installed, it's gonna be tough to write a script of scripts to GitHub.
I have no idea why you would assume WSL, or Git Bash would be in any way manner or form necessary for any of this, or what you're on about "other OSes", this is a tool for Windows and is pretty much completely unusable for Linux or others, and their tools are not particularly useful for Windows because Windows does not run them by default and they have no understanding of e.g. Windows registry. I created a tool that can take your fresh Windows installation from the first time you log in, to having all the tools you want in it, with much of the configuration already done, with one copy & paste to a PowerShell terminal.
What you do is, using your existing working environment that you write your dev.to comments on, you set up the repository with the configuration for how wish your machines to be, and then run the commands on the machines you want configured. This works both for making changes on your currently running machines, by giving you access to tools that weren't as easily available before, some sensible defaults, as well as a backup for your settings for whenever you eventually happen to need a reinstall or new hardware.
It also works especially well when you have a number of machines that you'd like to sync up, as you just have to push your changes to the repo and they will get applied on all your machines.
The initialization commands do not depend on any kind of WSL, Bash, Git, or anything else than plain Windows PowerShell, and can configure a large number of things and save a lot of time even when you have an existing working setup.
The basic usage information is at github.com/Lieturd/aperture-control
List of premade "recipes" for things that you can easily automate with it are available at github.com/Lieturd/aperture-contro...
Btw this "standard environment" basically would already work out of the box, and doesn't need you to do anything but run the commands - though you shouldn't because of the reasons mentioned in the repo.
Forking on GitHub is about 1-2 clicks, and that's all you need to make it your own and safe to use.