By default XAMPP won’t start the Apache and MySQL services at system startup, so every time you reboot your computer you’ll need to restart them. Wouldn’t it be nice if those services started automatically? One way of doing that is to create a Launch Daemon that runs at system startup and have it start XAMPP for us.

Fire up Terminal, and run the following command:

cd /Library/LaunchDaemons
sudo nano apachefriends.xampp.apache.start.plist

Enter your OSX password when prompted, then in nano paste the following into your new plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>EnableTransactions</key>
<true/>
<key>Label</key>
<string>apachefriends.xampp.apache.start</string>
<key>ProgramArguments</key>
<array>
<string>/Applications/XAMPP/xamppfiles/xampp</string>
<string>startapache</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>WorkingDirectory</key>
<string>/Applications/XAMPP/xamppfiles</string>
<key>KeepAlive</key>
<false/>
<key>AbandonProcessGroup</key>
<true/>
</dict>
</plist>

Save the file and exit nano (control+o, return, control+x).

Now run the following terminal command:

sudo nano apachefriends.xampp.mysql.start.plist

And into this new file paste:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>EnableTransactions</key>
<true/>
<key>Label</key>
<string>apachefriends.xampp.mysql.start</string>
<key>ProgramArguments</key>
<array>
<string>/Applications/XAMPP/xamppfiles/xampp</string>
<string>startmysql</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>WorkingDirectory</key>
<string>/Applications/XAMPP/xamppfiles</string>
<key>KeepAlive</key>
<false/>
<key>AbandonProcessGroup</key>
<true/>
</dict>
</plist>

Save the file and exit nano (control+o, return, control+x).

When you restart your computer the XAMPP Apache and MySQL services should start automatically. You can check this by launching XAMPP Control and checking that Apache and MySQL have green lights displayed next to them.

A note about security

If you’re concerned about the security of your system while running XAMPP, the safest approach is not to run Apache or MySQL at all, in which case you might not want to have those services running while you’re not using them. However, I’m fairly certain that unless you intentionally open up port 80 in your hardware/software firewall your XAMPP server should be invisible outside your local network.

Credit

A hat tip to ‘cwd’, who posted this solution on Superuser. I tried a couple of other approaches before I stumbled upon this one which actually works.

Installing XAMPP was a snap, but when I came to create my own Apache VirtualHosts things started getting fiddly. Here are the steps I followed to get everything running smoothly.

What are VirtualHosts?

First, some quick background on what we’re trying to achieve.

VirtualHosts allow Apache to map a hostname to a directory on the filesystem. You can set up as many VirtualHosts as you need, so that each website operates under its own hostname. For example, you might want to map mysite.local to /Users/yourusername/mysite. To test your development site all you would need to do is plug “http://mysite.local” into your browser’s address bar.

Enable VirtualHosts

The first thing you’ll need to do is open the file /Applications/XAMPP/xamppfile/etc/httpd.conf in your favourite text editor. Look for the following lines:

# Virtual hosts
#Include /Applications/XAMPP/etc/extra/httpd-vhosts.conf

Uncomment the second line by removing the hash (#), so that Apache loads your custom VirtualHosts configuration file:

# Virtual hosts
Include /Applications/XAMPP/etc/extra/httpd-vhosts.conf

Create your VirtualHosts

Open the file /Applications/XAMPP/xamppfile/etc/extra/httpd-vhosts.conf. Towards the bottom of the file you will see some example VirtualHosts, which you should comment out or delete.

At the bottom of the file, add ‘localhost’ as the default named VirtualHost:

# localhost
<VirtualHost *:80>
    ServerName localhost
    DocumentRoot "/Applications/XAMPP/htdocs"
    <Directory "/Applications/XAMPP/htdocs">
        Options Indexes FollowSymLinks Includes execCGI
        AllowOverride None
        Order Allow,Deny
        Allow From All
    </Directory>
</VirtualHost>

This step is necessary to ensure that http://localhost still points at XAMPP’s htdocs directory once we’ve created our custom VirtualHosts. Personally I don’t use the htdocs directory a lot, but occasionally it’s useful to have somewhere to perform quick tests.

Now you are ready to create your own VirtualHosts. After the default localhost that you just created, add:

# My custom host
<VirtualHost *:80>
    ServerName mysite.local
    DocumentRoot "/Users/yourusername/path/to/your/site"
    <Directory "/Users/yourusername/path/to/your/site">
        Options Indexes FollowSymLinks Includes ExecCGI
        AllowOverride None
        Order Allow,Deny
        Allow From All
    </Directory>
    ErrorLog "logs/mysite.local-error_log"
</VirtualHost>

In the above example you should replace “mysite.local” with your own hostname. This can be anything you wish, but make sure you choose a hostname that won’t conflict with a real domain name. Using a .local extension makes it obvious that the site is hosted locally rather than on a public web server.

The path to your website can point at any folder in your OSX user directory. I store most of my sites inside of Dropbox so that I can access them on both my home and work machines. If your path includes spaces, make sure you enclose it in quotes, like in my example.

Edit your hosts file

Once you’ve saved your httpd.conf and httpd-vhosts.conf files, the next step is to edit your OSX hosts file so it knows how to handle your new ServerName. The hosts file is used by OSX to map hostnames to IP addresses. In this case we want to map your new ServerName to the IP address 127.0.0.1, which is your localhost.

Fire up a Terminal instance, and at the prompt type the following command:

sudo nano /etc/hosts

Enter your OSX password when prompted, and the hosts file will be opened in the nano text editor. You’ll see that the hosts file already contains some default hostname mappings (e.g. “127.0.0.1 localhost”). Use your keyboard’s arrow keys to navigate to the bottom of the file and add your own mapping:

# XAMPP VirtualHost mappings
127.0.0.1 mysite.local

Save the host file using the key combo control+o, and pressing return when prompted to choose the filename. Close the file using control+x.

Restart Apache

So that your changes take effect, restart Apache. This can be done using XAMPP Control, which is found at /Applications/XAMPP/XAMPP Control.app.

Point your browser at http://mysite.local (or whatever ServerName you chose) and you should see your website. However, there’s a chance that instead you’ll be faced with a…

403 error

Because Apache runs as the ‘nobody’ user by default, it may not have adequate permission to browse your OSX user directory or some of its subdirectories, in which case you’ll see a 403 ‘access forbidden’ error when you try and view your development site. Similarly, you may find that although you can view your dev site, PHP throws errors when you attempt to write files or make directories on the filesystem.

To fix this you can configure Apache to run as your OSX user. Open /Applications/XAMPP/xamppfile/etc/httpd.conf and look for the following lines:

# User/Group: The name (or #number) of the user/group to run httpd as.
# It is usually good practice to create a dedicated user and group for
# running httpd, as with most system services.
#
User nobody
Group nogroup

Change User to your OSX username, and save the file:

User yourusername

Restart Apache and you should now be able to navigate your site without any issues, including manipulating files and folders using PHP.

Making the change I’ve described above carries certain security risks, and if you choose to run Apache as your OSX user then you’ll need to be quite certain that XAMPP is not accessible from outside your local network. From what I understand, XAMPP’s built in security features ensure that this is the case out-of-the-box, and it is straightforward to beef up security for additional piece of mind.

If you’re not convinced that it’s safe to let Apache run as your OSX user, another option is to change the permissions of your dev directories so that the ‘nobody’ or ‘_www’ user can read/write to them.I suspect that I would quickly tire of setting folder permissions, which is why I have opted to take the path of least resistance!

Conclusion

Hopefully this post helps someone else to get XAMPP up and running on OSX. I imagine that MAMP Pro streamlines this process somewhat (I know it has a wizard for creating VirtualHosts), but as long as you don’t mind getting your hands dirty XAMPP is a fantastic way to learn how Apache actually works.

When I switched back to phpDesigner, the default blue-on-white color scheme seemed a tad boring, so I decided it was time to pimp my IDE! Unfortunately user created themes for phpDesigner are thin on the ground, which left me no option but to make my own.

PHP example:

HTML example:

CSS example:

JavaScript example:

I’ve named my theme Sunset, and it is inspired by the Midnight theme for SyntaxHighlighter. If any phpDesigner fans are looking for a light-on-dark color scheme to spruce up their code editor, perhaps Sunset will fit the bill.

Download

Download Sunset theme for phpDesigner

Installation and uninstallation instructions are included with the theme. Currently the theme has syntax highlighting colors for the four languages I work with: HTML, CSS, JavaScript and PHP.

Important

There is currently a bug in phpDesigner that sometimes causes the ‘separator’ colors to revert to their defaults (e.g. the color of <?php ?> tags reverts to black). The only sure-fire way to get things back to normal is to open the phpDesigner preferences dialog, and click ‘OK’. You might also try closing all your open documents and restarting the application. Hopefully this bug will be fixed in a future version of phpDesigner.

Working with a local web server

Except for the very simplest sites, my web projects require PHP and therefore must run on a webserver with PHP installed. For testing purposes I have an Apache webserver installed on my local computer – I use XAMPP, which is a free Apache/MySQL/PHP distribution for Linux, Windows, Mac OS X and Solaris.

For each project I create an Apache virtual host, which allows the website to have its own domain root. This is configured in Apache’s httpd-vhosts.conf file:

<VirtualHost *:80>
    DocumentRoot "D:/jobs/my_project/dev/_svn_working_copy/www"
    ServerName myproject.local
    ServerAlias www.myproject.local
    ErrorLog "logs/error.log"
    CustomLog "logs/access.log" combined
    <Directory "D:/jobs/my_project/dev/_svn_working_copy/www">
	Options Indexes FollowSymLinks Includes ExecCGI
	AllowOverride All
	Order allow,deny
	Allow from all
    </Directory>
</VirtualHost>

The important thing to note here is that the DocumentRoot points at the www directory of my Subversion working copy, not at a sub-directory of my XAMPP installation, as would usually be the case. This allows me to keep the development version of the site in the same location as all my other project files, in this case: D:/jobs/my_project.

The job folder also contains Photoshop mockups, wireframes, image assets and any other files related to the project. Keeping these files all in the one spot makes it easy to backup the project – I simply burn the entire job folder to disc or an external hard drive.

Version control is not backup

While we are on the topic of backup, I think it is important to point out that your should never rely on Subversion alone as a backup solution.

It is tempting to think of a Subversion repository as an alternative to conventional backup strategies, since in many respects a repository seems like the perfect backup: it is stored off site, it is well commented, and it has a history of every change ever made to your project. But by relying on the repository for backup you are putting all of your eggs in one basket. If the repository is ever corrupted you will lose your entire development history! Sure, you still have your local working copy of the site, but the ability to roll back to a previous website state or refer to old code is lost forever.

To guard against this possibility it is important to perform regular exports of your working copy, and archive these copies using your regular backup method. Subversion has an export command for this purpose.

Deploying to a live server

When it comes time to deploy your website to a production webserver, the simplest approach is to simply upload your working copy via FTP or SFTP. This method should require no major changes from your existing workflow, and has the advantage of working with any webserver. If your site resides on a shared hosting account then this is probably your only option.

There is just one gotcha: Subversion creates a bunch of .svn folders inside the working copy, which it requires to work. They contain sensitive information such as your repository URL, which you probably don’t want to broadcast to the whole world, so it is important to make sure that these files are omitted from the upload process. Any decent FTP client can be configured to filter out particular files or folders, so make sure to create a filter that ignores .svn directories. I use Filezilla, which does the job nicely.

If Subversion is already installed on your production web server (or you are able to install it yourself) and have shell access to the server, then you have another option available to you.

Instead of uploading files to the server from your working copy, you can checkout a working copy of your repository trunk to the production server. When you are ready to publish to the live site you just need to update the server’s working copy and any modified files and folders will be deleted/renamed/downloaded automatically.

The advantage of this approach is that it is largely free from human error – there is no chance you might forget to upload a modified file, or that one developer will accidentally upload an old file over a newer one.

Explaining how to work with Subversion on your production server is beyond the scope of this article (plus, I’ve never done it before!), but if you dig a little you will find tutorials online.

Update 11 March 2010: A couple of readers have pointed out that the alternative deployment approach mentioned above requires additional steps to hide the .svn directories on your production server. Please read the comments below for further information.

Making friends with Subversion

As I mentioned at the outset of this series, it took a couple of goes before I had an “aha!” moment and realised how Subversion could improve my workflow, but once everything clicked into place I didn’t look back. Hopefully this article has given you some pointers about integrating version control into your own web development process.

There is plenty of technical detail I haven’t covered, and for that I recommend checking out the free Version Control with Subversion book, and the excellent TortoiseSVN documentation. If you have any questions about my approach, or suggestions based on your own experiences with Subversion, please leave a comment below.

Icons in this article are courtesy of Visual Pharm.

Structuring your repository

Before you import any data to your Subversion repository you will need some top-level directories to help organise your project. There are no set rules dictating how you approach this, but the recommended repository layout is to create trunk, branches and tags directories:

/trunk
/branches
/tags

Trunk: This is where you store the “main line” of development. It is a snapshot of the current state of the project.

Branches: A “branch” is a copy of the project, and allows you to carry out a separate line of development without breaking the trunk. Once you are happy with your changes they can be merged back into the main code base.

Tags: A “tag” is an archival snapshot of the project at a given point in time.

Whether or not you create branches and tags entirely depends on your own approach to version control.

Tags are commonly used in software development to capture a snapshot of a stable release of an application, but are not necessarily applicable to websites, where changes tend to be pushed live as soon as they are made.

Branching is useful when multiple developers are working on the project, but may be a redundant concept for a solo developer. Two scenarios where I can see branching would be useful are during a website redesign, or when adding a major new feature to a site. Development of the live site continues in the trunk whilst the upgrades are carried out in a branch.

Even if you don’t plan on creating branches or tags I still recommend sticking with this conventional directory naming structure. If another developer ever needs to access your repository the trunk/branches/tags structure will probably be one they are already familiar with, and it also gives you the flexibility to create branches and tags should the need ever arise.

What files to keep under version control

The only files I keep under version control are those that are required to compile and deploy the site: the source files, any files that are required on the live web server, and a copy of the site’s database.

For a typical website I create two additional folders inside the trunk:

/trunk
    /db
    /www
/branches
/tags

The www directory represents a web server’s public http directory. This is where most of the project files and folders live. The db directory is where I store a dump of the site’s MySQL database (more on this in part 3 of this series).

If I was working on a Flash project then I would have additional directories for my Actionscript and FLA source files:

/trunk
    /db
    /www
    /src
    /lib
/branches
/tags

None of these folder names are set in stone, and you should choose a structure that suits your work methodology.

Creating a working copy

To begin working with your repository you need to checkout a working copy. To do this, create a folder somewhere on your local computer, and give it a name that makes its purpose obvious. I call mine _svn_working_copy, and create it inside the job folder for the particular project it relates to. For instance, my folder might reside at D:/jobs/my_project/dev/_svn_working_copy.

Right-click on the directory you created, and choose SVN Checkout from TortoiseSVN’s context menu. In the Checkout dialog that appears, enter the URL of your repository trunk.

Once the checkout is complete your working copy should now contain the db, www, and any other directories you created in the trunk.

(You might notice that each directory in your project contains a folder named .svn. TortoiseSVN requires these folders to do its job so make sure not to delete or edit them!)

Now you can start to add files to your project, and edit them as you would usually. Remember that the www directory represents the site’s root level, so your index file should be stored here, along with any other files and folders required for the site to function.

You might be wondering “What if I need run my project in my local web server? Shouldn’t I check out the working copy to my Apache webroot?”. That’s what I initially thought too, until I realised that Apache could be configured to read files from any directory on my computer. I’ll explain how (and why) I do this in part 3 of this series.

Keeping a database under version control

If your site relies on a database then you need to keep that under version control too, otherwise you lose synchronisation if you ever need to roll back to a previous website state. But because the database is stored outside of a website’s public html directory it needs special consideration to ensure it is included with Subversion commits.

I mentioned earlier that my SVN trunk includes a directory named db. This is where I place a dump of the site’s MySQL database. In my case this is a manual process: I use PHPMyAdmin to export a .sql file which I copy into my trunk’s db directory, overwriting the previous version.

I suspect it is possible to automate the process of exporting the database from MySQL into the db folder, but for now I’m happy enough to do it manually. Like the other steps in the version control workflow it quickly becomes second nature.

Making commits

When you have finished editing the files in your working copy it is time to commit them to the repository. In TortoiseSVN this is accomplished by right-clicking the folder in which your working copy resides (or any sub-folder or individual file) and choosing SVN Commit from the context menu.

At this point you have the option to add any non-versioned files to the repository, after which any new or modified files are uploaded to your Subversion server and stored in the repository. The next time anyone browses or checks out the trunk they will be able to view your changes.

Commenting your commits

It is good practice to accompany each commit with a descriptive message explaining the changes you have made. In a team environment commit log messages are a vital means of communicating with the rest of the team, but they are just as important for the solo developer. Well documented commits help you recall every change you make to your project, when you made it, and why.

Trust me, you don’t want to be the dunce, who commits with blank messages, or with meaningless ones like “Fixes”. Your team will hate you. You will hate yourself after a month, when trying to discover what the hell this code does in your brilliant project.
–Petyo Ivanov, The importance of commit messages

Commit frequency

How often you choose to commit changes to the repository is a matter of personal preference. Once a day, twice a day, ten times a day – it’s entirely up to you.

I like to make my commits fairly frequently. This makes it easier to review the changes that I’ve made, and also keeps me focussed on the task at hand: the commit message acts as a goal for the coding session. Also, I get a small glow of satisfaction each time I make it commit, like ticking off an item on a to-do list!

In the final part in this series I will talk about working with a local Apache development server, and deploying a version controlled website to a live webserver.

Read part 3 »

For a long time I steered clear of version control, dismissing it as too complex, or something that was only useful for large development teams. I took Subversion for a test drive, but didn’t really “get it”, and decided version control wasn’t for me.

I changed my tune earlier this year when I was employed to work on a project that was already under version control. I had no choice but to get up to speed with Subversion, and once I got the hang of it I was excited to discover that version control streamlined my entire workflow. I now use Subversion for all of my web projects and consider it an integral part of my development process.

My approach to Subversion is geared towards solo web developers like myself, and is fairly easy to grasp. I won’t delve too deeply into the inner workings of Subversion and its commands – this will be more of a conceptual overview of setting up a version control workflow:

Part 1: Getting started with version control
Part 2: Working with Subversion repositories
Part 3: Servers and deployment

What is version control?

In a nutshell, version control allows you to track changes made to a file over time, and roll back to a previous state when you mess up. This might not sound too different to the traditional “save as…” technique offered by virtually every software application, but a Version Control System offers considerably more functionality than simply appending “_v01″ or “_v02″ to your file names. Some of the advantages of a Version Control System are:

• Roll back. Jump back in time and revert a file, folder, or even the whole project to a specific historic state. If you make a mistake in your code you can simply revert to the last good version of the file you are working on.
• Revision messaging. File revisions can be accompanied by messages explaining what changes were made, and why. This makes it possible to track the evolution of a project over time.
• Branching. If you need to test out new features in your project without disturbing the main line of development, you can “branch” your code and continue development in a separate sandbox. Later, you can merge changes back into the main code base.
• Work with a team. If several people are working on the same project, version control helps to synchronise changes so that one team member doesn’t accidentally overwrite another’s work.
• Work remotely. A version controlled project can be accessed from anywhere, any time. This is perfect for geographically remote team members or developers who work from multiple locations.

Why use version control?

In my pre-Subversion days I relied on an ad-hoc backup system whereby I would periodically create a manual snapshot of the project I was currently working on by copying the entire project source to a new directory. I might make a backup once a day, or perhaps every two days. If the changes were small, I might not make a backup at all.

This approach worked well enough, but left me wide open to data loss. Reverting to a previous project state could be a tedious task, requiring that I backtrack further than was strictly necessary.

I also lacked comprehensive metadata about the changes I was making. I did keep brief notes with each backup, describing the changes I had made since the last snapshot, but these notes provided only “broad brush strokes” information about my edits, and lacked detail about which specific files had been modified.

A Version Control System helps to address these problems: snapshots are taken of revisions much more frequently, code changes are easier to document and track, and recovering from coding mistakes is much easier.

Version control for web development

When setting up a Version Control System my initial challenge was to find a workflow that worked for me as a solo web developer. Most of the explanations of version control I read were aimed at software programming teams, and it wasn’t immediately obvious to me how I fitted into the picture. To help me choose a version control approach that suited my own requirements, I began by listing the key components of my web development process:

• Most of the time I work alone on projects, not as part of a team
• I work on projects from the office and from home, using two different computers
• During the development phase of a project I work from an Apache web server, hosted on my local computer
• Most of my websites rely on a MySQL database
• My websites are hosted on a range of web servers, usually in a shared hosting environment, and in many cases I am not free to choose the hosting solution

With those considerations in mind, I needed an approach to version control that allowed for:

• Remote access to the Subversion repository
• A working copy of the repository that could be accessed by my local web server
• The website’s database to be under version control along with the source files
• A deployment process that would work in a typical shared hosting environment

Creating a Subversion repository

The first step in working with Subversion is to create a repository. A repository is a store of data, which holds all of your project files, much like a standard file-system. A repository does a lot more than that though:

What makes the Subversion repository special is that it remembers every change ever written to it: every change to every file, and even changes to the directory tree itself, such as the addition, deletion, and rearrangement of files and directories.
–Version Control with Subversion

The simplest way to create a repository is on your local machine, a task that is made extremely easy by TortoiseSVN (a Subversion client). A local repository is perfect for cutting your teeth with Subversion, but has a major drawback: it can only be accessed from one computer. A remotely hosted repository is a far more powerful and flexible option.

To create a remote Subversion repository you are going to need a web server with Subversion installed. This is not as daunting as it may sound. Many web hosting companies offer Subversion with their plans (I use Dreamhost), or you can choose a Subversion hosting specialists such as Unfuddle, Springloops and Beanstalk.

It is important to note that your Subversion repository needn’t be on the same server as your website. In the development environment I describe in this article there is never any direct communication between the repository and the live web server.

Choosing a Subversion client

Once your Subversion repository is up and running, you need a way to access it. A Subversion client allows you to to read data from your repository (“check out”, in Subversion parlance), write data to the repository (“commit”), and perform other useful actions such as branching, tagging, and merging.

I work in a Windows environment, so TortoiseSVN was an obvious choice for my Subversion client. TortoiseSVN installs as a Windows shell extension, and all of its functionality is accessed via the Explorer context menu – in other words, by right-clicking on a file or folder. This approach is very unobtrusive, and soon becomes second nature.

I won’t go into detail about how to install and use TortoiseSVN. The program is very well documented and there are stacks of online tutorials if you get stuck.

In part 2 and part 3 of this series I will refer to TortoiseSVN when explaining some of my processes. For other Subversion clients the process will be slightly different from what I describe, but the basic principles remain the same. Apple users will find that there are plenty of Subversion clients for the Mac, though I haven’t used any of them and can’t make a personal recommendation – if you have a favourite you can leave a comment below.

In the second part of this series I will explain how I structure my subversion repository, how to create a working copy of your repository, and how to commit changes to the repository.

Read part 2 »

• The original typeface for Safari and Firefox 3.5
• A WOFF font for Firefox 3.6+
• An SVG font for Opera, Chrome, and iPhone
• An EOT font for Internet Explorer
• A sample HTML page
• A sample CSS stylesheet

The generator also features options to reduce file size by subsetting the font, cleanup font outlines, and auto-hint glyphs to improve rendering.

Sweet!

My client has reps in both Shanghai and Beijing, neither of who could see the website, so I knew it wasn’t a localized issue. My immediate suspicion was that the infamous “Great Firewall of China” was to blame. Thankfully I was able to take a few simple steps to diagnose the problem and get the site up and running.

What is the Great Firewall of China?

For anyone who doesn’t already know, the “Great Firewall of China” is the informal name given to the vast Internet censorship apparatus of the Chinese government. Sites considered injurous to the public good are blocked on a massive scale, so that they are innaccessible to Internet users within China.

How to test if your site is blocked

For foreign businesses and web designers who need to ensure their website reaches a Chinese audience, there are several tools which test a site’s availability from servers within China.

WebSitePulse

Website monitoring company WebSitePulse offer a free service to check if a website makes it past the Great Firewall of China. You can test your site using servers in Beijing, Shanghai and Hong Kong. WebSitePulse also do a side by side comparion with servers in the US, Germany or Australia, so you can compare the responses.

WatchMouse

WatchMouse offer a free service which pings your website from a number of servers worldwide, including one in Shanghai. If your website is being blocked, the Shanghai server will report 100% packet loss.

Why me?

One of the common methods of censoring a site is by IP blocking. Unfortunately, if the banned site is on a shared web host, all sites that share the same IP address are also blocked. This is what I believe happened in my case.

The fix

Luckily there is a simple workaround to sidestep issues with using a shared IP address: buy a static IP address. If your website has a unique IP address then it can’t be blocked simply because it shares a server with a banned site.

Within an hour of purchasing a static IP adress, my client’s website could be reached from within China. WebSitePulse and WatchMouse’s Chinese servers could see the site, and more importantly, my client’s reps in Shanghai and Beijing could too.

This is not only a great way to try Opera Mini 4 before downloading, it’s also handy for web designers curious to see how their sites hold up on a mobile device. Like previous versions of Mini, Opera Mini 4 processes web pages on the server, and reformats them to fit the screen of your mobile device. This reduces bandwidth consumption dramatically, and makes pages easy to read even on small screens. In what appears to be a nod to the iPhone, this time around the browser combines full screen and zoomed-in views, instead of squeezing an entire page into one long column. The genius of Opera’s approach is that text is still reformatted to fit your screen width, so multi column layouts will appear as several columns of narrow text that neatly wrap within the browser window.

Unfortunately the Opera team are still working out some kinks which stop the beta installing on my Samsung d900i, so for now I’m still stuck on Opera Mini 3. But judging by the simulator, the upgrade will be well worth waiting for.

Update: I downloaded the latest beta, and it now works on my phone. The only downside – no RSS reader in the beta, so it looks like I will still be stuck with Opera Mini 3 until the final release of version 4… Sigh.

When I bought my first web hosting account back in 1999 I had no idea what I wanted from a hosting company. I went with a recommendation from a more experienced colleague, and wound up with a fairly pricey – although fast – shared hosting account. At the time I don’t think I even considered basic criteria such as disk allocation, bandwidth allowance or server-side scripting support. As it turned out the host was running the Cold Fusion programming language, which even in 1999 must have been extremely unusual!

In those happy-go-lucky days clients placed few technological demands on their web designer, beyond the simple requirement of getting a website online. For a newbie like myself that was about the extent of my abilities anyway, and as long as a web host gave me FTP access I was happy. But as the medium has matured so have the needs of both clients and designers, and today I am much more careful to select a hosting package that suits my requirements.

Hosting platforms

Most web hosting plans fall into one of two categories, determined by which operating system they run: Windows or Linux. This in turn dictates the programming languages, databases, and software packages available to a designer. For this reason, the choice of platform is a fundamental one when deciding on a hosting solution.

The most prevalent web server configuration is is known as a LAMP stack, comprising the Linux operating system, Apache web server, PHP programming language, and MySQL for database management. Linux hosting plans also often offer support for the Ruby and Perl programming languages. The fact these are all open source software solutions means that Linux hosting tends to be cheaper than Windows.

With about 32% of the server market, Microsoft’s Internet Information Server (IIS) running on Windows is also an extremely popular hosting solution. IIS is usually coupled with the ASP.NET programming framework and MS SQL database management. Windows servers often offer PHP and MySQL support too, which makes them a flexible – albeit more expensive – option.

I’m not going to argue the comparative merits of Windows and Linux hosting, suffice to say that familiarity with a platform is usually the deciding factor. Pingdom did and interesting survey of seven of the most popular sites on the Internet to see what server configuration they were running on, and found that the decision to use a particular technology was usually motivated by familiarity. It makes sense – we are much more likely to choose technologies that suit our skill set rather than the other way around.

Shared vs dedicated hosting

Regardless of the software platform you settle on, you will also need to decide between a shared and dedicated server environment.

A shared hosting plan is where a large number of websites are located on a single server box, and share the computer’s resources. The hosting company takes care of server maintenance, software installation, backups, and bandwidth management, which makes shared hosting a painless affair. In addition to simplicity, a big advantage of shared hosting is the price. Because the web server is shared between many customers the cost per business is lower.

But there is a downside to hosting numerous sites on a single machine. If a neighboring site experiences extreme traffic demand, other sites on the server are likely to slow down too. You are also limited to whatever server configuration your hosting company decides is best. For instance most web hosts don’t give shared hosting customers access to their domain’s PHP ini (configuration) file.

If you don’t like to share then you’ll want a dedicated hosting account, with your very own web server at the hosting company’s data center. Your server will still be managed to a degree by the hosting provider, who will typically take care of data backups and performance monitoring. Scalability is the single biggest advantage of dedicated hosting, and because the server’s resources are reserved solely for your use dedicated hosting is perfect for high traffic websites. For a web design firm a dedicated server can also be used to house a number of client websites, allowing you to balance the server’s resources to suit the requirements of each site.

A third option is co-location, in which you provide your own server machine, and plug it into a service provider’s Internet pipeline. This gives you total control over your server, but isn’t an option you will want to pursue unless you are skilled in server administration and hardware configuration.

Server-side programming

One thing to be wary of when choosing a hosting package is to make sure the server, programming, and database management software are configured in a way that suits your requirements. Lets take PHP as an example.

In version 5 and earlier PHP offered a ‘safe mode’, designed to limit the possibility of malicious PHP code being executed, and protect servers from hackers. Nice as that may sound, safe mode also severely limits web developers from performing even straightforward tasks such as uploading files to their server via PHP. Some hosts install PHP with safe mode turned off, while others such as Dreamhost and Media Temple offer a way to effectively disable safe mode on a per-site basis. Unfortunately, most hosts have no such option, which means many popular PHP scripts will not run on their servers without some serious tinkering.

Similarly, the speed with which hosting companies update their software installations can differ quite significantly. For instance, if you are developing in PHP 5 then obviously you will need a host that has PHP 5 installed, whereas a large number of hosts still only offer PHP 4. Most web hosts will specify somewhere on their company website what software versions they run. If they don’t, make sure to ask.

Disk and data allowances

Exponential increases in hard disk space have meant that even the cheapest web hosting plans now offer ample file storage. Gone are the days of 10Mb hosting plans, so hosting video and other disk hungry files is no longer a major drama. Still, it is worth paying attention to the storage limits imposed by your web host, especially if you plan on hosting multiple websites under a single account.

As well as dictating the amount of disk space your site(s) can utilize, web hosts set a data transfer limit. This is a measure of how much data can be transferred between your web server and the Internet each month – in other words, how much your visitors can download before you are penalized. Traffic allowances vary greatly from one host to the next, so it is important to estimate your requirements accurately and choose a plan that meets them.

One hosting company I have used in the past states on their website that a 2Gb monthly traffic allowance should be sufficient for most small or medium business websites. Having designed a number of sites for small businesses I can say that this is not the case, and even a moderately successful site can easily exceed that limit.

If you think you may exceed the bandwidth limit set by your host, it is important to check the rate at which they charge for excess traffic – sometimes excess data charges can be exorbitant.

Control panel

Smaller hosting firms often require that you contact their support staff any time you need a change made to your account. When even something as simple as setting up an email autoresponder requires a phone call, it can be extremely frustrating. Thankfully most hosts offer a web-based control panel that allows you to customize almost every aspect of your account. Some larger hosts offer a comprehensive custom built control panel, but most opt for a generic panel such as the popular cPanel or Plesk.

When considering a host it is worth considering the control panel you will be using, as a good panel will make website maintenance simpler and more pleasurable.

Reseller hosting

Reselling hosting to your clients not only saves you having to purchase new hosting account for each client, it can turn a tidy profit. Reselling involves purchasing one hosting account, then subdividing it into multiple sub-accounts, one per client. This allows you to set your own pricing structure, and sell hosting to your clients at more than its original value.

In practice, any hosting plan that allows multiple domains can be resold, but many web hosts offer accounts that are purpose built for reselling. These reseller packages mask the identity of the hosting company, so it appears to your clients as if you are the host.

Local vs offshore hosting

Unless your website’s primary audience is in the US, choosing to host on a web server located in your own country may offer significant speed and reliability benefits. The downside to local hosting (by which I mean non-US hosting) is that it tends to cost more. Most of the large scale hosting companies (Go Daddy, Dreamhost, Media Temple etc) are based in the US, and economies of scale mean that local operations cannot compete with them on price alone. But there are compelling advantages to local hosting, even despite the fact it is more expensive.

The primary reason for choosing local hosting is speed. It’s a simple matter of geography: the further your end-user is from your host’s data center, the longer the traffic is going to take to reach them. I live in Australia, where hosting on locally based servers generally costs more, but is considered vastly more desirable due to the speed boost when serving pages to an Australian audience.

Another advantage of local hosting is that server maintenance is timed to coincide with off-peak traffic in your time zone. Any sensible web host will perform scheduled server maintenance during the wee hours of the morning, when web traffic is at its lowest. But what may be middle of the night in Texas or LA is the middle of our working day in Australia, meaning routine maintenance can kill my client’s email access and take their website offline.

For those readers who are based in the US, the local/offshore distinction is irrelevant as you already get the best of both worlds: low cost hosting in the same country as your primary audience.

Reliability and performance

While cost is inevitably a consideration when choosing a web host, it is dangerous to make a decision based on price alone, as cheap hosting often comes at the expense of server reliability and performance. A common measure of reliability is uptime, the percentage of time that a web host’s computers are up and running. A website needs to be available around the clock, and every moment offline equates to lost visitors and income, so choosing a host with a high uptime is critical. Most hosts promise 99.9% uptime, but don’t take their word for it. Check with a host to see if they records of their outages, or ask one of their customers for their anecdotal experiences.

Many hosts also have redundant servers, waiting to kick into action if the primary servers go down. Ideally, redundant servers will be housed in a separate data center to the host’s primary servers, so that in the case of a power outage or natural disaster they will be unaffected.

Another critical measurement is the speed of a host’s servers. This is influenced by many factors, including their network infrastructure, connection to the Internet, and whether they oversell their hosting plans. A host will usually offer information about their network and data center on their company website, but overselling – cramming too many websites on a single shared server to maximize profits – is harder to detect. In most cases overselling has no ill-effect, since few customers will ever use their full bandwidth and disk allowances, but it is still something to be aware of.

To test the response time of a host, you can ping a site that is hosted with them. In Windows you can do this by opening a command prompt, and typing ping domain, for example ping google.com. This will tell you how long data takes on average to reach your computer from the website. This is a useful way to compare the speed of two different webhosts.

Conclusion

Choosing a web host isn’t as easy as typing ‘web host’ into Google and clicking on the first search result, but provided you do your research it’s not hard to find a service that suits your needs. I hope that this article has made you aware of a few of the pitfalls that await the unwary.

Although I have mentioned a couple of web hosting firms and software solutions by name, that’s not because I think they are the best around, but rather they illustrate a point I was making. There are a vast number of hosting companies out there, and obviously I have personal experience with only a fraction of them. During the article I also talked in greater detail about Linux/PHP hosting environments than other alternatives. That’s because I am most familiar with LAMP servers, not because I think they are somehow better.

If you have your own web hosting experiences or tips to share, please leave a comment below.