Setting up a development environment

Since I migrated to Linux about two months ago, I’ve been setting up a development environment. By that, I mean installing everything I need to do web development on my own computer (things like a web server). It’s been a great learning experience, both for learning how the individual pieces of software work and for how Linux (and other Unix-like systems) work in general. This article is designed to guide you through the decisions you need to make when setting up such an environment for yourself. It does not tell you how to install each and every piece of software, there are so many guides on the internet that do that already it’s not really worth it.

Stage 1: what services do I need?

The first step is to analyse what your need is and decide what services will be needed. This list will depend entirely on your circumstances. If you plan to just to do basic web development, it’s likely all you’ll need is the basic web server, CGI program (eg PHP) and database software (eg MySQL) set up. Anything more involved, and it’s likely you’ll need to pick and choose from the following list:

Web Server

Pretty much mandatory for any type of local web development. The only time you could conceivably get away without one of these is if you hired a web space and simply wrote everything on your local machine and then uploaded it to your remote server.

CGI program

Whether or not you have some sort of CGI scripting ability installed depends on whether you want your pages to be dynamic or not. If all you want is static pages that are displayed the same to every user, don’t bother messing around with this. Any degree of dynamicity, though, and you’ll need something like this to handle the scripting for you.

Database software

Again, if you want dynamicity on your pages, it’s likely you’ll need to store some sort of data in a database, and so you’ll need some sort of software to run it for you. Notice that you can’t have database software without scripts to connect to it, so without a program to run CGI scripts, you can’t really store anything in a database.

Version control

(Definitions for those that haven’t heard of version control before) If you’re working with a team, you’ll need some sort of version control. If you’re not but care about backups, then you’ll still want to go for some sort of version control. It’s such a stupidly useful piece of kit to have that sometimes it can be worth going the extra mile to get something set up.

FTP Client

Only necessary if you need to sync files on your local server with files on your remote server. If you’re only doing remote development, you won’t need an FTP client.

Stage 2: What software will I choose?

Now you’ve decided which services to install, you need to decided what software you want to fulfill those services. There are a few options open to all of the services mentioned, I’ll go through some of them here:

  • Web Server: if you’re not bothered about spending money and are more familiar with Microsoft products, then IIS is probably the way to go. If you’re on Linux, don’t want to spend money or just prefer the flexibility of open-source products, then Apache is a better choice. Both of these servers are extremely well documented and have avid followings, so you won’t have any problems finding support if you get stuck with something.

    There are other options available as well. If what you’re dealing with is mostly static or all static files, then a server like Tux or thttp will be a faster option, so you should check these out. Of course, there’s high-end solutions as well. If you have a very busy site, it may be worth serving images or other static files through a seperate server, and here you might want to investigate one of the servers I’ve just mentioned.

  • CGI program: probably the most important decision you’ll make is what language to script in. The choices, once again, come down to Microsoft in the form of ASP.NET or open-source in the form of PHP. Once again, both languages have excellent documentation and thousands of forums available for discussion. The good thing about ASP.NET is that it’s more a framework than a language. You can use many different languages, ranging from VB.NET to things like J#.NET and even C++.NET! This can be a great way to use what you’re famailiar with on the web. Keep in mind that a Microsoft setup will cost you, though. You may also want to go with ASP.NET because of it’s object-orientated form. PHP is traditionally a procedural language, and as ASP.NET is a recent language it has been designed as object orientated.

    On the flip side, PHP is free and is has more libraries: because PHP is open source, people tend to write extensions to PHP when they need a library that isn’t already included in PHP. Because of this, you can find loads of brilliant libraries to connect to any type of service. Of course, don’t forget that it’s free. You may also want to consider the fact that it’s free.

  • Database software: Your choice of database software is largely determined by the CGI scripting language you’re using. Go with ASP.NET and it’s likely you’ll go with Microsoft SQL Server, go open-source and MySQL is probably the choice for you. Have a look around, though, there are several good SQL database systems around that could suit your project well.
  • Version control: the big version control software is CVS, but it’s a case comparable to browsers: the biggest isn’t really the best. I’d advocate Subversion, which is growing in popularity and was designed specifically to address common frustrations with CVS.
  • FTP Client: just go for a cheap free one, unless you do lots of FTP transfers, when you’ll probably want to search for a bit longer. I’m a fan of the command-line based NCFTP client.

Stage 3: where to put it all

This is debatably less important than the first two stages to designing your environment, but it is nevertheless important in my mind. Once you’ve decided what software to use, you need to decide first where to install the software, and where to keep the files for your development environment. That’s a bit vague so I’ll clarify: you need to decide where, in terms of directory structure, where to keep your files.

There a few factors at play here. You you need to keep the length of your paths down (for example, /usr/local/software/apacheorg/httpd/htdocs/ is a bit long considering how often you’re going to need to type it), whilst still maintaining a logical and appropriate directory structure.

This obviously depends on your file system and operating system. SuSE Linux by default puts a collection of sample HTML files in /srv/www/htdocs. I found this a bit too cumbersome, and had several projects, and so changed it to /srv/htdocs/<project name> (for example, my working copy of xmouse lives at /srv/htdocs/xmouse). My subversion repositories are located at /srv/svn/<project name>. These are the two important paths to think about, as they’re the two you’ll be typing in often. I could have my database files at /srv/db, but I didn’t really think it was necessary as MySQL knows where they’re at /usr/local/var/mysql, and I didn’t want to change the default directory. However, I frequently type /srv/svn when dealing with my repositories, and /srv/htdocs is one of the most visited directories on my hard drive. My point here is that you need to keep a logical directory structure, but make sure your structure isn’t so vertical that you end up with ridiculously long paths.

Other decisions

I’ve described basically the design decisions I went through, when I was setting up a single user system with minimum security. It’s likely when working with a team you’ll need to consider multiple users, access levels, security measures like SSL and network access. I’m not going to go into sort of detail here because this is pretty much where my experience ends and I frankly wouldn’t have a clue what I was talking about (not that that would be a big change or anything :)).