Choosing the services to compare

I’ve tried to select VPS and Cloud instances specifications that are broadly equivalent in terms of RAM, disk space, and bandwidth offered for this study. What’s not so obvious is the computational power offered, and I’d like to state that I’ve benchmarked nothing at all, so don’t take this as a scientific recommendation, just my take on a big topic.

The VPS baseline is comprised of some tried and tested, and trusted, services.

• A bottom of the range 512MB Memset miniserver VPS, which is a low cost baseline I’ve used for years.
• A comparable 512MB Slicehost VPS.
• A Brightbox Nano VPS, which is comparable to the Brightbox Cloud instances I’m trialling.

Things weren’t so simple in the Cloud.

Most VPS services come with a fixed amount of monthly bandwidth included in the price, but their Cloud equivalents exclude bandwidth. Cloud bandwidth is charged by unit of resource you use, per GB for example, and often at a different rate for incoming and outgoing traffic. These costs are largely independent of the type of instance, so happily for my analysis they don’t reduce my options.

Rackspace make the point that the AWS offerings are much higher specification than needed by most web applications, and I found that it’s a valid claim that ruled out all but the Micro instance.

So, in the end I chose these options for the Cloud team.

• AWS Micro On Demand instance
• AWS Micro Reserved instance, which is the same but incurs a booking fee upfront in exchange for lower hourly rates.
• A 512MB Rackspace instance that’s hopefully comparable to the Slicehost VPS above.

Unfortunately Amazon have complicated the economics of the Micro instance by removing all storage. This is provided by attached EBS – bless Amazon and their abbreviations – which is priced according to it’s own model based on volume size and the number of requests: another cost to consider alongside bandwidth.

My analysis

To simplify things, I’ve used the baseline Memset VPS service as the benchmark against which to assess the other options, but something to note is that some of these services were prices in USD and others in GBP. Attempting to make this as consistent I drew up a list of assumptions for this analysis.

1. Production has 8760 hours of annual use.
2. Staging has 1152 hours of annual use.
3. Exchange rate of 1.6 (USD/GBP).
4. I/O request rate of 1.3 requests per second.
5. Production traffic is split 90% outgoing and 10% incoming.
6. Staging bandwidth is split evenly between outgoing and incoming traffic.

I then tried running my model at under three traffic conditions that I consider to represent low, medium and high volume. These were 10GB, 50GB and 100GB per month respectively; trust me, I don’t need to worry about anything higher at the moment.

OK this makes Brightbox seem very expensive, and it is, but I should point out that their Nano VPS is backed by a separate MySQL cluster and includes a New Relic standard account. None of the other providers do any of this, but since they’re one of my current hosts I’ve added them anyway. After all, I did this analysis primarily for my own benefit.

Oh, and the step change you can see in the cost for Memset under high traffic was due to a one-off fee for increased bandwidth, the base allowance is 50GB/month. The other VPS services had sufficient allowance for all my test cases.

So how does the Cloud stack up in production?

It seems that these bottom end instances are relatively competitively priced against these VPS services, with only Memset offering me a better deal. The costs also scale directly producing a nice smooth progression in expenses as traffic increases.

As mentioned before, an AWS reserved instance requires an upfront commitment that’s a large proportion of the total annual cost. That’s fine if you’re sure you’re going to use it throughout the year, as a production server probably, but it’s not very Cloud-like. Still, under these conditions it does appear to offer overall savings relative to all the competition except Memset at intermediate loads.

If you can afford a production Cloud, testing is even better

The real advantages come if you’re in a position to use an identical platform for production and testing. If the cloud is competitive with a VPS at your routine levels of traffic, then it’s going to offer even better value as a pre-production testing environment.

I decided that the best way to investigate staging in the Cloud was to reduced the number of hours I’d need the instance for each month, scale the bandwidth proportionally, and rerun the original model. I chose an arbitrary 96 hours (4 days) each month for testing purposes, it could be more, but could quite easily be less depending on the type of project.

This chart shows the effect of reduced usage for each of the Cloud instances in the analysis above, and the advantages of the hourly Cloud contract are obvious as the cost scales directly.

If I’m using a VPS then I’m forced to use another VPS on a monthly contract if I want an identical staging platform, and this is much more expensive than using any of the Cloud alternatives presented here.

Conclusions

Will I be moving to the Cloud? I’m certainly tempted, especially with my own projects. It’s interesting how there seem to be cost sweet spots at both really low loads and higher ones.

Being able to use identical staging environments is something I’d love. I’ve tried local virtual machines, but they’re never really identical, and I dislike having a VPS that hardly does any work. Unfortunately to realise this dream I’ve got to move all my production to Cloud instances, and concerns about reliability – especially given the highly public problems at AWS – make me reluctant.

The key is to be able to quickly spin up new instances, and rapidly destroy them once the testing is done, so that I can keep costs down. Most services allow you to save custom images from which you can create servers, so may be I need to play with this in the Brightbox beta some more.

Long term, I think there’s no question that this’ll be the basis of my development workflow.

I’m a single developer working for myself on small client projects and a few personal ones too. To date I’ve extensively used virtual machines from a number of providers and been quite happy with most.

I rarely need to configure a new VPS, and regular maintenance isn’t a major headache since they’re few in number. So beyond the light use of Amazon S3 for backup storage, the Cloud seemed to hold little of interest.

But then the afore-mentioned problem cropped up, and it’s origin was a mystery. I’ve setup Linux systems for years now, but the cryptic application errors and the server logs were distinctly unhelpful. I ended up created a new web app just to debug the root cause, and it all took time.

I was lucky, I could afford it since this VPS wasn’t hosting client projects. Had it been I’d have felt obliged to rent a new VPS to maintain continuity, and the experience would’ve cost me, so this is where I revisited the idea of the Cloud.

Developmental benefits

Staging on an identical platform without the cost of a permanent staging server was the first benefit that struck me. It’d make ironing out deployment and dependency issues much more cost effective for the small developer.

Operational benefits

In the context of my recent problems, there’s the option to rapidly spin-up and configure a new server instance from a saved image. I could have skipped fixing that broken server configuration and just replaced it with a fresh one.

Switching a public IP address to another server is quick and easy so if one of your servers does fall over you can switch to an alternative without messing with the slow to refresh DNS.

Cost benefits

When it comes to cost, apart from the hourly versus monthly pricing, the main difference lies in the way bandwidth is charged.

This complicates things a bit, in fact with AWS instances it’s even more complex, but overall it seems that for light traffic applications the cost of Cloud servers is very competitive with their VPS cousins.

Still it’s in my nature to fire up a spreadsheet when things get messy, and that’s a topic for another post.

Normal behaviour

I expect the bundle to be installed inside an RVM Gemset directory that looks a little like this.

All the gems are installed in the gem directory and are available to the application.

Problems with Passenger.

Recently I’ve been finding that Passenger doesn’t see these gems in the default location. The RVM documentation suggests a fix if the usual bundle install doesn’t produce the expected results; use the bundle install $BUNDLE_PATH option.

Doing this causes Bundler to add a .bundle/config file containing file paths and prevents the sharing of gems. In additions, and possibly in an attempt to avoid sharing, Bundler places the new bundle inside a sub-directory, ruby, as it would if I wasn’t using RVM. This leaves the Gemset structure with a duplicate.

Problems with Bundler.

This all seems fine until you want to update an existing gem or add a new one.

I made this discovery when I emptied my Gemset to find that bundle check seemed to think that all the dependencies were still satisfied, strange. It turned out it was still looking at the ruby/1.8/ directory as directed by the .bundle/config file.

Unfortunately, Rake and other application tasks couldn’t see these gems, and Bundler couldn’t install them again, dependencies satisfied remember. Worse still it didn’t seem able to manage the copy either and crashed whenever changes were needed. Under RVM, Bundler seems to break in the presence of the .bundle directory.

As you might expect from what I wrote above, viewed through Passenger it was like nothing had happened.

So I deleted the useless ruby directory. That broke everything.

Investigation.

I wondered why the .bundle directory was necessary, a legacy thing I think; I deleted it to find out, that’s what version control’s for isn’t it.

I ran bundle install, but still no joy, the error was still there, and then I tried clearing the cached gems. Great, Rake was back in action, and gem list showed me what I expected, one problem down. Bundler can now modify the gems in the original bundle, the ones the application can see. But Passenger was still dead, it just complained about the lack of gems.

I could fix it in the same way as before, using the $BUNDLE_PATH option, but that would leave me with a second bundle copy again, and a whole lot of problems trying to update them. Besides, two copies of the same thing is just a bad idea anyway.

Then it occurred as a result of the Bundler upgrade information, that Passenger was using Bundler to get the gems, and Bundler didn’t seem to know where to look. The $BUNDLE_PATH environment variable should provide that information, but Bundler wasn’t getting the message from RVM and Passenger.

My solution

Don’t use the $BUNDLE_PATH option or you’ll end up with a second bundle copy and render the original unmanageable. Make sure you delete the .bundle directory in your application root, or future attempts to use Bundler will fail.

Manage your gems using Bundler with the plain vanilla commands, like bundle install, and everything should work in development. Bearing in mind that you’ve got good development server options, like rails s and Shotgun, available you might want to give Passenger a miss. But if you don’t, and you’re using Apache, I’ve found that adding

SetEnv BUNDLE_PATH path_to/.rvm/gems/ree@thegemset

in the vhost configuration should get it working, though you might need to restart the Web Server, touch tmp/restart.txt won’t do.

Why RVM isn’t passing the $BUNDLE_PATH to Passenger, and how Passenger could find the Gemset copy in the first place, I don’t know, but I’ve got my development environment back on track. Wish I could say the same for my attempt to deploy Rails 3 to REE with Bundler.

I’ve been using Sinatra for more and more projects, but there came a point this week when I realised that I was in danger of accidentally upgrading gem versions without testing first.

Dependencies in crisis

You see, my applications all use the system gems, and require "gem_name" to load the most recent local version.

As the number of applications on the server grew, I found that this had the effect of automatically upgrading all my applications whenever I upgraded a gem, whether intentional or otherwise.

Now I like to take advantage of bug fixes and new features of the latest releases whenever possible, but I don’t necessarily want to upgrade every application in a single mammoth coding session, or have to hold back the deployment of a new application until the others have been upgraded and fully tested.

Gem and version dependency control

It dawned on me that I needed some control over both the actual gems and the versions each application used.

Simplicity

The simplest approach is to control what it available in the application load path before loading it in the usual way, and these are the commands for the job.

gem "gem_name", "gem_version" require "gem_name"

I tried this with some success, and quite a few of my applications are still using this method for now. But I decided to try using Bundler as a long term solution.

Bundler

If you want to know about Bundler I suggest you try the github repository or some of the posts on Yehuda Katz blog.

I found it pretty easy to integrate with Sinatra by following these instructions, and my Gemfile looked like this.

source "http://rubygems.org" gem 'sinatra', '1.0' gem 'haml', '3.0.13' group :test do gem 'rspec', '1.3.0', :require => 'spec' gem 'rspec-rails', '1.3.2' gem 'cucumber', '0.8.3' gem 'cucumber-rails', '0.3.2' gem 'webrat', '0.7.1' end

Testing with WEBrick went like clockwork, working smoothly with both RSpec and Cucumber, but when I tried to get things running on Passenger this is what I saw.

This had me stumped for quite a while. I reinstalled Bundler; checked out the installation of Passenger, my $GEM_PATH, and the Ruby environment; nothing worked.

The solution turned out to be much simpler than all that: add the Bundler gem to the Gemfile dependencies.

gem 'bundler', '0.9.26' gem 'sinatra', '1.0' gem 'haml', '3.0.13'

I wish it had occurred to me earlier, but the simple ones never do. Anyhow, my Passenger deployments work perfectly, and I’ll be migrating all my Sinatra apps over to Bundler.

Capistrano integration

And if you, like me, want to use Bundler to manage dependencies during Capistrano deployment, you might like to try these useful recipes.

There’s no better way to learn a new language than to actually use it in real life. My Nature Notes started as a project for my partner in PHP, CodeIgniter actually, but progress was slow due to an enjoyment deficit.

Testing is the main reason that I grew unhappy with PHP, most of the tools were there, but the integration was patchy: the basics are all there in Ruby and it’s associated development frameworks and integrating new packages via ruby gems or plugins is simple.

I started using the built-in Rails testing tools, but for no particular reason I’ve moved on to RSpec for unit and functional Rails model and standalone Ruby code testing coupled with Cucumber based integration testing. I’ve found that I need both.

Cucumber tests try to exercise the whole software stack – views, controllers, models and even the database. The use of natural language makes it easier to translate user stories into the appropriate tests, though it still needs some discipline to ensure that the edge cases are covered: I don’t think clients could write these as acceptance tests.

Involving the whole stack makes tests a little brittle, how specific is too specific? I’ve managed to break tests by removing fullstops (periods) from the rendered HTML!

I think that this is where unit and functional testing with RSpec at the model level is indispensable. I test model associations, validations and custom business logic in that order, I draw the limit at all the ActiveRecord CRUD functionality.

I’ve found that the development environment hasn’t really changed in the move, the same basic toolkit does PHP and Ruby.

I regularly use several code version control systems including Subversion, Git and Mercurial. Recently though I’ve increasingly turned to Git and GitHub. Like most good tools the more you use it the more attached you become, so I’ll have to force myself to use the equally fine Mercurial again soon. I love these distributed tools.

TextMate is my editor of choice for Rails development. I’ve tried to use Netbeans IDE, I use this for Java, but it seems like overkill. TextMate is quicker, simpler and provides the tools I need via the a range of bundles.

I have to admit that the code syntax highlighting is the most useful feature because I like using the command line too much, but I’m increasingly using code completion and I’m going to try the Zen coding bundles for HTML and CSS, I don’t like the default tools much.

That’s a round up of my current practice, more about the resulting software once I’ve decided to move on to a public beta.

It feels like I’m starting from the top of the software stack and working down from broad specifications, creating code as I go, rather than up from fine grained models based on specific unit tests. Is this a reductionist approach?

When writing my features and scenarios I’ve noticed a tendency to follow the CRUD acronym common in data access layers: Create Read Update and Delete. The order of these processes is significant and my reasoning goes something like this……

I can’t really expect to read the contents of an entity before I’ve generated the code to create it. Now I’ve created it, I’m not going to try to edit this same entity unless I can actually read it. I can read what I’ve got, but I might want to edit those contents, and delete comes last…… because it just does, I guess the order of “UD” is negotiable, but this way it’s easier to pronounce.

You get the general picture, but this is just the approach I’ve adopted through trial and lots of error. It’s far from perfect, so how do you use behaviour to lead the code?

Whilst the Brightbox Rails hosting stack is very focused, my general purpose hosting has been based on CentOS, a free flavour of Red Hat Enterprise Linux, and the WHM/cPanel server management interface; a scatter gun approach I don’t like: it was time to change.

Keep the servers clean.

I find that removing complex GUIs and reverting to command line management results in cleaner servers, with more control over software baggage and file structure.

On top of this I found that most clients have little interest in accessing the server, preferring that I take care of everything. I’ve no intention of entering the reselling business, so exit cPanel, the extra cost, and the hassle.

Standardise to maintain quality.

I’ve standardised my Ruby maintenance scripts and wanted a set of VMWare Fusion based staging virtual machines for deployment testing. To reduce the workload, and the chances of mistakes, using a single operating system seemed logical.

Since I started using Ruby on Rails, I’ve converged on Ubuntu 8.04 LTS as my server operating system of choice: I find that it is a neater implementation of Linux, especially when it comes to Apache configuration.

Competitive pricing.

At around the same time as these thoughts were flowing through my head, Memset changed the way they implement their VPS leading to better specifications and significant reduction in price.

Initially I was sceptical, it looked too good to be true, but I have completed migrating my existing websites and Subversion repo to a VM1000 and it has run well over the last couple of months. I haven’t run any performance tests, but subjectively these websites seem a little more responsive, and all at a quarter of the price!

A good result.

This is great news since I’ve been wanting to supplement my LAMP based work with more significant applications using Ruby and/or Java stacks, and running all that on a single low resource server is not a good idea.

To sum up I’m still happy with Memset…… probably happier, since the price reductions have made it possible to experiment freely without having to use a US based host with an unclear commitment to environmental impact.

I’ve used Ruby for scripting, and deploying PHP applications with custom Capistrano recipes for years now, but I’ve never tried any of the available web frameworks.

This week I switched to Ruby on Rails, and I’ve accomplished more in a couple of days than in a couple of months with CodeIgniter.

I’m not trying to claim that there’s anything fundamentally wrong with PHP, so don’t beat me up over it, but I find working with Ruby and Java much more intuitive, enjoyable and productive: it’s a personal choice, I feel more inspired.

I’m particularly loving the default support for unit, functional and integration testing; I now feel in control of my code and I’ve yet to explore the full range of testing frameworks and approaches available for Rails.

I know that CakePHP mirrors Rails functionality very closely, but I’m afraid it’s the PHP language that I find too ugly to love – personal choice again, don’t shoot – consequently this is one developer who may have written his last line of PHP code…… maybe.

I’m now hoping to have the first release of the nature and wildlife recording application I’ve been promising Clare for…… much too long, up and running in the next couple of weeks.

The Git work environment.

Working with Git is quite different to using Subversion. The actual contents of the project directory change to reflect the currently active branch: the directory contains a whole repository, not a checked out copy. Don’t get alarmed when files start disappearing only to reappear again when you switch branch.

I also noticed that I interacted with the version control less frequently when editing, delete, and create files. The interaction is saved until you’re ready to commit, making the process feel more seamless. I occasionally used to get into trouble by deleting files via the OS, rather that using the Subversion command.

For the majority of the time, I’ll use the Git commands, as I’m working in a Git repository. The git svn functionality is only needed as a Git interface with Subversion.

Getting ready to work.

I like the master branch to always reflects the current trunk until I choose to update it, so all my commits are made from other working branches.

I start by checking out a branch based on master to use as a base from which to work. I’ve imaginatively called it basework in this example, and as a branch of master it is linked to the same remote branch: trunk.

git branch -a

should display all your branches in the repository.

jkw@mac> git branch -a * basework master svn/trunk jkw@mac>

I work in increments based on stories, that’s another post, so I actually create a story branch from basework, that can be merge back into this parent upon completing the story. This helps cope with changes in the remote codebase.

Creating my working branches.

It’s a good idea to check that basework is up to date with the remote Subversion trunk before branching:

git svn rebase

This will either update the local repository with the remote changes, or tell you that the current branch is already up to date.

I’m now in a position to create my story branch:

git checkout -b inwork

The -b option is used to create a new branch and then switch to it. Without this option the same command is used to move between branches.

This same process was used to create basework.

I have my working repository structure, and I’m currently working on my story branch, see the asterisk.

jkw@mac> git branch -a basework * inwork master svn/trunk jkw@mac>

The local commit.

You can see details of the changes to the local working branch using the git status command:

jkw@mac> git status

On branch inwork

nothing to commit (working directory clean) james@cybermac1> git st

On branch inwork

Changed but not updated:

(use “git add/rm …” to update what will be committed)

(use “git checkout — …” to discard changes in working directory)

#

modified: footer.php

deleted: images/feed-icon-64.png

modified: style.css

#

Untracked files:

(use “git add …” to include in what will be committed)

#

includes/category-1.inc.php

no changes added to commit (use “git add” and/or “git commit -a”) jkw@mac>

To add the new file show in the example to those being tracked:

git add includes/category-1.inc.php

If I wanted to add all of the untracked files, I could use the -A option instead of individually naming them.

Now all the files are staged, the time comes to commit them to the local Git repository:

git commit -a -m "A message to describe the changes."

Leaving the -m option off will cause Git to request comments using whichever editor is defined in your configuration files.

I now the story is complete, and all the changes committed to the inwork branch, it’s time to commit them to Subversion.

The remote commit.

I start the remote commit process by switching to the basework branch:

git checkout basework

Next I check that the remote codebase hasn’t changed, or update the changes:

git svn rebase

I’ll merge inwork into basework:

git merge inwork

I use my text editor to manually fix conflicts that arise. Git tells you where to find them by marking up the code. This is followed by another local commit, at which point the merge is complete.

Now I can try a dry run of the remote commit:

git svn dcommit -n

It’s the -n option that makes this a dry run: nothing has been committed yet. It shows you the local versions to be bulk committed if you choose to go ahead. To actually perform the commit, remove the -n, and re-run the command, it may take a while if you’ve been busy.

Verifying the remote commit.

This is where leaving the master branch untouched pays off. basework has been committed to the remote trunk, whilst master still reflects the pre-commit trunk.

I switch to master, which should contain none of my new work, and update it from the remote trunk:

git svn rebase

It should have changed to match basework, and if so the previous commit worked.

Cleaning up.

I’ve verified the commit: I have master and basework branches that are identical, so inwork is no longer needed, I’ll delete it:

git branch -d inwork

Deleting a child branch of a different parent is a little dangerous, so if you’re not in basework you’ll get a warning. Either switch to basework and try again, or re-running the command with the -D option.

If I’ve finished work on this project, I’d delete the basework branch too, but if I’m going to continue, I’d use it to create another working branch, and I’ve gone full circle.

mkdir myproject cd myproject

The initialisation itself is pretty simple, just remember to point Git at the correct url for your Subversion repository, and watch the communication protocols.

git svn init -s --prefix=svn/ svn+ssh://svn.repository.com/svn/myproject

The -s option tells the repository to expect the typical trunk, branches and tags structure of a Subversion project. You can specify the location of your trunk, branches and tags using the -T, -b, and -t respectively.

Using the --prefix option is handy, ensuring that the remote directories will be prefixed with svn/. This makes it clear which are Subversion and which git branches later.

All that remains is to checkout all of the information relating to your project from the Subversion repository.

git svn fetch

Depending on the size of the project, this could take a while, it’s downloading the entire project history from the remote repository.

I word of warning you about the strangeness that can ensue if the remote repository contains any tags. They will be imported as git branches, and you may find the local master branch pointing to something other that the remote trunk.

These git svn commands, and all the others, are pretty well documented. Now I’ve got a Git repository, in the next post I’ll to describe my normal workflow.

Branching and merging is quick and simple, and as a result I find I do this far more often than when using Subversion alone. I also commit changes more frequently: it’s far quicker than using a remote repository, even when not off-line.

This sort of functionality is vital to successful version control, and I think it promotes better practice, as long as you’re only committing working software. All the local Git commits will later be bulk committed to the remote repository. However they all retain their identity as separate versions, so discipline is important, we wouldn’t want anyone finding broken code.

I could get all this from Git alone, but the combination retains Subversion vendor branching and the deployment advantages of my existing Subversion / Capistrano set up. I’m going to try GitHub, or my own remote Git repository, and exploiting the Capistrano support for Git, but at the moment why reinvent the wheel?

I prefer to work on the command line, and that’s the approach this series will take, but GUIs are available for Git, try typing git gui to check out the one bundled.

I use this approach for anything I need version controlled, including my Curriculum vitae/Resume, but before try this out for yourself you’re going to need to check out a local copy of that remote Subversion repository… I’ll cover that next time.

My experiences got me thinking about what I needed to code confidently. As a minimum, I need to know that everything works before committing code to version control, but security comes with regular testing, and this is no use unless everything is covered.

Based on web development frameworks using the nearly ubiquitous MVC design pattern, the logic and side effects at each application tier must be tested, and I came up with this list.

1. The Database tier schema, whether RDBMS, XML or anything else.
2. Data Access logic is usually implemented in models, but often uses built-in features of the framework, such as ActiveRecord.
3. Business logic is encapsulated in the models, libraries, and sometimes controllers.
4. Presentation logic at the server comprising controllers and their respective views.
5. Presentation and business logic at the client tier implemented by DOM scripting, mostly in JavaScript.
6. The actual data presentation at the client tier based on XHTML and CSS.

I’ve tried to order it from inside the application, working out from the data tier to the client, and it’s quite a list; I’d be interested to hear what I’ve missed.

Since this is a huge topic, I hope to write a series of posts isolating specific areas as I encounter them, and comparing tools and approaches. The first will look at how a few development frameworks in popular languages appear to measure up.

Unfortunately, testing anything other than libraries and models is difficult because there’s no way to access the another important type of object: controllers. CodeIgniter positively encourages using controllers to implement business logic, consequently not being able to test them is a serious anomaly.

Integrating a front-end testing framework, such as Selenium, might be the solution, but does that properly test the controller code? I don’t think it does; the target there is the presentation tier at the browser.

The lack of good code coverage bothers me a lot, but I continue to struggle on with CodeIgniter because I’ve found other PHP frameworks to be just as lacking. Is this a general problem with frameworks? I’m tempted to try Ruby on Rails next to find out.

Positive experiences.

The most frequently touted benefit frameworks have to offer is minimising the time taken to code and deploy a software solution. Given my interest in Agility, this is an attraction, reducing the time to market.

Another solid development practice is code reuse in the form of software components, and frameworks have a place amongst them. This approach offers the reliability and security inherent in widely used and tested code. Remember to choose popular software though, or this benefit disappears.

On the downside.

Applications developed using frameworks have to carry significant excess baggage in the form of unused features. This raises two main issues: your codebase will be unnecessarily large, and underused blocks of code are a breeding ground for hidden exploits and errors.

Frameworks are designed to function in a specific way, some with more flexibility than others. This much you’d expect, after all it’s the essence of a framework, but what if it doesn’t provide everything you need? For example, I’ve spent hours trying to integrate SimpleTest, a unit testing suite, to produce satisfactory results with CodeIgniter. My unit tests run well for my own libraries, but I’m still unhappy with the test coverage imposed by CodeIgniter’s MVC implementation.

Finally, they say practice makes perfect, but does reliance on any framework reduce developer skill? This isn’t a problem if everything is pre-packaged in your chosen tool, but what if a client wants something that isn’t included?

Too good to ignore.

That said, I’ve found all of these software very useful and there are far too many advantages to ignore them. But I often find myself fighting these same tools, frustrated at they’re eagerness to help me do something in a way I don’t want it done. I guess the key is to understand which is the right tool for the current job: the ultimate skill for a developer.

There’s a good TextMate bundle to support Git, but to be honest I’ve mostly used the command-line.

Weaknesses.

Vendor branching is possible, but awkward. I frequently use vendor drops of WordPress, SimpleTest and a number of other libraries. There may be a good way of doing this, but I haven’t found it online… yet.

I miss the svn:externals functionality, especially in applications that use a lot of plugins: WordPress in particular. Subversion allows me to define particular tagged versions of these to be pulled from their repositories during deployment without needing to bother controlling them myself.

Strengths.

Branch merging when trying out new ideas is a dream. I created a new branch, refactored huge sections of the codebase, and merged it all back together flawlessly. With Subversion this would have been a lot slower and more problematic. Git’s simply great for those investigatory spikes.

The verdict for Git.

I’ve yet to seriously try Git to interface with my remote Subversion repositories, using the ‘git svn’ series of commands. Having local copies of these, whilst still being able to use remote Subversion would be very useful. I’ve found using remote Subversion repositories easy, but trying to push a Git repository to Subversion is not so easy. I’m also going to try deploying from a Git repository using Capistrano in the near future.

It strikes me that Git is best at programmer related activities and weakest in those of interest to administrators deploying applications. I shall certainly continue to use it, but alongside Subversion.

Changing the Architecture.

I’m not a keen on the idea of dumping all my code in the web server root directory, so I tested the framework flexibility by rearranged the application structure a little.

    -rw-r--r--   1 Capfile
    drwxr-xr-x  14 application
    drwxr-xr-x   3 config
    drwxr-xr-x  13 system
    drwxr-xr-x   5 public

Once these locations were updated in the application configuration files it all worked perfectly. The reasons for doing this sort of thing have been documented elsewhere, and I agreed with them from this security standpoint, however this structure also fits better with Capistrano deployment.

A positive first impression.

The Views deal with the presentation logic, and I like the fact that embedding PHP within the HTML is the default, instead of a complex templating system. It’s not the cleanest approach, but I prefer to have full control over my HTML.

As for the Controllers, the implementation is quite intuitive and you can build a friendly set of URLs with a little help from mod_rewrite and the URI class.

The form validation is a great feature that I found easy to implement within the Controllers and Views. I’ve centralised my validation rules in the global configuration file suggested in the documentation, but haven’t got the automatic rule group feature to work yet.

The Model class is used to represent a single database table. I’m used to mapping tables with a Class in this way, but normally each instance would represent a row of data. CodeIgniter Models implement the Singleton design pattern, only one instance per class, from which the Database class methods can be called.

The Database class provides the data access layer and a good set of robust methods which return an array of stdClass instances representing the resulting data rows. These arrays are then forwarded to the View, where the instance variables can be directly accessed. This is quick and easy, but not very OOP.

Implementation reservations.

I believe that the Model should be capable of running as a stand-alone application, once equipped with any interface, even the command-line. It’s this level of autonomy that results from the MVC design pattern: substitute a different Controller and View and it’ll still work the same way on a different platform.

Controllers reacting to events, whilst Views shouldn’t have direct, mutable access to instance variables. The Model should encapsulate both the data and the business logic, not something that can be effectively achieved with Singletons alone. Indeed CodeIgniter blurs this distinction by making Models optional and allowing data manipulation directly in the Controllers.

I’ve implemented my preferred approach by providing my own classes to replace the stdClass. They don’t extend the CodeIgniter Model class, but are instantiated within those that do, encapsulating data and business logic; including Object–relational data mapping and CRUD functionality.

It works well, but I’m concerned that by introducing a more rigourous approach I’m losing some of the advantages of the framework. May be I would be better to take CodeIgniter at face value, as a flexible, if a little dirty, rapid development environment that works.

The Agile approach is more adaptable with respect to three key project variables; only the last of which, in my experience, is considered flexible in the waterfall world of engineering.

• Scope.
• Time.
• Resources.

Scope contraction.

Scope flexibility is something of a taboo subject. Scope is something that is added to in both a controlled manner — providing additional revenue — or uncontrolled creep. But the point of any project is delivering something that achieves the customers business goals. This is not necessarily the product that they, or the development team, initially envisaged.

One uncomfortably overspent project lead to the realisation that I could have achieved the business objective well under budget by actually drastically reducing the scope. It wouldn’t have delivered exactly what the customer expected, but it would easily have achieved their goal.

Which is more important, expectation or results? If you have a customer representative on the team it’s much easier to explain your rationale, and the chances are they’ll like the idea of results with less work as much as you do.

Timescales.

If you have a customer that doesn’t mind when you deliver, you’re a rare and lucky project manager, though you’ll never actually finish anything; deadlines do provide focus. So set plenty of deadlines, that’s what iterations and releases are about.

Try to answer the most pressing question as quickly as possible. Leave refinements and those ever present scope changes to the next iteration, it’s probably only a few days away.

This rapid cycle provides useful results, whilst allowing the flexibility to quickly change direction without that wasteful churn: just tidy this up a bit then I’ll be with you.

And the resources?

I’m afraid the project manager has to earn their money too. Line management will always have the urge to reassign any of your key people they feel aren’t being fully employed. It’s important to emphasise that the productivity of any team depends on preventing this happening.

Agile teams don’t strictly segregate workload on the basis of job descriptions, that’s why you need versatile individuals. Unfortunately, these are exactly the type of individuals that those managers will want to steal away. Removing the demarcation of tasks will help ensure everyone is kept busy and that work is conducted using the minimum number of people.

Better than the Waterfall.

I’ve found actual project goals shift too frequently for effective use of the Waterfall approach to project management. Using iterations within this framework always felt unnatural; how do you decide how may there will be and when will you actually deliver something?

An Agile approach perversely leaves me feeling more in control by worrying less about control. There are a huge array of Agile software development techniques, many of which can be adapted to other engineering disciplines.

For Software Engineering, I would recommend reading The Art of Agile Development. The Agile Alliance promote the use of Agile techniques, so take a look at the Manifesto for Agile Software Development upon which it’s all based.

1. Log in as a privileged user.
2. Create the domain deployment directory.
3. Export the application code from Subversion.
4. Update the file ownership and privileges.

For WordPress I also had to export code for each theme or plug—in to the required locations. So I decided to improve the situation. I’ve changed the way my WordPress sites are handled in Subversion; haven’t moved to Git yet like the rest of the world, and I am using Capistrano to manage the deployment.

Capistrano is a Ruby based remote task manager, the most commonly used tasks being for web application deployment. Obviously the original target was Ruby on Rails, but many people use it for PHP. It uses Secure Shell (SSH) as the preferred method for logging into remote servers; all communication is then encrypted.

What follows isn’t a full set of instructions on deploying PHP with Capistrano, HostingRails.com provide a useful piece and you should look at the Capistrano manual, these are my thoughts. May be something more detailed might come later… but no promises.

Managing the source code.

The Subversion repository for each blog project uses a vendor branch of the WordPress source code and svn:externals properties to import the required themes and plug—ins from their respective repositories.

WordPress updates are integrated into the vendor branch and then into any of my projects without disturbing any custom code changes. For merging changes I can strongly recommend using the svn_load_dirs.pl script, it allows you to maintain file history and makes the whole process easier.

And now deploy.

I currently have my main Subversion and Web servers on the same machine, leaving me with the option to use the local file:// protocol to retrieve the application files. I wanted to make my deployment script more universal so that I could use it for the production and development platforms.

The obvious choice was the svn+ssh:// protocol I normally use, but in addition to SSH, I use public key authorisation with passphrases for all of my servers. A frequent problem was that Capistrano didn’t like asking for passphrases for remote machines.

Since the repository and deployment machines are one in the same, I can use SSH forwarding to provide a recursive tunnel by defining the following in the deploy.rb script.

set :user, "me" 
ssh_options[:forward_agent] = true

The variable user tells Capistrano which user has SSH access and the forward_agent option allows the same SSH credentials for the tunnel to the Subversion server. Now , if your svn user is different from the ssh user you’ll need to add another couple of things:

set :svn_user, username
set :repository, "--username #{svn_user} svn+ssh://hostname/repository/#{application}/trunk"

These variables enabled me to use the default deployment tasks for my application, there’s no need to override them, just use the before_ and after_ hooks to define additional functionality.

The result.

I have two WordPress blogs deployed on my server using Capistrano and Subversion for remote control, including custom themes and third—party plugins. I’ve already redeployed to incorporate changes and everything has worked perfectly.

Next… Drupal?

Redefining the Architecture.

I decided to start again by defining the information architecture for the site based on a proper discussion with the Club committee. The first few meetings on this topic just weren’t as well focused as they should have been; mostly my fault for not knowing what I wanted from them; but this time I tried targeting those features that the membership would really value. Each of the features that emerged seemed to fall into logical sections of the information architecture:

• About the Club — including notices, events and membership contacts.
• Content on Birding — after all it’s the main focus of the Club.
• Social groups within the Club divided by specific interest.

These overall sections were used as containers for the more specific features, and these formed the basis for implementation.

I’ve tried an online tool called WriteMaps for developing and sharing the architecture of this site. I haven’t decided whether it’s the best way to approach the job yet, but here’s the link to the detailed sitemap.

Implementing the Design.

The original site used custom taxonomy — tagging — to enforce the architecture, with multiple sections of the site sharing the same content types. As I mentioned, this made it very confusing for the Club editors, which was reflected in the site presentation.

Installing new modules.

I needed to add several new modules to support the new content. There are several ways of doing this; this alone is a substantial topic; but the simplest is to download the module directory containing the code into the modules directory of your Drupal installation.

Content types.

For this redesign I decided that each of the features should have a dedicated content type so that users only need select the right one, there’s help text as you can see, and it’ll end up in the right place on the website. No more messing about with tags!

A great tool for this is the Content Construction Kit (CCK) module. It makes implementing new content types very easy; no PHP required; and there are a wide range of modules that provide additional data fields. I’ve used several to provide dates, images and even GoogleMaps, take a look at the full list of compatible modules on the Drupal website.

Once the CCK module is installed, all the changes you want to make can be managed from the Content types section of Content Management.

Providing access.

All these new content types need to have access control set–up before you can go any further. This is done in Access control, under User Management in the administration section of Drupal.

You should find both create and edit options to set under node module for the new content types.

Once these are set the content types should appear on the appropriate create content menus.

Setting up the paths.

But you’ll want to set the URLs to reflect the new architecture before deploying.

I use Pathauto to provide aliases for my content that better reflect the structure of the website and present friendly URLs. You can do this manually, but if you can’t rely on your users to do this consistently I would recommend using Pathauto.

The Pathauto settings are under Site Configuration, and it’s the Node paths you want to set–up for your new content.

These, combined with the individual content types, provide the structure for the website. For example I wanted the bird guide to appear within the birding section of the site architecture with individual entries beneath this, so I set the pattern to birding/birdguide/[title].htm.

Time for a View.

The Views module provides the ability to present node data in a range of different formats. With the module installed your views can be managed from the Administer views section found under Site building.

Here you can define new views for each of the content types and define a URL from which the specific view can be accessed in the browser. In the image above you can seen that I wanted the bird guide list to appear as the default in the bird guide, and gave it the URL birding/birdguide. These views can generate lists, tables and customised sorting, in addition to the more standard web page presentations.

…And a menu.

Finally we’re going to want a menu from which all our good work can be accessed. The menus and blocks in Drupal can all be found in the Site building section.

The sequence is simple, first create a new menu for the features you’ve implemented, under the Menus section, using the URLs of the views;

and then go to the Blocks section and put the new menu where you want it to appear on the website.

That should be it! Your new functionality has been added.

Conclusions?

Having established this workflow, I implemented each of the identified features one at a time, ensuring it was working and acceptable before moving on to the next.

I believe, and feedback suggests my users agree, that this approach to building a Drupal website is far more successful than a taxonomy based one. I still use taxonomy, but it now provides addition information for particular types of content rather than forming the basis for site architecture.

As for Drupal itself, it’s relatively easy to use, even without significant PHP knowledge, and the large community provides a huge range of contributed modules and support. This makes it a powerful way to develop feature rich, multi–user websites very quickly.

On the downside, I’ve found providing users with an easy way to upload and insert images very difficult. There are serious problems with using the popular TinyMCE WYSIWYG editor and IMCE file handling together; individually they work OK, but together… I need to look at this again.

I would definitely recommend trying Drupal out if you need a CMS, for an image rich website; such as a gallery; I’d try Flickr or, for ultimate control, hand coded XHTML.

Which programming platform to use for the server-side application? Whilst I have to admit that I’m not the greatest fan of PHP, it’s definitely the best option. Why? Because I need to run this application locally on a minimal server and PHP is available wherever you find Apache, and the skills should have some commercial value.

I’ve recently read a great deal about agile development, TDD and employing software design patterns. As part of this project I’d like to apply some of what I’ve learned.

A test framework.

Now I’m going to need a testing framework, and I’ve gone for SimpleTest. This framework not only provides unit testing, but the ability to create tests for web pages. I prefer to run my test suites from the command line, which is relatively easy to arrange with the TextReporter object. I’ve combined the whole thing with Apache Ant to automate most of the tasks in the project, including deployment.

Unfortunately, it appears that SimpleTest doesn’t play particularly well with PHP5, although they’re in the process of making the transition.

I’ve encountered the mass of error messages generated as the result of E_STRICT. This is easily solved by using a customised php.ini file as an option at the command prompt when executing the test code. Once this is done you can see the actual test messages!

A more significant problem is that the Mock object code cannot be called as static class methods in the way the documentation suggests. A little snooping through the code leads me to think that it’s due to PHP4 without the static keyword in the method headers required by PHP5. I don’t have a work-round for this, and I don’t want to have to alter all this code. I hope they address this as the transition to PHP5 continues, but at the moment my code is simple enough for me to write my own mocks.

When all is said and done, if you know how to use any of the xUnit test frameworks, SimpleTest is very easy to set-up and use.

Driving with tests.

Simple the tests may be, but using them to steer the direction of your coding effort takes a different mindset. The hardest part is learning which questions to ask when developing your tests. Asking the right questions about functionality will result in clean, precise code.

There’s always a temptation add just a little more functionality, but resist it. The point is to remain in control of the code at all times. When it’s not working, it must be because you’ve added new tests describing new functionality. The code should never contain functionality that hasn’t been demanded by a test. Good refactoring can produce beautiful code without breaking the tests — still in control.

I think I’m getting the hang of it in relatively simple cases, but there’s much more to learn. I’ve found it a very liberating way to develop software, whilst remaining in total control — you are using version control?

Patterns in the code

Whilst there are loads of MVC based frameworks out there, I want to know how it works first hand. This topic is worth an article of it’s own, and that’s what I’ll give it.

There’s a good chance that the core application model will need to implement a facade pattern, but lets not make any assumptions.