Day two of Drupalcon London and it was definitely 'the morning after the night before' for a lot of people at Fairfield Halls in Croydon. Things were much calmer and the initial volume levels from the assembled masses more muted than on the opening day as many people nursed some sore heads. Nevertheless the main hall was packed by just after 9am in time for the days keynote from Tom Standage, Digital Editor from The Economist magazine. I wasn't too sure prior to the keynote what form his talk was going to take, but it proved to be extremely entertaining and completely different from anything else that is likely to be heard all week (or probably at any other Drupalcon for years to come for that matter).

Tom explained how the origins of social media went as far back as the ancient of Ancient Greece and illustrated many examples from throughout the ages of how the original media was social media and had been like that in one form or another for hundreds and thousands of years until the year 1883 when the New York Sun newspaper was founded. This was the first newspaper to use an advertisers funded model rather than subscriber/reader fee based model for a publication and changed the face of how media was produced and consumed. It went from being a two way exchange to a one way street, with a limited number of people (the editors) deciding what information was important for the readers to receive. The current form of social media on the Internet has reverted media and communication back to being a two way exchange, but Tom expertly led us from start to end of the history lesson in a very entertaining fashion. If the speech has been recorded and is viewable on the Drupalcon London website, I thoroughly recommend watching the whole thing, it is informative and entertaining in equal measures.

For the first more serious seminar of the day I decided to attend the one on Deployments and the features module. Features is something I first came across back at the Drupal London meet at Microsoft earlier in 2011 and wasn't really convinced about it. I've since seen the power of features bur still never had the chance to play with it firsthand. The seminar was informative covering topics like what should be in features as opposed to install profiles, use of drush make and how features are both upgradable and revertable. It went into a little too much detail from a novices perspective at times but it was a useful session overall.

After lunch (which I again skipped, 0 for 2 at eating at Drupalcon, aside from a can of Pepsi) I headed back to the main hall along with my colleagues from The Collinson Group (shameless plug) for a seminar on one of the most important topics for large Drupal websites, making Drupal perform 'like a rockstar' (I must point out at this juncture that I really don't like the term rockstar for any kind of web development stuff, leave it for musicians, anyway I digress).

Four main reasons were outlined for the slow performance of Drupal websites during this seminar, and they are listed below:

1. Full page renders - 200 to 300 SQL queries per page?
2. Dynamic content to anonymous users
3. Excessive/slow/non-optimised DB queries
4. Naughty modules

All of these were valid basic points, coupled with the fact that many drupal sites don't use any forms of caching, not even the caching built into Drupal by default! Different methods of caching such as Drupal's default caching, memcache and APC were discussed throughout the talk along with the benefits that each type of caching can provide. The use of performance measuring tools for page loading such as the devel module and something called New Relic (which I am not currently familar with but have seen it being advertised at this Drupalcon and I am very keen to try it out) was advocated as they will allow developers to work out where their load time bottlenecks are occuring (e.g. whether its the SQL (which is a common cause), the strain on the server from the traffic, or other reasons).

Another key aspect of Drupal performance that was highlighted is your sites MySQL configuration (if that is your DB of choice). Several settings were picked out as being key settings, though obviously not the only ones:

• key_buffer_size
• query_cache_size
• query_cache_limit
• table_cache
• sort_buffer_size
• myisam_sort_buffer_size
• tmp_table_size

The values of these need to be adjusted depending on the server hardware at ones disposal. It was also recommended that if you are using caching to check the cache expiry to see whether its renewing too often, and other good tips such as is path alias caching and whether your home page should always be cached, even if it has dynamic content on it (with a period refresh, how frequent depending on likelyhood of updates). Again this is a presentation where I would definitely recommend getting hold of the slides.

This was shortly followed by Robert Douglass (@robertDouglass) leading a very interesting session on the current state of Drupal in regards to apps and marketplaces for those Apps. This week Acquia (for whom Robert works) have announced their intention to have an app marketplace, initally for their subscribers and are hoping to make that public by the end of 2011. What I was not aware of is that two other companies - Subhub and Phase2 (who were both represented well during the session) have already launched App markets in the last year. Of the services to be initially offered on the Acquia marketplace, the one that really interested me was Visual Website Optimiser (or VWO for short) as we made very good use of this at WikiJob during my time there and its a fantastic SAAS offering, so that should be watched very closely for anyone with an interest in conversion rates and analytics.

The main piece of news to come out of this informative session apart from the discovery of the existing Drupal app marketplaces was that the three companies (Acquia, Phase2 and Subhub) are working together on an Open App Standard (OAS) so that developers only have to work to one set of specifications when building their apps but the apps would be able to be on many app stores (if they met the app store's individual business criteria), at least from the coding perspective. I think this is great for many reasons, not least of all they have seen the issues that have arisen with some of the mobile app development (android in particular) and are doing their best to make sure there are not the same issues with any Apps for Drupal.

Anyone wanting more information about the Open App Standard initiative, you can read about it at http://groups.drupal.org/open-app-standard/oas.

Finally for the middle day of Drupalcon the last session I attended was entitled 'A bulletproof plan for themeing' from the very good Rasmus Kalms (@kalms) from Copenhagen. He spoke a lot of common sense including how style guides can be very good tools to make use of and how they can prevent the need for designers to design every element of every page allowing the themers to use their brains, so long as they know what the basic page elements such as form elements, lists, content boxes, typography and images are supposed to look like. He also advocated close communication between designers, developers and project managers along with code review between front and back end developers. All things that may sound like common sense to some people but I'm sure its also something that a lot of people out there are not doing enough of (or at all in some cases).

Another sensible recommendation was for themers to organise their themes. Inside your main theme folder, to have subfolders for each type of template e.g. views, panels and nodes to name but three possibilities. We were also encouraged to take the plunge with HTML5 and CSS3, and to use things like CSS pre-processors which allow the use of such CSS3 functionality as variables, mixins (which look amazing), nested css and even basic functions. If anyone reading doesn't know what a mixin is, below is a basic example (I may not have the syntax 100% right but you get the idea):

.myclass {
   color: red;
}

.mydivclass {
   .myclass; 
}

Two drupal projects to look at in terms of preprocessors are Sass and Less (drupal.org/project/sass (or less)). I haven't investigated these myself yet but will be doing so shortly.

Overall, another great day at Drupalcon. I hope those who went to Batman enjoyed themselves, stay tuned for the final instalment tomorrow night.