I'll be interested to see what you turn up about system administration, because I could probably use a good primer myself.
Some things I know you will need to learn:
1) You're going to need to learn how to run/manage the operating system of a server. Presumably some flavor of linux. You may find – I did – that this information is easier to learn for a specific flavor of linux. Speaking of learning linux is a little bit like speaking of "learning romance languages"; most pedagogy is organized around learning one at a time, though after you've learned one or two, generalizing to the rest is pretty easy. I have a Debian linux server, so that's what I looked into, and found some nice resources I should spend more time with. And expect to soon.
2) Programming and system administration have a particularly intertwined relationship in the unix/linux world, because:
• The unix command-line commands, themselves, work like tinker-toys: you can concatenate them up into meaningful expressions that are basically little programs. For example: The expression ls means "list out the files in a directory"; the expression grep means "find all lines that match this example". The expression "|" (called "pipe") means take the output of this command and make it the input of that command, so ls | grep '.html' means "get the list of files in this directory and return only those with '.html' in their names." The expression ";" means "and then next do"; the expression ls this; ls that will result in the directory listing for this followed by the directory listing for that. And there are other ways to cause commands to interact. So you can see how you can start building long complex chains of expression. And this isn't "programming", in the sense of making a document that you store and run; this is conversational code, expressing yourself to the computer at the prompt.
• Certain unix command-line commands are, themselves, programmable in weird and powerful ways. sed and awk are two famous examples. I never remember how they work, and always have to look them up. There are others; there are conventional programming languages that allow themselves to be called this way, and some other things, like the insane email client I use.
• You can write programs that function as command line commands and interact with the above. If you write a little program in perl called myprogram.pl and put it in your bin directory as is traditional, you could then say at the prompt ls | ~/bin/myprogram.pl.
• You can capture any of the above into programs, which are called "shell scripts" (also there is something called "aliases", which are like particularly simple shell scripts.)
Upshot: basic interaction with unix/linux servers, at the command line, entails some degree of speaking conversational unix/linux to the computer, which is done in something that looks a lot like a programming language, but! Which is actually a whole bunch of programming languages.
3) If you're going to want to run interesting services on your server, yourself (not a foregone conclusion; most mere mortals just configure their email that someone else runs, because running an email server is Hard these days) you will need to learn the specifics of whatever applications you're running.
4) And that will probably entail some amount of learning how computers talk to one another, which is protocols. This might be something you only need the rough outlines of to get done what you want. Like, I have a studious ignorance of how TCP/IP actually works and it has slowed me down not at all so far. OTOH, if you actually get interested in that, more power to you. And to do interesting things with webpages or email, you might actually have to know a bit more about how HTTP or SMTP works.
5) You may need to learn how to compile things from source, because that's how the applications you want to run are distributed. This is kind of considered part of "how to program" because compiling is a things programers do to programs.
6) Somewhere along the line, if you're doing a lot of work at the command line, you're probably going to need to learn vi. Or maybe emacs. These are text editors for commandline unix/linux systems. You use these to edit files. And they are full of their own quirky commands. (emacs, in particular, is famous for being/having its own language embedded within it, hence the joke, "emacs isn't a bad operating system, but it needs a better text editor".)
Miscellaneous. Eclectic. Random. Perhaps markedly literate, or at least suffering from the compulsion to read any text that presents itself, including cereal boxes.
(no subject)
Date: 2019-09-12 05:14 am (UTC)Some things I know you will need to learn:
1) You're going to need to learn how to run/manage the operating system of a server. Presumably some flavor of linux. You may find – I did – that this information is easier to learn for a specific flavor of linux. Speaking of learning linux is a little bit like speaking of "learning romance languages"; most pedagogy is organized around learning one at a time, though after you've learned one or two, generalizing to the rest is pretty easy. I have a Debian linux server, so that's what I looked into, and found some nice resources I should spend more time with. And expect to soon.
2) Programming and system administration have a particularly intertwined relationship in the unix/linux world, because:
• The unix command-line commands, themselves, work like tinker-toys: you can concatenate them up into meaningful expressions that are basically little programs. For example: The expression ls means "list out the files in a directory"; the expression grep means "find all lines that match this example". The expression "|" (called "pipe") means take the output of this command and make it the input of that command, so ls | grep '.html' means "get the list of files in this directory and return only those with '.html' in their names." The expression ";" means "and then next do"; the expression ls this; ls that will result in the directory listing for this followed by the directory listing for that. And there are other ways to cause commands to interact. So you can see how you can start building long complex chains of expression. And this isn't "programming", in the sense of making a document that you store and run; this is conversational code, expressing yourself to the computer at the prompt.
• Certain unix command-line commands are, themselves, programmable in weird and powerful ways. sed and awk are two famous examples. I never remember how they work, and always have to look them up. There are others; there are conventional programming languages that allow themselves to be called this way, and some other things, like the insane email client I use.
• You can write programs that function as command line commands and interact with the above. If you write a little program in perl called myprogram.pl and put it in your bin directory as is traditional, you could then say at the prompt ls | ~/bin/myprogram.pl.
• You can capture any of the above into programs, which are called "shell scripts" (also there is something called "aliases", which are like particularly simple shell scripts.)
Upshot: basic interaction with unix/linux servers, at the command line, entails some degree of speaking conversational unix/linux to the computer, which is done in something that looks a lot like a programming language, but! Which is actually a whole bunch of programming languages.
3) If you're going to want to run interesting services on your server, yourself (not a foregone conclusion; most mere mortals just configure their email that someone else runs, because running an email server is Hard these days) you will need to learn the specifics of whatever applications you're running.
4) And that will probably entail some amount of learning how computers talk to one another, which is protocols. This might be something you only need the rough outlines of to get done what you want. Like, I have a studious ignorance of how TCP/IP actually works and it has slowed me down not at all so far. OTOH, if you actually get interested in that, more power to you. And to do interesting things with webpages or email, you might actually have to know a bit more about how HTTP or SMTP works.
5) You may need to learn how to compile things from source, because that's how the applications you want to run are distributed. This is kind of considered part of "how to program" because compiling is a things programers do to programs.
6) Somewhere along the line, if you're doing a lot of work at the command line, you're probably going to need to learn vi. Or maybe emacs. These are text editors for commandline unix/linux systems. You use these to edit files. And they are full of their own quirky commands. (emacs, in particular, is famous for being/having its own language embedded within it, hence the joke, "emacs isn't a bad operating system, but it needs a better text editor".)
That's just off the top of my head.