In this tutorial you will learn how to how to quickly set up a simple, low-requirements, no-database, no-webserver Git repository. All you need is (unprivileged) SSH access and the git program itself.
In this article, we’ll cover some good reasons why you would want to learn to program (even if your position doesn’t have ‘software’ or ‘developer’ in the title).
Then, we’ll discuss the questions you should be asking when it comes down to choosing your first language and actually getting started.
Finally, I’ll tell you which languages I would learn, in which order, if I were starting over again today.
I was just talking to a friend about programming. She’s interested for all kinds of reasons, not the least of which is that she’s read all about how ‘programming is the future’ and that tech people make tons of money.
We talked about some things that I thought would be useful to share more openly — so here it is: my advice for getting into programming, System Administration, or any other technology path.
System Administration and programming are becoming more and more entwined with each passing year. If you’re not programming yet (or don’t view the scripting/configuration-management you do as programming), my hunch is that you will be, soon.
There were a few talks at 32c3 about different methods for securing applications on Linux and Unix. You’ve probably heard of several, like AppArmor, SELinux. Capsicum is an interesting solution for FreeBSD; its basics are explained well in this video (although the video is really about another technology).
We’re definitely still at the very beginning stages of running untrusted code safely on our machines. It’s kludgy, breaks common applications, and works cleanly for only a few very specific use-cases at the moment. One of the problems is that applications really aren’t written with containment in mind — a lot of security problems require the cooperation of developers to really work smoothly. For example, your web browser needs to read and write files ANYWHERE on your filesystem (for opening local HTML and saving files from the Web). Even if web browsers had no other features, this would make them difficult to effectively contain.
CloudABI looks like it’s a big step forward in this space. It’s a way to limit what software can do once it’s running on your system; a sort of ‘restricted execution environment.’ CloudABI has three huge features, along with many great small ones):
- Capsicum is always turned on.
- Applications are forced to behave (no global namespaces, no hardcoded filepaths). Dependency injection is enforced.
- Implementations/Ports for NetBSD + Linux.
This talk gives you a good idea of how it works on both a theoretical and a practical level. Even if you never write applications that comply with an environment like CloudABI or mechanisms like Capsicum/SELinux/AppArmor/etc., this talk is an interesting introduction to the thoughts behind how to contain applications, write safer/less-exploitable applications, and otherwise improve Operating System security.
Here’s something that surprises many people: I actually don’t have a college degree. Before I got into System Administration, I did all kinds of things: I’ve been a soldier, carpet salesman, martial arts teacher, Chinese massage (Tui Na) practitioner, data entry temp, bakery worker, and a few other things.
On the surface, these don’t look like they are related to System Administration, but each of these other attempts at ‘finding the right career’ taught me something valuable that I still use today in System Administration and Development work.
For example, all that ‘unrelated‘ experience has taught me how to
I remember sitting at a system engineering gig a few years ago, fighting an angry LDAP server and talking about my goal of sitting on a beach and doing sysadmin and programming work from my laptop. My manager, a smart and practical fellow, laughed and told me it was a pipe dream and that such work simply didn’t exist. Two years later, I can work from the beach every day, if I feel like it.
Everyone loves remote work — whether it’s system administration, database administration, testing, QA, remote programming work, or something totally different. As with anything else, there are some downsides, but the advantages to both companies and employees are huge. Lower office costs for companies, fewer interruptions for employees; the list goes on and on. It’s still early in the ‘remote work’ timeline, and some businesses still need to get used to the idea. If you’re interested in an exhaustive pro-and-con list in book format, check out Remote: Office Not Required.
Here are a few of the sites I’ve used to search for (and get) both full-time and contracting work: