The Advent of CLI - Day 6

Let make a little parenthesis just for Windows, but some of it will also work on macOS and Linux :slight_smile:

In The Advent of CLI - Day 1, I already introduced some default settings like using WSL with Ubuntu 18.04 LTS and the Windows Terminal, but now let focus a bit more on the programming for programmers stuff.

magic


For Windows

First, here a short video that introduce nicely most of the concepts
Developing on Windows with WSL2 (Subsystem for Linux), VS Code, Docker, and the Terminal


This is exactly why you do want to use the command-line.

Simply put, installing developer tools under Windows sucks,
let’s say you want to install things like Node.js, Python, PHP, Ruby, etc.

With only the CMD, it really gonna sucks
and probably not work really well and you will end up being super duper frustrated.

Using something like Chocolatey will ease the pain, but some stuff will still not work
and you will still end up being frustrated.

When you are under a Linux distro, like Ubuntu, all this pain go away instantly as you just need to type something like this $ sudo apt-get update followed by $ sudo apt-get install nodejs, and from there everything is then automated.

And yeah you could use something like Cygwin, but then you would not get by defaut a package manager like apt-get, you can emulate it somehow but it is pretty limited.


So the video above do a pretty good job a demonstrating how using WSL / Windows Terminal and then VS Code is a huge game changer under Windows.

See, having a light Ubuntu VM with WSL is great, but you will always end up fighting a little bit with the different file systems, environment variables and whatnot.

WSL 2 improve that a lot, but still you will have to plan in advance how to organise your projects

  • do I checkout the sources under the Windows file system and then work under Linux ?
  • but if I checkout the sources under Linux how do I edit them under Windows ?
  • How do I share stuff ? How do I deal with the different access rights and credentials ?
  • plenty more …

And that is exactly what VS Code can solve for you :stuck_out_tongue:

Under WSL, so inside an Ubuntu environment, juste type $ code . and then it will connect “magically” to your VS Code IDE launched under the Windows environment, that’s great.


VS Code Remote

See VS Code Remote Development introduction

Visual Studio Code Remote Development allows you to use a container, remote machine,
or the Windows Subsystem for Linux (WSL) as a full-featured development environment. You can:

  • Develop on the same operating system you deploy to or use larger or more specialized hardware.
  • Sandbox your development environment to avoid impacting your local machine configuration.
  • Make it easy for new contributors to get started and keep everyone on a consistent environment.
  • Use tools or runtimes not available on your local OS or manage multiple versions of them.
  • Develop your Linux-deployed applications using the Windows Subsystem for Linux.
  • Access an existing development environment from multiple machines or locations.
  • Debug an application running somewhere else such as a customer site or in the cloud.

No source code needs to be on your local machine to get these benefits. Each extension in
the Remote Development extension pack can run commands and other extensions directly inside
a container, in WSL, or on a remote machine so that everything feels like it does when you run locally.


So yeah the first extension you would want to install is Visual Studio Code Remote Development Extension Pack.

It works great under Windows, but also macOS and Linux.

It allows to combine three very essential things for a developper

  • using your code IDE on your local machine for all the comfort of writing and editing the sources
  • instantly deploying the sources on the target environment to test, debug, etc.
  • and still sync seamlessly with your favorite VCS like svn, git, hg, etc.

Before this existed I was using tools like sshfs and Expandrive.

And before that I was editing locally, synching with the VCS, then connect remotely and update from the VCS … little dance.

And way before that I was uploading all my files through FTP … total fucking nightmare but yeah it was the 90s.


But no more of that bullshit, VS Code Remote is the way to go, here some use cases

  • you get the sources under WSL 1 or WSL 2, type $ code .
    and boom you edit eveything under VS Code for Windows

  • You got a complex setup, have everything configured under a VM,
    run your VM (for ex under VirtualBox) and Remote SSH to it from VS Code

  • You already deployed some code on a Linux server
    Remote SSH to it from VS Code and directly edit the code as if it was local

It will work virtually anywhere: WSL, VM, docker, remote server, etc.

The only thing you need to do in parallel is configure SSH correctly.


It is great for open source projects, any type of projects involving code running on a server,
even complex projects where you have different daemon (like background jobs) and other micro-services.

My typical case is

  • having a local VM that is the perfect replica of the production server
  • remote SSH to the local VM to implement new features
  • then push to an online test server and then deploy to a prod server

but this can vary a lot depending on your needs and what you do.


To get started, follow the 3 part tutorials from the Windows Command Line blog


To go more into the details, follow the really well made tutorials