This is a blog that I have posted on a few other sites, but I think it deserves a space here too.
I recently completed a web development boot camp. This is not an uncommon occurrence, nor is using a Windows machine to do it. In my case though, I was using a Windows machine in a Mac centric environment. All of the instructions for installing programs were done with the assumption that everyone would be using Mac. The instructors had, for the most, part done their work using Mac. Therefore, I was going to be mostly alone while performing my troubleshooting. That is why I decided to write about my experience, plus a suggestion from the instructors, so they can send the next Windows user somewhere to help them with issues. This is specifically written with General Assembly Web Development Immersive programs in mind.
My background has always been in Windows. I was working tech support before starting the boot camp, and this was almost entirely focused on Windows, with some Linux thrown into the mix. This work would sometimes require using the command line on both Windows and Linux, so I know my way around the file system. I am also a seasoned PC gamer, and have built six computers over the years, not to mention countless times replacing parts. With my extensive experience with troubleshooting, I was confident using Windows was going to be fine for me.
To start, I will talk about the applications I decided to use that will allow the use of Linux commands, then I will go into the applications needed for the course, and finally I will cover a few other issues that I ran into during the course. This information is going to require that you are using Windows 10, as some of the tasks we are going to go through can only be done on that OS.
First things first, you are going to want to get into the habit of running everything from the administrative command prompt. To do this, right click on the command prompt, hover on more, and choose run as administrator. The other option is to do a search from the start menu for cmd, hit CTRL SHIFT ENTER. You will be able to perform some tasks without doing this, but others will require administrative privileges.
The first thing that I found out about in my research was that you can install a subsystem of Linux on your machine. This is not a dual boot, and will not have the functionality of a full Linux distribution, but will be enough for getting you through your course. This is called Windows Subsystem for Linux, or WSL. We are going to install this using the Microsoft documentation.
- Open Windows PowerShell, You need to enable the feature before installing any Linux distro.
- From the start menu, type PowerShell, then right click on it, and run as administrator
- From PowerShell, copy and paste the command
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
If you didn’t run as administrator, this command will fail, telling you that you the requested operation requires elevation.
This can also be done through Programs and Features in the Control Panel. Then click on the Turn Windows features on or off submenu. Then find Windows Subsystem for Linux and click the checkbox.
You will be required to restart your computer.
- From the store do a search for Linux.
- There should be a banner that will take you to the Linux apps.
- Choose whichever distro you want, I chose Ubuntu.
- Launch the app when the install is complete.
- You will be asked to enter a username and password. That is all it takes to install Linux
As I said earlier, this is not a full Linux install, but this will allow you to run some Linux software on your Windows machine pretty seamlessly. You will also be able to run a handful of commands from the Windows command line by prefacing the command with WSL. For example, pwd is the Ubuntu command to show the current directory you are in, it is not a valid Windows command, but if you do wsl pwd it will show you the directory, from the Linux root.
The Linux files are located in a directory in your profile path. You can access this directory without going through Linux, but it is not recommended, because if you are not safe, you can cause issues to the OS. That being said, it might be necessary. If you have a .js or .html file, you could open it from Windows or Linux. What if you are trying to get something off of a USB drive into the Linux files? You would need to be able to go Windows file system.
To get to Linux files from Windows C:\Users\NAME\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs
To get to the Windows files from Linux, you need to go to the mnt directory on the root. In there will be the drives located on the computer, using their letter association that has been assigned by Windows /mnt/.
While this is a great feature that can be extremely useful, I didn’t use it for much. This is due because Windows doesn’t support using Linux graphical applications from Windows, so there was a lot of moving through the file systems. There are things that you can do if you want to run Linux graphical applications. You can start by checking the links below. That being said, I would still install it, because it was helpful for a few things later on during the course.
Git for Windows
The more useful product throughout was Git for Windows. This provides BASH emulation that allows Git, as well as some more common Linux commands, to be run from the command line. Go to the Git for Windowssite and download the installer.
Run the installer, choosing the defaults most of the way through. When you get to Adjusting your PATH environment, choose the option to use Git and optional UNIX tools from the Windows Command Prompt.
This will allow you to use the default Windows command prompt for most of the work you will do in this course. It adds the common Linux commands (pwd, ls, touch, and others) as recognized Windows commands. PATH is an environmental variable that allows for the command prompt to open a program without typing out the whole path. For example, to open VS Code from the command prompt, you can just type -code- otherwise, you need to type out the complete path to the executable file. This will not be the last time that we see this verbiage, in fact we will manually add a few things later on. Finish the install with the defaults the rest of the way. If you had the command prompt open, you will need to close it for the new commands to be recognized.
WSL and Git for Windows were vital programs to have during this course. Next we are going to go over the installation of some of the programs that you will need to have for this course.
Installfest is the task that installs all of the applications that will be needed through the class. There is a command to run that will connect to the schools server that will install all the required programs, but the reason for this writing is again because this command is only useful for Mac users. You will want to follow the Linux link, this is because this is just a list of what you will need to install. From that list you will be able to download install files from the respective websites. There may be multiple programs that want to restart the computer, it is safe to wait until all have been installed and just do one restart. After all the programs are installed, you can go back to the default Installfest page to follow the GitHub setup and configuration steps.
Code Editor — VS Code
You are going to want to start with your code editor. The instructors will recommend VS Code or Atom, but if you already have a favorite editor, you do you. I went with VS Code. Which you can download from their website, Docs link at the top, then Setup link from the side. You can just follow the defaults of the install. This included keeping the check box in place to add to PATH.
Next is Node.js, which again can be downloaded from their website. This can also be done straight through the defaults. You will again want to make sure the PATH variables get installed for NPM and Node. This will be a default, so you shouldn’t do anything to it.
Again, go to the website to install MongoDB for Windows. Run the installer, choose the complete installation. Keep the configuration defaults. This will allow us to start and stop the MongoDB as a service. Then click install.
To finish up with MongoDB, let’s add the variables to the PATH environment. You can right click on the Computer icon on the desktop and select Properties, then go to advanced. Alternatively you can do a search from the start menu for Environment, and choose to edit from the control panel.
In the dialog box, click Environmental Variables. This can be as a system variable, used for every user that logs onto the computer, or User variable, only for the logged on user. Find the Path and click edit. Click new, add C:\Program Files\MongoDB\Server\4.0\bin (be sure to change your version number to match if 4.0 is not the current version), then click OK. This setup is going to allow you quick commands to start and enter MongoDB.
Get the Python installer from the site. Make sure to add to PATH at the bottom of the window, then click install and this will setup Python. This installation, at the time of this writing, is Python 3. While working with Python in the course, some of the commands being used will be given as python3 and pip3, if the version that we installed is the only one on your computer, you will only need to use the commands python and pip. Pip is the package installer for python. For example, at some point you are going to install ipython, you will install it using pip install ipython.
The last thing to install from Installfest is PostgreSQL. From the site get the install file, and follow the default installation. You are also going to want to modify the environmental PATH again. Follow the directions again from the MongoDB section. Then add the new path of C:\Program Files\PostgreSQL\11\bin (make sure the version is correct, as current writing it is 11).
During the install process we created a password for the postgres user, this is the default superuser, and we had no way of changing the user name. Now when we go into cmd and try to open the database, it asks you to put in the password for your user name. This will cause login errors because that user isn’t set as a user for the database. There are a few things we can do to get around this, first you can add the user as a superuser. This would require either doing the command while logged in with postgres, or using the PG Admin graphical tool. I will not be going over this, but if this is the path you want to take, go for it. The simplest way is to use the user attribute when starting your database psql -U postgres. The final way, which I feel is the best way, is to add it as an environmental variable. Get into the environmental variable properties again, this time instead of editing the Path, we are going to create a new variable. This can be done in the User or system variables, click New, in the variable name type PGUSER and the variable value as postgres. Now all you need to do to start your database is to type psql in the command prompt, it will then ask for the postgres password.
Now that all of our major programs have been installed and some setup done, we are going to go over some of the other issues that I ran into during the 12 weeks, and how I got through them.
You may first run into issues with Mac/Linux commands versus Windows commands. With the install of Git BASH, this shouldn’t be a problem. Generally, you can search pretty easily for the similar command, I have also added a link to some common commands.
Throughout the course, there are going to be checkpoints to test your knowledge of the materials. These will generally be coding challenges that you have to run a test against. This caused some serious headaches for me. These tests are all written with Mac in mind, so there were a few issues run into. Firstly, Mac and Windows paths do not follow the same convention. This is where WSL is incredibly useful as the Mac path conventions follow the same standards as Linux. You will want to use the Linux BASH that you installed, and follow the instructions above on how to navigate to the Windows folders to perform your tests. That being said, another issue that I encountered was that even using WSL, the tests wouldn’t run for the first checkpoint we took. The best the instructors and I could figure out was that this had something to do with unexpected syntax problems. The only thing to do was write the code and hope for the best. This problem did not occur for any of the other checkpoints taken.
The final little problem I ran into was during the Python and Django part of the course. While working with Python, it is best practice to use a virtual environment. Install the package using pip install virtualenvwrapper-win. Then you will create the environment using mkvirtualenv envname. This will activate the environment automatically, but if you need to start the environment again, use workon envname.
Even though a lot of this information would be useful for any person getting started as a developer on a Windows machine, as I said before, the focus was on the specific course that I took. Following these instructions will hopefully keep you from getting behind as you are searching for solutions. There are also a few good links you may want to check out too. Good Luck.