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!

The trouble is that digital fonts have no provision for DRM, and pirating a copy of an embedded web font is a trivial exercise for anyone with the mind to do so. That’s obviously not a prospect type foundries are too keen on, and consequently no major foundry offers a licensing option for embedding their fonts in a web page. If you link to a commercial font from your CSS stylesheet the chances are that you are breaking your license agreement. Even the number of free fonts with an EULA that condones @font-face embedding is pitifully small.

That’s where Typekit comes into the picture. Typekit is a new font delivery service devised by Jeffrey Veen that promises to take the pain out of licensing fonts for web embedding. In their own words:

We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.

Here’s how it works:

• Typekit strike up agreements with type foundries allowing fonts to be licensed for CSS linking.
• Web designers subscribe to Typekit, and pay a monthly fee to embed typefaces on their websites using an @font-face declaration.
• Would-be font pirates are deterred from stealing embedded Typekit’s fonts by security measures including: allowing only authorised domains to link to their fonts; source code obfuscation; and splitting fonts into multiple files.

Problem solved, right? Well, perhaps.

Typekit’s font-as-a-service model navigates a clever path through the legal minefield of web font licensing, but I am not convinced that it is a perfect solution. In particular there are two aspects of Typekit’s approach that strike me as problematic: the fact that their pricing model is based around renting fonts rather than owning them, and the need to rely on remote servers for the delivery of fonts.

Renting vs buying

Because Typekit is still in beta details of its pricing are sketchy, but it is clear that customers will pay a monthly or annual subscription fee to access Typekit’s font library. This pricing model is significantly different to the traditional one-off payment required to license fonts for offline applications.

Will website owners be prepared to continue paying for a font month after month, year after year? Over time Typekit subscription fees could conceivably exceed the cost of a standard font license, despite the fact that Typekit’s fonts cannot be reused in any other medium, or potentially even on another website. And if you ever cancel your Typekit subscription, the fonts vanish into thin air. This is a radical departure from the current font licensing model, which grants customers the right to perpetually reuse any fonts they purchase.

Purchasing fonts twice

In addition to the fact that font subscription models require designers to pay for fonts they can’t reuse, in most cases it will also be necessary to purchase a regular installable version of each typeface.

To produce mockups and work on a production version of a website, a web designer needs to work with the same typefaces that will feature in the final live site. Typekit only offer web embedding of fonts, so to install a typeface on their local computer a web designer would have to purchase a separate font from another vendor. It’s not going to cut the mustard to produce mockups set in Arial and tell the client to “imagine that the headings are actually Avant Garde”!

When you also consider that many websites have multiple domain aliases (mysite.com, mysite.com.au, etc), and Typekit uses a per-domain pricing model, it is clear that the potential exists to pay many times over for the same font.

Network reliability

Another potential problem with Typekit is network downtime.

I can’t imagine many designers would trust their CSS files to a remote delivery network, and I think we need to accord fonts a similar importance. If major players like Google and Amazon suffer network interruption from time to time, then it is reasonable to assume that Typekit will too.

Admittedly, occasional network outages may not be a deal breaker, what happens if Typekit goes out of business, or a foundry retracts the right for Typekit to distribute their fonts? In either of these scenarios it seems probable that Typekit subscribers would have the fonts rudely stripped from their websites. In a best case scenario subscribers could turn to a Typekit competitor such as Fontdeck to revive their font links, but what if no competitor offered the same typefaces? The design of countless websites could be irrevocably ruined due to their dependence on remotely hosted fonts.

The future of font embedding

Despite the reservations I have outlined above, I have to agree with Andy Clarke when he predicts that Typekit will change everything.

By coming up with a practical answer to the problem of @font-face licensing, Typekit has paved the way for alternative font embedding approaches. Clearleft and OmniTI have joined forces to create Fontdeck, and at least one foundry, Typotheque, has a web font service under development.

Soon there will be a number of services vying with Typekit to win the hearts (and wallets) of web designers, however I suspect the deciding vote will ultimately be cast by large font foundries such as Linotype and Adobe.

The type industry’s major players will need to decide where they stand on the issue of font embedding, or they risk being left behind while smaller type foundries reap the benefits of web font licensing. If they follow the lead of their counterparts in the music industry it might be years before our @font-face woes are sorted out. On the other hand they might choose to take the bull the horns and launch their own font hosting services to compete with Typekit.

Whatever the response of large type foundries and vendors turns out to be, it will very likely determine the future of typography on the web. Hopefully we end up with a solution that is fair to web designers, website owners and font foundries alike.

Further reading

Introducing Typekit

Jeffrey Veen announces the arrival of Typekit, and explains the basics of how the service will work.

Ubiquitous web font embedding just got a step closer

John Allsopp argues the case for more liberal font licensing. Recommended reading.

First impressions of Typekit

A step-by-step tour of the Typekit beta.

On Typekit

David Yeiser shares some of my reservations about Typekit.

The Font-as-Service

Jay Elliot Stocks gives an overview of Typekit and its competitors.

Testing Typotheque @font-face embedding

Andy Clarke takes Typotheque’s new web license for a spin. It is interesting to note that Typotheque requires a one-off payment rather than a subscription like Typekit.

But today I came across Scaffold, a CSS framework that made me rethink my position.

Scaffold differs from traditional static CSS frameworks in that it runs on a web server, and acts as a compiler. Scaffold extends the power and functionality of CSS by parsing each of your CSS files using PHP and generating browser-readable stylesheets on-the-fly. Some practical benefits of this approach are:

• Automatically cache and compress CSS files
• Declare constants in your CSS file and reuse them later in the stylesheet
• Call mixins (functions) from your CSS selectors
• Evaluate portions of your CSS as PHP
• Nest CSS selectors

Ruby users will be familiar with many of these features from Compass and Sass, but Scaffold brings server-side CSS to the Apache/PHP user base.

Extending scaffold using plugins

Scaffold’s feature set can be extended using plugins. In addition to bundled plugins for compression, image replacement and generating human readable output, there are plugins for targeting specific browsers, creating grid layouts, and extending selectors (true OO CSS!).

How it works

Scaffold works by routing your CSS files though its PHP library, parsing your Scaffold code, and generating a standard CSS styleheet which is returned to the browser. Installation is a matter of dropping scaffold into your CSS directory, modifying a few settings in a PHP config file, and setting Apache folder permissions for the directories that Scaffold needs to write to.

You have two options for passing files to Scaffold: route all CSS requests to Scaffold via .htacess, or change the CSS links in your HTML so that they point to Scaffold.

<link href="scaffold/index.php?request=screen.css" />

Scaffold is definitely a CSS framework I could learn to love, and I’m really looking forward to using it in a project. Compared to the current batch of static CSS frameworks Scaffold looks like a big step forward.

Hinting

The reason Arial looks good at small point sizes is because Microsoft pay a lot of attention to the hinting of their web fonts so that they render well on screen.

To quote Wikipedia’s article on Font Hinting:

Font hinting is the use of mathematical instructions to adjust the display of an outline font so that it lines up with a rasterized grid. At small screen sizes, with or without antialiasing, hinting is critical for producing a clear, legible text for human readers.

Fonts that have not undergone a rigorous hinting process tend to look fuzzy or poorly spaced when forced to align to a computer monitor’s pixel grid. Helvetica is a case in point: it renders very well on Mac systems even at small point sizes, but on Windows systems it looks, frankly, crappy.

Arial vs Helvetica

To demonstrate, here is a comparison between Arial and Helvetica on a Windows system. You will notice that Arial’s anti-aliasing is much crisper than Helvetica’s at larger sizes, and that Helvetica’s kerning falls to pieces at sizes smaller than 12px. These defects are especially evident when viewing an entire webpage set in Helvetica.

I performed the test above in Firefox 3.5 and Internet Explorer 8 on Windows Vista, using both Adobe’s OpenType Helvetica LT Std and a Linotype PostScript version of Helvetica, with identical results.

Arial on the Mac

On a Mac the story is quite different. Arial and Helvetica look virtually identical (as they should), and both remain perfectly legible at 8px. This might be because Apple’s font rendering engine is superior to Microsoft’s ClearType, or perhaps the version of Helvetica that ships with Mac OSX has been hinted to retain legibility at low resolutions.

Whatever the case, the fact remains that Arial looks better on Windows than Helvetica does. Does this make Arial a superior font than Helvetica? Not by a long shot. But it does serve to illustrate Arial’s suitability for the Windows environment, which still accounts for over 90% of all web traffic.

Does Arial deserve reconsideration?

So what do you think – does Arial’s superior hinting on Windows systems elevate it beyond the status of a substandard Helvetica clone, or is it beyond redemption?

A note about Win/Safari

If you use Safari on a PC you may have noticed that Arial renders differently than than in the screenshot I provided. In fact, it renders exactly as it would on a Mac. That is because Safari offers the option to use Apple’s font rendering engine rather than Microsoft’s ClearType. Sadly I couldn’t test whether Helvetica’s rendering was similarly improved in Win/Safari, because Safari refuses to recognise any of my non-system fonts. If anyone can shed light on this issue, please leave a comment below. I’m very curious to know if Helvetica’s substandard appearance on Windows can be attributed to a deficiency in ClearType rather than a deficiency in the font (I suspect the former).

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.

IETester is a web browser that can run the IE5.5, IE6, IE7, and IE8.1beta rendering engines in the same process. It has a tabbed interface which makes switching between different IE versions a snap, and although it is only an alpha release it seems to work fairly well.

Personally, I’m still a fan of running IE6 in VirtualPC, using the virtual machine provided by Microsoft specifically for this purpose. No quirks or bugs, just the real IE6 running within a real Windows XP installation. But if for some reason you can’t or won’t run VPC, IETester provides a workable approach to testing in IE6 & 7 side-by-side.

Version targeting in Flash

Version targeting in Flash works in much the same way as it will in Internet Explorer: each Flash movie contains embedded information telling the Flash Player which version of Flash it was created for, and the Flash Player itself contains multiple rendering engines to handle legacy content.

This approach to backwards compatibility has been a feature of the Flash Player since its earliest incarnations. The latest version, Flash Player 9, supports content produced for FLV (Flash video), SWF9, SWF8, SWF7, SWF6, SWF5, SWF4, SWF3, SWF2, and FutureSplash. That means that Flash content created in 1995 still renders perfectly in 2008. Flash developers can have a great deal of confidence that an application they create today will continue to work in the future without any need to revisit it*.

Why have Adobe worked so hard to ensure the Flash Player is compatible with legacy content? I think the answer lies in the commercial nature of Flash. Because Adobe relies for its livelihood on the continued patronage of website developers, they need to keep that customer base happy. Flash would never have gained traction if developers were forced to rework their legacy websites every time a new Flash Player version is released – I can’t imagine anyone paying $700 for software that generates code that breaks every eighteen months!

Does backwards compatibility hamper progress?

Let us consider my concerns about version targeting, and see if they have been borne out in Flash: Has backwards compatibility hampered progress in the Flash industry? Has it slowed adoption of the Flash Player? Has it stalled advances in Flash technology? I think the answer to these questions is “no”.

One metric we can use to gauge the rate at which advances in Flash are taking place is to look at Flash Player adoption rates. A fast adoption rate by end users is a sign that users are encountering Flash content targeting the latest Flash version, and are upgrading their player in response. Even before the introduction of an automatic update feature, adoption rates for the Flash Player were very high. From the time a new Player was released, it would achieve 55%-65% market penetration within 6 months. This is a good indication that Flash developers are quick to take advantage of new features in Flash.

Another measure of technical progress is the rate at which new features are added to the Flash Player (as opposed to the Flash authoring tool, where some changes will be merely cosmetic). During the past four releases there have been three complete overhauls of the Flash programming language, the introduction of powerful video functionality, bitmap effects (motion blur, dropshadows, etc) and filters, to name just a few new features. Because version targeting ensures there is no pressing need for Flash developers to upgrade, Adobe needs to continually improve Flash’s feature set to give its customers a compelling reason to purchase an upgrade license. Rather than stymieing progress, version targeting actually encourages technical advances in Flash.

A personal perspective

I worked as a full-time Flash developer for four years, and Flash development still accounts for about half the work I do. Until this week I hadn’t given much thought to the impact of version targeting in Flash, but on reflection I see that it has compelling benefits for end-users, seasoned developers, and Flash novices alike.

Flash has a very healthy development community keen to push the boundaries of their medium, and even though version targeting enables many developers to work at a lower level, I don’t see any evidence that this skill gap impedes advances in the field. I myself still publish content targeting Flash Player 8, and am familiarizing myself with the new ActionScript 3 programming language in the meantime. I certainly don’t feel that I am holding anyone back by learning at my own pace!

I also consider that version targeting goes a long way towards easing the Flash developer’s workload. If I build a site targeting Flash Player 8, I know without testing that it works in Flash Player 9 too, and vice versa. I know too that I will never need to “fix” that site to comply with a future Flash Player release. This forward compatibility is something that I take for granted when I develop a Flash site, and the idea of ‘fixing’ my legacy projects every couple of years seems totally absurd. Yet for some reason this “break and fix” cycle is considered perfectly normal for HTML websites.

What’s good for the goose

Of course, comparing Flash Player with a web browser is not like comparing apples with apples: Flash and Internet Explorer have very different business models; Flash has no serious competition whereas Internet Explorer is part of a busy browser ecosystem; Adobe is free to introduce new features to Flash as it sees fit whereas Microsoft is beholden to various working groups; the upgrade cycle of Flash is driven by web developers rather than software vendors. What works for Flash may not necessarily work for Internet Explorer.

Yet I believe there are enough similarities to draw a comparison. Flash shows us that under the right conditions version targeting can actually be beneficial for everyone involved in the development, delivery, and consumption of content for the web.

Footnotes

* There is only once exception I can think of: new ’sandbox security’ restrictions introduced in Flash Player 7 caused some older Flash applications to break.