content

I feel like I've written a lot for this blog recently, but actually I've just been logging in and, after much deliberation, deleting one old blogpost after another. The move to Drupal 7 has given me the tools (and the will and desire) to review such ancient, half-written content, during which process I've found very little that's salvageable: old arguments; points no longer relevant enough to be made; nonsensical first drafts.

But part of writing a blog is unwriting it: not in the sense of removing your hardiest, most flourishing plants; but rather in the sense of clearing out the weeds that rightfully grow on any fertile ground, and sweeping away the clearly failed crops, so that the rest can flourish. As programmers, we should also remember to apply this principle to good programming too: we should not be afraid to trim and remove code.

After all, we're living in the glory days of version control, where the flexibility of systems like git and mercurial seem mindboggling to those of us who grew up with subversion or (worse) CVS. And if you truly embrace distributed VCS, then you need never worry; for then truly shall omnes mutantur; nihil interit.

For anyone who's interested: I've written a debut blogpost on Sustainable Witney . It contains disturbing revelations about my personal carbon emissions. I know, eh: not for the faint-hearted. And if that's not racy enough for you, I'll be discussing loft insulation in a few days' time.

Doesn't get any more interesting than this. No, you misunderstand me: it actually doesn't get any more interesting than this.

Simon Willison put together an excellent short-and-simple backup script over a year ago now, and I've used it intermittently to make backups. It takes files, whole directories, or the output of shell commands, and wraps it all up into a datestamped gzip file, before sending the whole thing up to an Amazon S3 account. It's a nice little piece of kit, in other words.

I found that it worked mostly fine, although it was (a) fiddly to run as a cron and (b) threw occasional errors which I wanted to fix. These two things together meant I wanted to do some proper development on the script and keep track of it.

I wrote a wrapper to help setting up cronjobs, which means it can be scripted using config files in the user's home directory and . I then decided on a whim to commit all of this to github , which is the online home for a community that's been set up around the git versioning tool. As befits a DVCS tool, git has spawned a community which is multithreaded and agile and most of all very friendly, with all free repositories available to the public and everyone able to fork off everyone else.

The repository was still a bit empty, as out of respect for the original coder I didn't commit backup_to_s3.py with everything else. Then, very kindly, Simon agreed to let me bundle his script with everything else, so you can now check out (clone) the "Configured S3 Backups" repository and follow the README to get scripted backups up and running fairly speedily.

I'd love for people to give it a try and offer some feedback. I definitely want to squash bugs and would also welcome new functionality. But the joy of git and github is that if I don't want to implement any extras, then other programmers can go ahead and

In summary? Configured S3 Backups: give the script a try. Git: give DVCS a try. And github: give DVCS-based online community building a try. Message ends.

When finished this site will implement several different layouts: blogposts, "static" pages, short "nuggets", blog archives, taxonomy listing and probably a bespoke front page. Although these will all have the same underlying seven-column layout, that can still present some problems that are usually solved in Drupal with many different theme files and a lot of "regions" in which you can put "blocks" of content.

Regions and blocks have serious limitations, though. For example, any one block---say the most recent posts from the blog, or a feed from Twitter---can only be placed in one region, although it can then be made to appear and disappear on other pages based on URL or (dangerously) bespoke PHP embedded in the database. There are modules which replicate blocks, to try to circumvent such problems. Following merlinofchaos' great talk at, once again, DrupalCon Paris 2009, I decided to use Panels and panes instead of the core Drupal region/block system.

It was touch and go initially as to whether I was going to scrap it all and start again with blocks and regions or not. I managed fairly quickly to assemble custom pages for nodes of a few different types, but then had real trouble working out the subtleties of getting custom pages together for existing non-single-node content. Panels and its associated CTools developer framework concentrate far more on front-end functionality than ease of backend user experience. That's a shame, as the most important take-home message of prioritizing user experience is that hidden functionality might as well be no functionality at all. But as with most of these things---api.drupal.org springs to mind here---the first time is the worst, and once you know what you doing, you, well, know what you're doing.

Panels lets you divide up a page into just those panels. A set of standard URL matches come with Panels as "pages" you can enable, but you can also add new pages at new URLs. In terms familiar to Drupal templaters they take over the $content variable in the page templates, leaving your existing block regions available if you still want them. So when you enable panels, you get an extra menu item under Site Building called predictably "Panels". This takes you to a dashboard where you can enable or disable panels support for existing URL schemata (e.g. the node URLs at /node/%) and create variants which take into account e.g. the node type, so your blogposts can look different from your events. 

Slightly more subtly, though, if you want to enable panels on an existing view page... you can't. There's no mechanism for overriding the existing view page at e.g. /blog, like you can with a node page, and if you try to create a new panels page at that same URL then the system complains and won't let you do it. Instead, you have to create a whole new page and eventually discard or at any rate mothball the view's own page. Assuming you have a view at /blog, create a panels page at /blog_new; you can then add the view as a panel pane. You can use any one of the view's configuration variants (default, page, block etc.), not just the standard page variant. When everything looks happy, move your view to /blog_old and your new panels page to /blog.

Drupal also provides taxonomy listings at /taxonomy/term/term-id , which with Pathauto get aliased to /category/vocabulary-name/term-name. If you want to override a taxonomy listing, you can... but again there's a catch. Panels doesn't seem to provide you with any way of replicating the original content as far as I can see, and instead you have to build a view to replace the behaviour of the original taxonomy listing, and then put that into a pane where you'd want the original dumb taxonomy content to go.

When you create the view, you give it a first argument of "term ID". Then, when you add the view to the panel, in the modal lightbox titled "Configure view NAME (Defaults)", under the "Override title" box, you should have a setting where you can choose what to pipe through into your argument. Set that to term ID too. What you end up with is, as seems to always be the case with Panels, more functional and configurable than before, but it's harder to get to. Not just harder than letting core handle it: that's to be expected. But harder than you'd expect a GUI-rich many-developer-hour content-driven application to be.

Here's a summary of my panels the configuration:

Site building > Pages

• System > node_view enabled
• System > term_view enabled
• Custom > page_blog created for the blog archives

Overall Panels has made me feel like I have total control over what I want to appear where on my site. But the learning curve is steep and doubtless puts some people off; some of the greatest advantages come from being happy to get your hands dirty with PHP and the plugin architecture too, which I'll cover at a later date, and that's not possible or advisable for most Drupal end users. If I'd not had the luxury of stepping back for a few days every once in a while I'd probably have done it all in templating with regions and blocks. I'm glad I didn't, though, and I'm looking forward to iterating and perfecting my site's use of Panels.

I'm ridiculously excited that the book I co-authored with Tim Hall, Python 3 For Absolute Beginners, has been published. Apress very kindly sent me some complimentary copies last week and I immediately took photos of it and posted them on Flickr.

I blogged about how glad I was to be asked to work alongside Tim on the project back in January, and said among other things:

The book's aimed at those learning to program, through the medium of Python 3, rather than those already experienced in Python 2.x. But the new Python looks like an excellent way to teach people about the vagaries of a whole range of programming concepts. Generally the changes in the new version are for the better, and I think Python's benevolent dictatorship were absolutely right to conscience backwards incompatibility in the occasional change.

This is still all true, and I still think that Python 3 is still a quietly exciting overhaul of Python 2.x that raises the bar for both object-oriented and scripting programming languages.

My two chapters are on Exception Handling and Modules. Tim's ten chapters are on... everything else. Buy it. Enjoy it. Request it from your local library. Point it out nonchalantly to your friends. Use it to stop your desk from wobbling. Whatever: I'm just proud it's out there.

As the Drupal 7 code freeze approaches, D7UX is gearing up for final rounds of testing: like much of Drupal's collaborative structure, this will be crowd-sourced. Get involved! You can help Drupal usability!

Anyway, Leisa discusses the next steps to be taken:

a) we need to finalise scripts and make them available to people who wish to conduct testing
b) we need to resolve the issue re: a testing theme, and
c) we need to ensure that drupalusability.org is ready to receive feedback from multiple sources

I'm pretty late to the full-on D7UX party, but tangential to (a) it just occurred to me that we would find it useful anyway to have the Verity and Jeremy user "sketches" in a more persona-like format. That way, it'd be easier to "read" the scripts in the mindset of Verity or Jeremy, and get more of a feel for whether or not their choices and observations are believable within their character.

Below are Verity and Jeremy, in a more structured breakdown similar to the one Torchbox use for in-house user personas. (I've used a bit of artistic licence to pad them out a bit, but they probably still should be considered far more like sketches than personas. As there's only two of them they have to cover quite a lot of experiential "ground" as you run through the test scripts, so they're bound to be a bit vague.)

Content creator

Name

Verity

Age

Late 20s

Job

Part-time administration assistant for a cancer support charity

Experience

• Not a developer
• Proficient with the MS Office Suite (Word, Excel etc.)
• Uses Facebook and email
• Hasn't really used Macs
• Doesn't "get" things like Twitter or Spotify

Motivation

• Verity works part-time while she completes her Social Care Diploma
• Website is one of many tasks in job
• Writing content, let alone building a site, isn't high on her career priorities
• Update "news" every week and small ad-hoc content updates
• Often interrupted by the phone and other staff while she is updating the website
• IT consultant that Verity can call: but she likes to avoid doing this

Summary

Verity wants:

• To be able to complete her website updates quickly
• Straightforward workflows, without her getting confused
• confidence that she’s knows where she is and what she’s doing at all times

Non-technical site builder

Name

Jeremy

Age

35?

Job

Social software consultant

Experience

• Not a developer
• Researched MySpace, Bebo, Facebook etc. for job
• Knows of YouTube and alternatives e.g. Vimeo
• Blogs, uses Twitter, photos on Flickr
• Has a smartphone?

Motivation

• Works with medium to large organisations to help them understand how social tools could help
• Recommends tools that they should use and how they should be implemented
• Frustrated because it is difficult to customise existing tools to suit his clients
• Would love to have the ability to ‘build’ a site that would meet his client’s requirements
• his technical skills are not great – for example, he can edit some PHP code; he understands what CSS is and what it can do, but he’s never written much himself.

Summary

Jeremy wants:

• to build rich and flexible sites
• easily discoverable functionality
• freedom from PHP code or Drupal internals

This is just a quick note to say that I've set up a Google Doc to automatically republish on changes. That means that (if you like) you can read my intermittently live blogging of DrupalCon Paris 2009.

Those of a Twitter bent might prefer to follow me, the #drupalcon hashtag or @ukdrupal.

Developing Drupal in a development--test--production environment has a lot of advantages. Each developer's work is sandboxed, staging is straightforward, and deployment to live the stuff of Capistrano scripts---especially if you unite the entire ecosystem of separate environments with version control.

However, it can lead to confusion over precisely where your browser's currently pointing at: at best, this can be comical; at worst, it can result in either loss of live content or the logjamming of a staged site with content intended for live. Suddenly a staging environment is out of action until that content can be exported to the live site.

Enter devwatermark β-0.1, a D5 module intended to watermark any non-live sites with a little right-hand banner overlay. When first enabled---you can do this on your live site---it inserts no such banner. However, as you add live domains to its configuration, it begins to work out when it's not on a live site and tags your browser window with the "DEVELOPMENT" banner. Like watermarking your printouts with "DRAFT", or maybe like dogearing a page in a book. If your site has to respond to multiple domains---and if the content is the same then you should really serve up 301s instead---then you can add those extra domains to the configuration as required.

Having devwatermark enabled on live means that when you bring a live database down to a staging site to test the next round of updates, the change in domain will make devwatermark automatically show its banner image. You know instantly when you're in a development---and hence content-volatile---environment. That means that you can also watermark staging sites as non-development too: by adding them to devwatermark's configuration you can confirm to the developers that here's a database environment that they can't wipe and start again.

As I mention above, it's currently only available for Drupal 5, and your theme has to respect hook_footer (most do out of the box.) But please feel free to download it and give it a try.

Those of you who subscribe to the Oxford Geek Nights Google group hopefully need no reminder that Oxford Geek Night 13 is on Wednesday 15 July. But, more excitingly, the two keynotes are now confirmed.

Bruce Lawson, Open Web Standards evangelist at Opera, is no stranger to Oxford Geek Nights, and covered new developments in accessibility back in OGN10. This time he'll be discussing the forthcoming new standard for hypertext markup, HTML5, and what effects it will have on web-browsing as we know it.

Andrew Walkingshaw, co-founder of Inkling Software, will present the rise (and further rise) of their service for data visualization and storage, Timetric. He'll also be discussing recent work by the Guardian which has incorporated Timetric visualizations, including a recent article on the relative purity of illegal drugs seizures over time.

We still need microslot talks, though, so if you're interested then do volunteer.