When we learn to code, our focus is usually on the.. uh.. coding. Well duh. But if you’re a LAMP developer your work will naturally end up on a Linux server. A few weeks ago I recommended a Linux primer to a junior coder on my team.
He responded, “But I’m on Windows – why do I have to know this?”
In fact I remember thinking the same thing, a hundred years before when I first taught myself Perl. I learned on MacPerl with a book at my elbow. Before long, I could assign variables and loop with the best of them (I hadn’t mastered subroutines quite yet, but that’s another story). What I couldn’t do though, was get my work to run on the server. That was because I hadn’t yet worked out the way file ownership and permissions worked in the Unix world. Eventually, I set out to my favourite bookshop computer section (Books Etc in Tottenham Court Road) and bought myself an introduction to Unix.
The bottom line is this: if you’re writing code that is designed to run on a Linux server, you’ll need to be able to get some Linux stuff done – or you’ll be forever asking for help and that will be a drag for everyone. Here are some basics you’ll need to get to grips with. I’ll be adding articles on each of the topics in the coming weeks.
Understand and set file and directory permissions
It is unlikely that the web server runs as the same user or group as you do. When your script is invoked by a browser it will run as the server – and it may not have the same rights to read and write files as you do. What’s more, for some files to be runnable as scripts need to be configured as executable. You’ll need to get these concepts straight early on because your scripts will hit ownership and permission issues. They are probably the most common cause of 500 errors in my experience.
Which brings us to:
Find and read your error log
Depending upon how your system is configured, some errors may throw up a featureless white screen. Chances are, a wealth of information has been written to the server’s error log. If you go to a more experience colleague for advice, the first thing she will ask you is ‘what does it say in the error log?’. See this post for some tips on errors and logs.
Configure a database
There’s a good chance your system writes data to a database. While the DBA or systems specialist on your team might be the person in charge of configuring the production database, it is often down to developers to stand up databases for test, staging and development environments.
Install packages
Code very rarely stands alone. At the very least, you’ll likely need a web server, and probably a database server. You’ll need the interpreter for your programming language. You’ll need about fifteen extensions to that interpreter. The list generally baloons from there as your project gets more demanding. You’ll need to get the right stack installed – probably using either Apt or Yum depending upon the flavour of Linux you’re using.
Create a Linux development environment
It’s fine at first to use whatever LAMP-like stack your non-Linux operating system provides, but sooner or later you’re going to need to deploy this stuff into an environment that resembles the production server. Luckily for you, virtualisation has gotten real easy recently. Check out this article on setting up Vagrant for some more on that. For nominal outlay you can spin up development boxes fast with service providers like Digital Ocean or Amazon’s AWS.
Edit files in place on the server
If you’re using Vagrant, you’ll mount your host machine’s directories on the development box so you can stay in your comfort zone when it comes to editing files, but sooner or later you’ll find yourself logged in to a remote server and needing to alter a source or configuration file. You should at least be able to open, edit and save a document. Real blood has been spilled over the years in aguments about the best Linux/Unix text editors. It’s worth noting that a flavour of the powerful-but-arcane Vi editor will be present on 99.9% of the machines you might access. Just saying.
Configure your Web browser
Up ’til recently that meant Apache – these days there’s a new guy in town – Nginx. Whatever you’re using, you’ll need to be able to perform some basic setup for things like name aliasing, URL rewriting and basic authentication.
Set up keys for Github, Bitbucket and the like
A member of a team I know has an account on a shared development server. He has his keys set up to work with Github from his local machine, but he has failed so far to set up his environment so that he can pull code he has committed to Github onto the staging server for testing and evaluation. This means he must ask his teammates to do it for him – about five times a day. In fact, he has everything he needs to configure his own access – everything but the knowledge.
Check back in over the coming few weeks as I flesh some of these out!
“Penguins” by _Reinis Traidas is licensed under CC BY 2.0_
