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.

I haven’t tested it out, as I do in fact have RC1 installed as my ‘official’ version of IE, and use a standalone version of IE6 for backwards compatibility testing. It looks good though, and appears to be a ‘proper’ standalone version which fully identifies itself as IE7, meaning conditional comments ought to work fine.

For anyone running older IE6, 5.5, or 5 standalones that don’t support conditional comments, I recommend you read Manfred Staudinger’s article on the topic, which will solve your woes.

Why would I want a standalone anyway?

Since you can only have one version of Internet Explorer installed on a single Windows system, testing a website across multiple versions of IE very difficult. That’s where standalones are very useful, allowing you to run multiple versions of IE side by side on the same machine. For web developers this is a must.

Without further ado, here’s the list:

Web Development

Developerside Server Suite and XAMPP

If you’re like me – and the majority of web designers – you rely on PHP as the server side scripting language that powers your websites, and MySQL as your database solution. That’s all fine and well, but uploading your PHP files to your web hosting account to test them *every* time you make a minor change gets old *real* fast. The solution is to install a WAMP (Windows Apache MySQL and PHP) web server on your local computer. Installing a web server isn’t as scary as it sounds, thanks to the availability of all-in-one web server distributions aimed at individuals and small businesses. I cut my teeth on the Developerside Server Suite, which is an easy WAMP installation, fully configured and ready to run. It’s as simple as unzipping the files, running a few command-line instructions, and firing up your web browser. From then on you can develop sites locally with all the goodness of MySQL databases and PHP, and only need to upload files to your web hosting account when the job is complete.

Although the Developerside server suite is the only WAMP package I have experience with, I know of many people using XAMPP. You may like to compare the two products to see which takes your fancy. XAMPP is available for Linux as well as Windows and Mac OSX.

PHP Designer

If you write a fair amount of PHP code, a PHP IDE (Integrated Development Environment) might help you code faster and smarter. The best known IDE’s are commercial products (Zend Studio and NuSphere PhpED), but there are a few good free PHP editors to choose from. PHP Designer has a free version for personal use that includes a code debugger, syntax highlighting, code tips, and a number of shortcuts for adding common PHP statements and HTML tags to your documents. Think of it as a text editor on speed. A more fully featured version on PHP Designer is available for USD$69, although if you’re going to splash out you should probably investigate some of the other commercial IDE’s on the market to make sure you get the best bang for your buck.

A little tip for getting the most out of PHP Designer: Turn on all of your toolbars (Format, Forms etc). The toolbars give you quick access to all the commonly used commands, but for some reason they are turned off by default.

SmartFTP

When it comes to FTP applications you want something that you can quickly fire up, connect to a server, and transfer files across. SmartFTP does the job, and throws in those handy extras like a favorites list, easy CHMODing of files and folders (that’s setting Unix file permissions), filtering files (so for instance you can choose to skip files of type *.fla and *.bak when uploading), and a nifty file transfer queue.

Firefox

The release of Firefox shook up the web design industry by challenging Microsoft’s stranglehold over the web browser market, and it’s still the best browser out there. These days other web browser might match it for web standards support, but when you throw a thousand or so extensions into the mix, Firefox is the clear winner. It’ll be interesting to see how the final release of Internet Explorer 7 changes the playing field, but for now I build sites for Firefox then tweak them to work in IE.

Web developer toolbar for Firefox

Speaking of firefox extensions, this baby is the web developer’s best friend. Edit a page’s CSS on-the-fly, display detailed information about every page element, validate HTML and CSS from within the browser, disable images, resize the page, run a javascript console. Is there anything this handy toolbar can’t do? Basically, no.

HTML Validator extension for Firefox (based on HTML Tidy)

OK, there is *one* thing the web developer toolbar can’t do. It can’t validate your pages locally. Instead it relies on the W3C’s online validation service. That’s where the HTML Tidy extension steps in. It also displays a handy icon in Firefox’s status bar letting you know if a page validates. That little icon will revolutionize the way you work by telling you at a glance if your pages are valid, and you can say goodbye to round trips to the W3C validator every time you modify a page. And as you’d expect from a Tidy extension, it can clean your HTML code for you, right from within the browser.

PuTTY

If your web host offers you shell access to your server, then you’ll need an SSH client to make the connection. Grab a copy of PuTTY and in no time at all you’ll be pulling the mad unix command line styles.

Office Productivity

Mozilla Thunderbird

From the folks that gave us Firefox comes the lean n’ mean Thunderbird email client. So far Thunderbird has failed to set the world on fire the way it’s web browser sibling has, probably because Tbird takes it’s lead from other email clients – notably Microsoft Outlook – rather than blazing new ground like Firefox did. However it still does a great job as an email client, and as you’d expect from a Mozilla product it can be augmented by a number of community created plugins.

Sunbird

Thunderbird lacks the day planner and task organizer that Outlook boasts, and that’s where Sunbird steps in. It’s still an alpha release, so don’t expect perfection, but Sunbird sports most of the features you need to keep your life organized.

OpenOffice.org

Have a chip on your shoulder about using Microsoft products? OpenOffice.org lets you break the shackles of corporate oppression with a fine set of Office productivity tools designed to rival Microsoft Office. Writer is the pick of the bunch for me, offering an alternative to Microsoft’s Word. It does a damn fine job too, and even reads and writes to Word format so you won’t find yourself shunned by Microsoft devotees.

Mozy

If you read my review of Mozy a few months back you’ll know that I was highly impressed with the ease with which the product automates online backup of your important data. For a web developer that means you can ensure that development files for your current projects are always safely backed up, and you barely have to think about it. 2gb of storage – and peace of mind – for $0 is a sweet deal in my book.

Trillian and Gaim

It seems like a good number of people rely on instant messaging these days to conduct realtime conversations with friends and colleagues, rather than the telephone. Unfortunately the major IM protocols don’t play to well together, but with a little help you can have all of your IM accounts and buddies happily cohabiting. Trillian and Gaim are the two multi-protocol IM clients I have experience with. Unfortunately neither application is perfect, and when transferring files with your buddies both clients show their weakness. I have found Gaim to become unresponsive when receiving a file, and Trillian to upload files at very slooooow speeds. In any case, it beats running ICQ, MSN and AIM all at the same time!

Here’s a gotcha for Trillian: The application comes with some of it’s shortcut keys configured the same as Photoshop. Except Trillian will ’steal’ the shortkey even when Photoshop has focus. You can disable the shortcut keys in Trillian’s preferences, which will put Photoshop back in the driver’s seat.

I make a regular habit of backing up projects to CD/DVD, but I’m not fanatical enough to burn a backup disc every single day. An external hard-drive would give peace of mind against hard drive failure, but it’s reasonable to assume it wouldn’t get left behind in a burglary or magically escape damage in a fire. Clearly a regular off site backup method is required to give bulletproof protection.

One studio-mate suggested online backup. At the time I dismissed the concept as too bandwidth and disk hungry. With the massive photoshop and video files I deal with on a daily basis it might take days to perform a backup, and the cost of storage would be astronomical.

Later I gave the idea more thought. What if I were to use an online backup service to protect only my critical files. As a web designer, I consider my website source files (Flash .fla’s, actionscript files etc) and deployment files (HTML/CSS/JS/SWF/XML files and website folder structure, mySQL databases etc) to be my most valuable assets. If those files are safe, then my client’s website’s are safe. Semi-regular CD/DVD backups would continue to take care of the larger files, with online backups providing protection against losing the day’s work.

The hunt is on!

I quickly discovered that there are now a plethora of online backups services to choose from. Most seem fairly fresh out of the starting gate, and the features and cost of each vary considerably.

One product seemed a particuarly good match for my requirements. It’s called Mozy, and it’s free to signup for their basic plan, which gives you 2GB of storage space, and allows you to recover your data up to 4 times a month should you need to. If that sounds too restrictive, you have the option to sign up for Mozy’s month-to-month $1.95/5GB, $4.95/30GB or $9.95/60GB plans. The Mozy application is currently only available for Windows XP, but a Mac client is on it’s way.

Mozy works by performing incremental backups, meaning only files that are new or have been modified since your last backup will be uploaded. The initial backup can take some time to complete, but after that backups should take between 10 mins and 1 hour – depending how frequently you modify the files in your backup sets.

Configuring Mozy

Once the Mozy application is installed you have the option to schedule backups and configure backups sets. Mozy comes with a number of pre-defined backup sets, covering the needs of your common home user. I removed the default sets and created my own, which was as simple as using a Windows file browser to locate the folders I wish to include in a set. There is the option to filter files that are included in a set based on file extension, size, creation date and modification date.

Running Mozy

There is no option within Mozy to disable scheduled backups, however you are still able to manually start a backup whenever you wish. I’ve got Mozy installed at home and at work (you need a different account for each computer you install Mozy on), each scheduled to backup daily. Backups occur in the background, and usually I don’t even notice that they have started. Occassionally I can detect a slight slowdown in computer processing speed during backups, but not enough to disrupt my workflow.

Restoring files

This is what really sold me on Mozy. When you choose to restore files, it delivers them back to you as a zip file containing a exact replica of your original folder structure. You can choose to restore individual files or folders, in any combination you choose, from backups as much as a month old.

Security

Mozy uses 448-bit Blowfish encryption to encrypt files on your PC, then transfers them to the Mozy server using 128-bit Secure SSL encryption. I’ll be honest, I don’t know what Blowfish encryption actually is, but it sounds robust – in a fishy kinda way! Of course, once your data is actually on the Mozy servers, I guess you pretty much have to put your trust in Mozy’s staff to keep it private. Bottom line, if you’re backing up top secret government documents, you’re probably a lot safer keeping them offline, but for the average Joe, Mozy should be more than secure enough.

The bottom line

As you can probably tell I’m fairly chuffed with Mozy. It’s gives me peace of mind to know that my current projects are backed up on a daily basis, and it’s given me a new toy to play with! Due to the comparitively slow network speeds of online backup services I don’t think they can provide an all-in-one backup solution, but they definitely have a place in the backup arsenal. I’m planning to also invest in an external hard drive to perform full system backups, but for my day-to-day needs Mozy has me covered.