We just got back from DrupalCamp Oxford at the weekend, and there were a lot of good sessions. When you consider the ticket price was only £50 and included two 3-course lunches (both of which were way above and beyond the usual "Drupal event" food quality), it was a real bargain, but with so much information to take in, we thought we'd provide a quick summary of the key bits we took away from it.

Cool modules

We didn't know about the hacked module, which was mentioned by Hernani Borges de Freitas, and is really useful if you've acquired someone else's Drupal code, like a website, and want to know if anyone has hacked a module, or worse, hacked core, so it no longer matches the code on drupal.org

There's also the authcache module that can provide a certain degree of caching for authenticated users. This is useful for sites where the majority of users are authenticated, although probably not necessary for the vast majority of sites, which generally deal with anonymous users (you should still cache, although not using this module).

Another of Hernani's suggestions is the MySQL tuner, which is a PERL script that can be used to suggest some decent settings for your MySQL installation based on the specs of the machine it's running on.

Migration

Data migration is always a pain, so Johan Gant's session on the migrate module was great. It's not a magic fix for data migration projects, but it can help to ease the pain. The main points we took away from this were:

• Make sure you can repeat your migration again and again and again because it will never go right first time.
• Make sure you know the progress of the current migration, as when it takes a long time, you need to know where it's at and whether it's stuck.
• Use realistic data, because if you use a small sample for testing which doesn't represent the rest of it, you'll run into problems when you try the real migration.
• Don't migrate on a live environment until you know it will work. You knew that already, right?!

Project management

Edward Kay's talk on project management was useful to us, especially as it outlined a lot of things we were already doing right. It's often useful to verify that your business process works the same or similar to other companies in your market, as otherwise it can suggest you've taken your eye off the ball.

Edward discussed how multitasking is deceptively ineffective and each individual should be kept on a single task. Jumping from task to task can feel productive, when really it is holding people back.

Edward also had some great suggestions about using spreadsheets to track the start, finish and sign-off dates for various parts of the project. He demonstrated some great-looking cumulative flow diagrams, but he didn't let us know how to make these, or give us any kind of template, so perhaps if Edward or his colleagues are reading this, we could get a link to those?

Aegir

We last took a serious look at Aegir in 2010, and it has come a long, long way since then. The main draw for a Drupal hosting provider like us is that the migration from one version of a module to another is seamless and automatic. If something goes wrong, the system will detect this and automatically roll the code back until you have a chance to fix the problem.

Combined with the fact that it can handle multiple remote systems and even non-Drupal projects (Wordpress, anyone?), we're now convinced it's mature enough and will be assessing it internally to see if it fits in with our deployment workflow.

Everything else

It's a credit to St. Catherine's College that they were able to cater for 150 people and put out such great food. Unlike most other Drupal events, lunch was civilised, orderly, and most importantly, actually tasted great!

The Friday evening meal at Al-Shami was also brilliant, and the first time most of us Tigerfishes had tried Lebanese cuisine!

A big thanks to everyone from the Oxford Drupal User Group who worked very hard to put together an event on this scale.