Warning: You are viewing old, legacy content. Kept for posterity. Information is out of date. Code samples probably don't work. My opinions have probably changed. Browse at your own risk.
Sep 3, 2008
Here's my Drupalcon Szeged review. Not a full account of what I got up to during the week but some of the highlights of the conference. The Szeged2008 website now has slides and videos, with more being uploaded as they are transcoded by archive.com so go checkout what you missed or revisit the sessions if you need a reminder. Here's my highlights from the event, in no particular order...
Really good to see some statistics on Drupal's growth over the past year. Strong growth in number of downloads and sites being deployed using Drupal. Slower growth than expected in usage of Drupal.org - raising questions such as where are end-users hanging out? where do users go for Drupal related info and help? Hopefully the redesign of Drupal.org will highlight and address the issues.
Other stats of interest:
Went along to the session on GIS with big hopes to get a better understanding of the current state of GIS in Drupal and how to implement. I was disappointed to learn that basically it's broken - and doesn't work. It sounds like things are moving along but the general confusion of this presentation didn't install much confidence on the current state of GIS - Location, GEO and GMap modules, in Drupal.
The modules presented were Location - for location input for nodes. GEO for
storage of location information. This uses mysql spacial so could be extended to store various types of geo information - but currently location just stores points. The other module in the suite is gmap that uses data from location module to display gmaps.
These are not the only way to do GIS in Drupal at the moment... A conversation with Mori over lunch that day made much more sense, in which he demonstrated the setup of GeoNames CCK and Geomap modules to do pretty much the basics of what I need to do in terms of GIS... I still need a good way to do proximity search.
Adding abstraction layers is OK, as long as you know the costs.
Rasmus talked about benefits of keeping it simple. He highlighted complexity victims as scalability, performance and security, and made some comparisons of various frameworks in terms of complexity and performance.
Rasmus covered some basic ways to optimize for performance... including opcode cache, coding styles such as removing require_once dependencies and simple things like the effect reordering php include paths can have on performance. The examples showed some impressive performance improvements.
Some of the framework results gave surprisingly large performance overheads, and luckily Drupal fared very well against even some more lightweight frameworks... plus it was noted by a comment from the audience that changes in Drupal 7 will help even further reduce the overhead. This is because of the further splitting of code into include files and only including the code necessary to serve the current request.
Rasmus made a really simple performance improvement recommendation to avoid calling the time() function. There's no need to do this as most of the time you can use the request time value from the $_SESSION variable that is available from the php environment.
Dries showed a couple of examples of how well RDF integrates with Drupal.
Rasmus did a good job of motivating the use of RDF, and advertised the yahoo initiative called searchmonkey. Yahoo is picking up RDF data in it's search index, and using searchmonkey you can tell yahoo what to do with it. Essentially you can define a plugin that works inside the yahoo search engine to display more useful results from your pages.
A basic development setup will use SVN, and have some concept of
development, staging and production servers. It's not obvious how these
concepts translate to Drupal development, particularly in handling
migrations from staging to production environments.
This BoF session aimed to bring out these issues and start some discussion on the subject.
A neat little trick was presented using SVN externals. This declaration essentially gives you a way to make one version controlled project reference the code in another versioned system. I think of it like a symbolic link from one repo to another.
Some hacks were discussed to get around problems encounted when migrating content between staging and production Drupal environments. These included a method hacking core to make the production server only assign odd node ids, and the staging server only assign even ids thus avoiding any conflicts. Another proposal was to hack core so there is
only a single source for ids, or creating migration scripts that rewrite sql dumps while moving from one system to another.
Drupal user alex_b said they had some code in their sandbox on Drupal cvs for a port module. It was also suggested that a group be set up on groups.drupal.org for further discussion, and that current known methods get documented as handbook pages.
...or so you would believe when you hear how many people turned up for the "testing party" at 9am in the morning! OK, so i have to admit i was hungover and didn't make the "party" but I made sure i didn't miss part 1 the day before - an introduction to testing in Drupal.
As of Drupal 7 testing is going to be in core. It's going to be a standard and required practice of all Drupal developers, and best of all Drupal makes it easy for us.
The simpletest module was presented, usage of the online web based testing gui, and they went through the preparation of a few test cases.
It was good to get a quick recap of the basics of unit testing - but even more interesting to see how it can be easily built using the testing api now available in Drupal.
Tests extend the basic class, and use the setup function to prepare the environment for the execution of the test. Then various test functions are defined which perform certain actions (either unit tests or screen emulation tests where clicks are emulated on a page), and then assertions are made - which are reported back as passed or failed.
Another complimentary module called code coverage was discussed. This is an awesome module as it checks the tests run against the source code and will tell you how much of your code is being covered by your tests. This then lets you identify either more tests which are needed to ensure full coverage of the code, or bits of code that are not required as they never get executed and should therefore be removed.
The main call to action from this session was to attach .test files to bug reports so that the errors can be reproduced easily, and included into future4 module testing so that further module updates don't re-introduce the bugs.
Some wise remarks were made during the session on attracting Drupal talent. This statement (the dentist quote) in particular was relating to remarks about knowing how many billable hours you have. It's not possible to do more than one thing at a time, you can't make more time.
This session covered some of the basics of managing projects and clients in the context of running a Drupal shop. I found it interesting hearing about how other people approach the process, from the initial client meetings, through to the relationship during development, and delivery of the final product.
One of the key takeaways from this session was about getting a knowledge management solution in place. Email is not efficient, and client hate basecamp, so some better system is required.
There was a lot of talk about usability at this Drupalcon, and this main session came in two halves. In the first half the two presenters talked about some basic usability theory, and made a call to action for creating a way for usability experts to feed back in the same way we have the issue queue for programmers - only that usability experts don't feel comfortable making usability requests in the issue queue which tends to deal with technical and programming requests. There was also talk of creating a widget framework that would make it easier for site builders to swap out ui elements for their own and provide a central place for ui builders to contribute and share their own ui improvements. all good ideas but no clear path forward was defined apart from continuing the discussions at groups.drupal.org.
The second part of this session was presented by Erik Stielstra and provided some solid recommendations for UI improvements for contributed modules. The presentation had two sections, the first was about documentation and highlighted the problems with finding documentation on modules. presented four places documentation is usually found:
README file, project page, handbook, and module help. The presenter gave good recommendations that in fact all four places should be documented, but that the documentation in each should have a specific purpose... let me see if I got the recommendations down correctly:
The presented then went on to talk about "the missing link" - at the point when you install the module - then what happens?
The recommendations for module developers were to set a drupal message in the install hook so that when you install the module some information is displayed to confirm that the module has been installed, and this message could contain a link to any extra configuration that is required.
The presenter then went on to talk about forms, and in particular module configuration pages. This included many good recommendations and any developer producing modules should watch this section of the presentation carefully.
My favourite recommendations were about not repeating yourself in form field titles and descriptions - but making sure they are used correctly. Titles should be short and scannable (i.e. contain keywords) and descriptions should only be used when they actually add information that will be useful.
The presenter also made some good comments about the mis-use of collapsible fieldsets, for example the correct use can be seen on search page where the advanced search is hidden by collapsed field because it's something that's not used very often. Incorrect use of collapsible fieldsets are when they are used to give an overview of the module setup. A preferred approach is to put the different sections of module configuration into tabs rather than hiding possibly essential bits of config in collapsed fields.
Other good comments that came out of this session were to minimise complexity wherever possible. This is key i think to improving usability in Drupal. Lots of modules include options that are not needed and should be removed. If it's an option not used by most people who use the module then it should be pushed out to a separate module.
Big changes from drupal 5 to drupal 6 include the improved menu system. Key reasons for the changes include scalability issues. Module developers need to understand the differences, and not use the hook_menu in the same way they did for previous versions of drupal.
One simple difference between hook_menu for drupal 5 and drupal 6 is the fact that the path is now the array key for the menu array.
Secondly the menu should not be used for storing links - this is now in a separate table and their are hooks for adding these links. Check out the full presentation for all the gory details.
It was also noted in this session that menu_link_save - the new way to add links - should be done in hook_enable - when the module is turned on - and not hook_install (when the module is installed).
Aquia presented the business module for commercial Drupal at this Drupalcon. They started the presentation by talking about some other successful commercial open source ventures, and then went on to present how the commercial Drupal service would be structured.
We saw the organizational chart for the new Aquia company, and they then broke down exactly what Aquia is offering...
Dries and Jay presented the proposed different levels of commercial support but it was disappointing for us UK based developers to learn that the basic support packages include support that is only available using east coast US office hours, and really showed a lack of concern about the global Drupal user base, and a clear indication that they are very US biased.
They went on to talk about the structure of the partner program. they made it clear that as a commercial entity they are not interested in getting into the business of building sites. They will be passing this on to their community of "Aquia partners". The partners get a small kick back from the subscription revenues for support services they sell and in return Aquia provides some basic support for the core and supported modules, and escalate any other support requests back to the partner who built the site.
In the summary remarks it was noted that there's a Drupal related event listed on groups.drupal.org for every day in September. This is certainly an exciting time to be involved in Drupal, and I'm looking forward to the next community event.
The next Drupalcon is going to be in US, probably east coast - yes we all know where but we can't say until the contracts are finalised. What about the next European Drupalcon? Well, it will be a while until this will be announced but I'm behind a Drupalcon in Berlin! That would be cool!