On March 22nd I gave a presentation to ASU's Software Developers Association which I called "What My Professors Didn't Teach Me - Developer Skills: What They Are, Why They're Important and What You Should Know About Them". The presentation provided an overview on seven different "developer skills" that I believe are necessary to succeed as a professional software developer. I define "developer skills" as those aptitudes between the "hard" technical skills of programming / hacking and the "soft" interpersonal skills of teamwork and communication. They are the things that a developer needs to know to succeed at his job outside of actually building software.
Over the next several weeks I will be writing a post on each of these proficiencies; each post will describe what the developer skill is, why I consider it to be necessary knowledge for the workplace, and what specific things you should learn. I plan to have links to tutorials or other websites that you can use to follow up.
The posts will be as follows:
Part 0: Introduction
Part 1: Version Control
Part 2: Ticketing Software
Part 3: Multi-Branch Development Workflow
Part 4: Libraries and Package Managers
Part 5: Working with Remote Computers
Part 6: Communication Between Software
Part 7: Securing Your Communication
The remaining three posts in this series all have a common theme, which is: (virtually) no computer works in isolation today. On one level this is a trivial statement - every computer is connected to the internet, obviously. What I am more talking about is the fact that the modern developer must be comfortable both communicating across the internet with other machines and often, developing on those remote machines. He also must know how to build software that can reach out to other software and communicate; and he must be able to do all of these things securely.
Perhaps the easiest way to see what I mean is to look at what I don't mean. Consider a standard college programming assignment. The code is written entirely on your computer. It is tested on your computer. It does not talk to other software across the web (it often isn't even allowed to use libraries). When the code is complete, you usually send the source code to a professor or TA, who compiles it from scratch on her machine to grade it.
This is quite unlike anything seen in the real world of development - communication with other machines and software is frequent and indispensible in modern development, and as usual it's crucial that you learn it. So let's begin the final set of posts by discussing one of the most basic modes of communication: connecting to a remote computer from your local computer.
What Is This?
Communicating with a remote computer can take many forms, but general idea here is that you are sending commands to a remote computer from your local machine and to some degree are seeing the results of those commands. It is as if you are opening a window to that computer - your keyboard (and maybe your mouse) are controlling the remote keyboard, and your screen shows what is on its screen.
There are two major forms of communicating with remote computers: through a terminal shell and a graphical shell. "Shell" here refers to the idea that the software used to achieve this communication is like a shell around the remote computer.
A terminal shell allows you to communicate with a remote computer using only text. If you've ever opened the "terminal" (also called a "command prompt") on your computer, you'll find that using a terminal shell to communicate with a remote computer looks almost the same. Of course, unlike using a command prompt on your local computer, you'll need special software to allow terminal communication with a remote computer.
Example of a terminal shell running ssh. Photo credit: https://www.howtoforge.com
telnet was once the primary software used to achieve this communication. Nowadays, ssh (stands for "secure shell") is the preferred software, as it is far more secure (we'll be discussing security more in-depth in the final post of this series). In either case, the software works by receiving an IP address or other qualified name for the machine you wish to connect to, negotiating a connection with the computer, and then sending commands and responses back and forth between the two systems. This is often referred to as "shelling in". Because the communication is solely text-based, only keyboard commands can be sent.
A graphical shell is the same concept, but instead of only showing the text responses from the remote computer, you are able to see a simulated desktop view in the graphical shell software, as if you were looking through a virtual window onto the remote computer's monitor. Graphical shells allow you to send both keyboard and mouse commands, and anything the remote computer can render on its screen, you can see. Windows Remote Desktop is perhaps the most well-known graphical shell - as the name implies, it allows one Windows computer to "RDP" into another Windows computer. There are other software that allows computers with other OS' to communicate, or even for you to RDP from one OS to a completely different one (Splashtop is an example of this that I use)
Example of using remote desktop on OSX to connect to a Windows machine. Photo credit: https://itunes.apple.com
Regardless of the shell type you're using, you must always have both visibility and permission for the remote computer in order to connect. Visibility means that your computer must be able to "see" the remote computer across the network - if the computer is obscured (say, behind a VPN) or disconnected, you will not be able to connect to it. Permission simply means that the remote computer will accept commands from your machine - this is often achieved in the form of providing a password or providing cryptographic proof of identity.+
Why Is This Important?
Modern development, but especially web development, extensively takes place on computers other than your own. As usual this is easiest to see in the case of web development: websites run on remote servers, and the web developer will need direct access to those servers to maintain and upload changes to the website. In many cases, it is highly convenient to develop directly on the server to allieviate the necessity of running a "local server" on your own computer - this also allows you to connect to the server and develop on any computer. You don't need to worry about keeping code in sync. Note that on-server development has its own set of best practices to be safe and secure which I will not cover here; I bring it up because it is frequently used and has many advantages.
In some cases, companies or clients don't want developers to store copies of code on local machines, and so any development must be done over a remote connection. Again, the efficacy of this is debatable, but ultimately it happens, and the modern developmer must be prepared for it.
A VPS is your own dedicated web server and is highly useful - but you'll need to access it through a shell. Photo credit: http://knihi.net
I advocate for all web developers to own some webspace in a cloud server - by this I mean a virtual private server (VPS) that allows direct shell access and full control over the environment. There are innumerable professional and personal benefits to having this webspace and I've often found it very useful in a pinch. Of course, to utilize this VPS, you'll also have to know how to connect to it.
I have never worked on a website that has not required me to connect to a remote computer in some way. With this in mind, I would recommend all developers (not just web developers) know how to use the software mentioned above.
Things You Should Know
This is pretty straightforward - know how to use both a graphical shell and a terminal shell. I consider the latter more important to know since I see it used so much more often.
If you run a Linux system or have a Linux emulator (like Cygwin), you can of course use OpenSSH's command line "ssh" tool. You can also use Windows PuTTY, which is a client solely for using SSH or telnet. Finally, the Mac terminal also has ssh support.
PuTTY, a Windows tool for telnet or ssh. Photo credit: https://mediatemple.net
You should also have an understanding of graphical shells and how to use them. Splashtop is probably a good tool to use since it's pretty much universal and works with any OS.
Finally, because communciating with a remote computer often requires a connection to a VPN (especially when connecting to company systems), learn what a VPN is and how to connect to one.
This concludes our discussion of connecting to remote computers. The idea here was to allow you, the developer, to connect to a remote computer and send commands; the next post will be about enabling your software to connect to a remote computer (or more specifically, the remote software running on a remote computer) and send and receive data from it. These are called "web services" and will be discussed in greater detail in the next post.