Parts in this series

Part 6: Local Development

This is part 6 in my series on the order to study topics related to programming. This series aims to provide a gentle path to follow as you explore this fascinating field. The goal is not so much to get you a job in the field, but to help you to take on a new hobby.

In the first five parts, I covered Markdown, HTML, SQL, a little interlude on bits and bytes, and dynamic programming languages. If you’ve made it this far, then congratulations! You are a programmer and you have acquired a new skill that I hope has been fun, challenging, and interesting.

There are many different directions you can take, now. You have probably encountered references to a ton of terms and technologies that tweak your interest. I encourage you to follow whichever learning paths inspires you the most.

However, if you don’t have a clear direction in mind, my next suggestion is to focus on the tooling you need for what is called “local development”.

In the tech world, the words local and remote mean roughly the same thing as in real life. “Local” refers to stuff that happens on the computer you are currently logged into. A “local development environment” is the collection of programs and tools you use to write software on your computer.

In contrast, “remote” refers to actions that happen on other computers across the network. “Remote” typically refers to logging into a specific computer at a specific location. If you don’t know the computer that you are remotely connecting to, then you are generally working in “the cloud”.

“The cloud” is an excessively overused, meaningless term. I’m sure you’ve heard it in the media. It means something like, “stuff just gets run somewhere in some company’s data center and that company is making sure that everything is happening in the right place at the right time.”

Why local development environment now

Strangely, setting up the software you need so you can program on your own computer can be frusterating. Every computer is set up differently, with different versions of different operating systems running on different hardware using different network configurations. Any one of these things can muddle what should be a straightforward task.

Traditionally, learning to program required completing all this setup stuff before you got to the fun bits. You’d probably encounter unforeseen issues not covered in whichever tutorial you are reading. Then you get bogged down in search engines or discussion forums for a few hours, and, ultimately, give up.

But! If you’ve made it this far, two things have happened:

  • You know you’re interested in programming. You understand the payoff, and the end result is more worth it to you than when you didn’t know what you were getting into.
  • You have learned a lot of neat things about the way computers work. You better know how to search for solutions to problems you encounter.

As a result, I think you’re ready to tackle the local setup. In fact, I suspect you will not have much trouble and will wonder why I’ve been going on about it so much.

There are a few things you should set up and learn how to use in order to develop locally:

  • command line interface
  • a text editor
  • the “toolchain” for the programming languages you have chosen

I’ll discuss each of these in turn.

Command line interfaces

Before computers had touchscreens or even mice, before graphical interfaces or the concept of “windows”, the only way to interact with a computer was through a command line interface, or CLI for short.

Most programming setups require that you know how to use CLIs, even today. A simplified view of a CLI is a “call and answer” interface. You type commands, which run programs that do things, and output responses on the screen. an example of a command line session follows. Each line that starts with $ is a command I typed in, and the following lines are the output from that program:

$ ls
archetypes  config.toml  content  data  layouts  public  resources  static  themes
$ cd content/post
$ ls | grep order
order_toi_learn_to_program-part-1.md
order_to_learn_to_program-part-2.md
order_to_learn_to_program-part-3.md
order_to_learn_to_program-part-4.md
order_to_learn_to_program-part-5.md
order_to_learn_to_program-part-6.md
$ wc order_to_learn_to_program-part-6.md
  58  711 4363 order_to_learn_to_program-part-6.md

The first command is ls, which stands for “list”. It lists all the files and folders in the current directory (which is what “folders” are called in CLI land).

The cd in cd content/post stands for “change directory”. It is changing into the post directory that is inside the content directory.

The next command is ls | grep order. The ls command is the same command used before. However, now I’m inside the post directory, so it’s listing different files. The | character in the command is known as a pipe. You hardly ever type it outside of the programming world. On a US keyboard it’s on the same key as the \ character. Essentially, the lines that would have been output by ls go into the pipe to be processed by a second command named grep. This funny name can be thought of as meaning “search”. The order that follows it is the word being searched for. Only those lines that ls would output that contain the word order are printed. These happen to be the Markdown files for all the parts in this tutorial.

The wc in the last command, wc order_to_learn_to_program-part-6.md stands for “word count”. It counts all the lines (58), words (711), and characters (4363) in the file and outputs them on the command line.

Setting up a CLI

Command line interfaces are also called shells. The most common one is named bash which stands for “bourne again shell”. The name has a long history; it is essentially a souped up replacement for an older (1979!) shell program named the bourne shell, named after Stephen Bourne, it’s inventor.

If you use Linux or MacOS, your computer already has bash installed, and should be fairly easy to find. Search for a program named “terminal”.

If you use Windows, it’s a bit trickier. Windows traditionally uses a quite different shell named Powershell. Most programming tutorials assume you use bash. You have a few options:

  • If you use Windows 10, there is a version of bash that is supported by Microsoft.
  • Older versions of Windows can use an open source application called mingw.
  • You could try to learn Windows Powershell instead of bash. You’ll need to follow Windows-specific tutorials in that case.

Learning CLI programming

Because all the commands that run in a shell are separate programs, anything is possible. In fact, you can write more programs to run from the shell. And shells are practically programming languages in themselves. Advanced bash programming is a serious art that few people have mastered. I’m not one of them.

Search for “introduction to bash” (or “introduction to powershell” for Windows). Make sure you are getting something that assumes you’re a beginner. If it doesn’t start with a better explanation of what a shell is than I did above, find a better one.

What to learn

Most importantly, get comfortable with navigating the filesystem using the command line. Learn commands like cd, ls, mkdir, cp, and pwd. I personally prefer using my shell to navigate my files than a graphical file manager.

Understand the concepts of stdin and stdout, so that you can use basic “pipes” and redirection. Make sure you can create a file from the output of a command.

Ultimately, make sure that you know enough to understand the commands that you read in tutorials on the Internet while you’re learning to code. Never blindly copy-paste commands that you don’t fully understand. There’s too many ways to encounter a malicious command. It used to be considered funny to trick newcomers into accidentally deleting all their files, for example. Programmers aren’t so nasty today, but malicious people might want you to run unsafe commands that allow them to hack your computer.

Text editors

I’ve touched on text editors in earlier articles, suggesting you might want to install one at various times. Now, I strongly recommend you install one. Some popular choices include vscode, atom, and sublime text, but there are many others. I personally use and recommend vscode, but any of the available options will serve you well.

Unlike programs written for consumption by the general public, text editors are extremely configurable. Most allow you to write your own “plugins” or “extensions” that change the editor in some way. There are hundreds of extensions written by other programmers to simplify various kinds of programming. All editors allow you to change keyboard shortcuts and have myriad settings to tweak. You can find dozens of articles about effectively using your chosen editor.

Programming toolchain

If you are developing locally, you need the tools installed on your computer to allow you to run your software. If you are coding in Python, you obviously need Python installed. If you are coding in Javascript, you may get away with just using the browser, but you’ll likely want to have something called nodejs installed as well.

Other environments such as Android, IOS, Windows, and game development all have completely different possible arrangements with their own quirks. Sadly, I can’t help you much here, since it depends on how you have your computer confured as well as what you are focused on learning. But I hope you get a system that you enjoy using as much as I enjoy my setup!