Posts tagged rspec

Selected (belated, extended) Saturday Links

The past two weeks haven’t really left time to compile my selected links, though there have been many. A few days at SxSWi (on which more, later) followed by travelling with the family and the inevitable work backlog moved blogging way down the priority list. So here’s a mammoth selection to get me caught up. Particularly interesting has been the discussion around the future of newspapers (represented here by Clay Shirky, Steven Johnson and Russell Davies), which seem to have finally pushed beyond “how t ind a good business model for papers” to looking at where the real value for society lies and how we can preserve and extend that in a changing landscape.

Testing PHP apps with Ruby tools

As I’ve mentioned here before, when working on web applications built with PHP, whether custom-rolled or drupal-driven, I often find myself missing various tools from the ruby kit. I’ve talked before about using capistrano with non-ruby code, but lately it’s been rspec and its stories that I’ve been craving.

I’m aware of PHPSpec and have played with it from time to time, but the lack of a compelling way to work with mocks/stubs has slowed my adoption, and last time I checked it didn’t offer anything for high level user stories. So this week I set out to harness cucumber and webrat to write some simple stories.

It turns out to be pretty easy. There’s no nice simple support for test environments, fixtures, mocks or stubs, but if you just want to make sure that a few pages load correctly, and have the right elements, or that logging in works as you expected, then it’ll do the job.

I’ve not done any packaging up of the code, mainly because there’s so little to it. My folder structure is:

specs/
  Rakefile
  features/
    admin_articles.feature
    steps/
      admin_steps.rb

(click on the links to see sample files)

I simply set up those files, go into the folder and type ‘rake features’ to put your site through its paces.

Project Launch: New Greenbelt website

One of the numerous projects I’ve been juggling over the past few months has been a redesign of the Greenbelt Festival website. That redesign went live late last night.

Working from Wilf‘s designs I initially built new HTML and CSS templates and began to establish some rules for how we’d handle the new image management requirements for a site that is now very photo-heavy. When it came time to apply the new designs to the CMS, however, it became apparent that there was a much bigger job ahead.

That CMS (a bundle of custom PHP that I had inherited) has grown over time and within some quite onerous server configuration constraints to a point where it was due a significant overhaul. Sticking with PHP was a fixed requirement as we’re relying on various APIs and a server architecture that wouldn’t be happy with me shifting to, say, rails, but already having the problem domain mapped out and the opportunity to radically simplify a few things meant I got to enjoy the feeling of stripping out a lot of code without impairing functionality.

One note that Derek Sivers made in his controversial blog entry last year about switching from Rails to PHP was that working with Rails had made him a better PHP developer. I’ve found a similar effect. I have no intention of leaving the world of Rails (I still prefer it by orders of magnitude), but tackling projects like this in PHP are a reminder that working for a while with really good tools is likely to encourage you to seek out best practice in whatever environment you end up in.

Ruby developers who occasionally work on PHP projects as I do may be interested to note that we are using capistrano for deployment, and I intend to use rspec for some testing. I’ll try to write that up once it’s in place.

With a refreshed CMS, new templates, and some standardisation of our many javascript files on top of a jquery foundation, Paul, Greenbelt’s was able to manage the photos and copy to turn that new look into a vibrant and content-rich new site. You can see a few notes he wrote about the redesign on the site.

There’s still a fair way to go. I’ve got a lot of tests to write in order to make it easier for us to make further changes, and various aspects of the site are more than ready for a more fundamental rethink that will let the festival open up its archives better, but all concerned are very pleased to present the fruit of our labours.