After a few days at Drupalcon Barcelona I am only now finally getting down to posting my notes and thoughts on day 1. What a rollercoaster ride it has been so far! Many familiar faces, and many new ones. I’ll kick off with my notes from Tuesday and follow up with Wednesday and Thursday in due course.
Monday was spent at the Community Kickoff event, engaging with other people who organise local meetups, Drupalcamps and other events and people who want to set up meetups and camps but need advice on how to do so. It was good to be able to share my experiences with Oxford Drupal User Groups and the Oxford Drupalcamp with other community organisers. You can see the notes for one of the meetings here.
So Tuesday was the first day of conference sessions, kicking off with a keynote from the creator of Drupal, Dries Buyteart, affectionately known as the "Driesnote".
Dries’s keynote was typically mild mannered, and intelligent posing some difficult questions of the Drupal community and assessing what challenges lay ahead.
He talked about work life balance, pointing out that it is important to discuss these things with those close to you. He asks if Drupal is losing momentum, to which he answers categorically “Yes” because people are still waiting for Drupal 8 to come out, after nearly 5 years. Citing the Osbourne effect he predicts that there will be a huge spike in Drupal usage when we do get Drupal 8 out of the door, so we need to get it out soon to avoid a fate similar to that of the Osbourne Computer Corporation in 1985. He wraped up this part of the talk by stating that the remaining critical split issues have been split into multiple smaller issues to help tackle theses faster. and finally announces Drupal 8 release candidate for Wednesday 7th October.
Comparing market share of top CMSs Dries talked about the the Wordpress elephant (in the room), highlighting the common perception that Wordpress has the largest market share. He points out that this perception is true if you look at all sites in the world, but that the reality is different if you look at the top 100K or top 10K sites. The summary of this is that Drupal is in a great position in terms of market share for the largest and most popular sites in the world, placing Drupal quite firmly ahead for complex and high traffic sites.
In this section Dries argued that Drupal 8 will be way ahead of the competition in terms of technical relevance. For example, the RESTful power of Drupal will allow Drupal to power all sorts of apps, from web apps to mobile apps. He also talked about Graphql https://github.com/graphql/graphiql which I didn’t fully understand, but looked like a great way to query Drupal’s REST apis.
Key take aways:
Drupal 8 RC1 scheduled for 7th October
Drupal is doing well for larger and high traffic sites.
Drupal 8 will place Drupal way ahead of the immediate competition technically.
One of the most exciting Drupal 8 initiatives for me is configuration management. While this is perhaps not that exciting for our clients, for developing and supporting a Drupal site this is magic. We have long used the features module to deploy some aspects of configuration in code from the development site, to the staging site for testing, to the production site, but anyone who has ever used features for this knows the pain that this can cause (features was never really intended for this but was developed for Open Atrium to allow different functionality to be enabled in different group contexts on the site).
Configuration management now supports exporting all configuration as yaml files, commit these to your git repository and import the configuration on staging to test and production.
This still poses some questions. The general workflow being that configuration is deployed from dev to staging to live, and content coming the other direction, created on production, and pulled down to staging or dev for testing and further work. In this new world order, how to deal with config changing on live and on dev?
just say no!
push all configuration edits for through the standard workflow
Ther’s a module to help with that, forcing configuration to be read only : https://www.drupal.org/project/config_readonly
Good for discipline.
sync live database to dev, export the config, commit and push back up through the standard workflow.
this is probable the most common way
Also, when removing configuration objects, all dependencies will be removed. For example, if we remove a content type, all fields that only depend on that content type will be removed. This is wonderful news, and something which features module could never do well.
Key take aways:
Configuration management in code is great!
There is a growing number of contrib modules that extend configuration management functionality.
Configuration management will deal with dependencies in a logical way.
An introduction to Docker from Dave Numan, with a focus on bowline, a tool he has developed to help Drupal development with Docker. We currently use Vagrant and puppet scripts to provide our development team with consistent local development environments, so it is interesting to learn how Docker might help with this in the future.
One point he did make was this: “When choosing what tools to supply to your team, decide how you are going to support it”. As our team grows, this is incredibly important, so consistency, testing and documentation is important. The front end dev stack is one area that is moving so fast that we have had issues ensuring consistency across projects and developers, so whatever we are using this needs to be managed well.
One exciting point about Docker is that it can be used to manage your local development stack, your dev server, and your production server, further ensuring consistency between all environments.
Key take aways:
Docker might be a good way to impove consistency on local dev environments as well as servers.
Whatever solution a team uses, it needs to be supported with documentation and people who understand it.
Presented by Lukas and Tonio - both partners.
Goals of the talk
self organisation is possible
pros and cons of self organisation
real world example
Liip sounds like an amazing organisation. They are based in Switzerland and the company is fully owned by 113 ‘Lispers’ (84 full time equiv). 100% of the shares are owned within employees. There is a 6 person management and a 1 level hierarchy.
This is obviously of interest to me as it has strong parallels with our worker co-operative governance and ethos, also fully owned by the workers. Further to this, Liip is has four clear dedications:
care for environment, socially, ecology
This sounds very familiar! For example, the company will not fund air travel, but will fund train travel, which is the same at Agile Collective.
market growing and changing fast
finding new people
finding clients that are a good fit.
They went on to discuss the book that has inspired some of their decisions:
Interestingly, Liip has no:
5 year plan
just rough annual budgeting! I'm not sure if we would want to go that far, but I like the idea of allowing growth to emerge rather than be planned.
The way that they manage over 100 people to self organise at Liip is interesting. They have autonomous teams of 10 - 15 people.
every person can define their own goals and strategies
use all the skills
fixed (teams don’t change)
So each team can:
win new business
produce new work
People, it is all about the people!
ability to accept change and to trust people
roles are not fixed
rewarded with empowerment - additional salaries for everyone (14 per year?) everyone gets an extra 14th salary, or no one
structured salary system, based on points and annual reviews
So these guys are pretty revolutionary in standard business terms, but draw many parallels with our worker co-operative. I was interested to find out why they were not a worker co-operative. After speaking with the Liip guys, it appears that this has all been emergent rather than planned, which is perhaps even better than planning to be a co-op from the start.
If I had only attended this one session at Drupalcon, I would have been delighted, it was quite inspirational - and not even Drupal specific!
They Keynote on Wednesday was from Nathalie Nahai who talked about web psychology. A fascinating insight into why we interact with the web in the way we do. Watch the talk on the Drupalcon site https://events.drupal.org/barcelona2015/keynote-nathalie-nahai but skip ahead to about 12 mins to avoid the preamble.
A session about designing in browser to speed up Drupal development.
Referring to a blog post they discussed various benefits to design in browser including precision, responsive, transitions and transparency. They use technologies like gulp and browser sync to speed up theming, but also twig templating for Drupal 7, which was interesting to hear. There was also the idea that we should be designing components not pages, to allow designs to more responsive.
- use panels for all layouts
- custom templates
- custom panes for prototype
- panels everywhere
- some panelized nodes
- fewer templates to override
- custom views rendering, not using views rendering,
- execute the view
- render the nodes (teasers for example)
So in summary, using panels with custom templates allows rapid prototyping of designs and greater control over the final html that is generated. This is not something that we’ve tried so I will be interested to discuss this with the designers and front end developers on our next project.
- Try rapid prototyping with panels everywhere and custom templates.
This session blew me away with a demonstion DevShop, an open source product for managing hosting environments and testing Drupal sites. The system runs on Drupal with Aegir underneath and acts as a control panel to manage your Drupal environments across multiple servers. This looks similar to hosting control panels provided by Acquia and Patheon, but I must admit I've not used either that much.
An interesting integration with Github allows developers working on a feature branch to issue a pull request, which will automatically spin up a new testing site on the branch in question, run automated tests and provide a link for the project mamnager or client to test the work before merging back into the working branch.
We do develop Behat tests for most new projects, but on smaller projects it is not viable to run fully automated tests on an continuous integration server, so the idea that this can be easily automated is very attractive.
- Devshop has the potential to automate the process of managing multiple hosting environments across multiple servers.
- It could make automated testing much easier.
- It appears to be very easy to install.
Jody Lynn gave us an overview of best practices in menu arcitecture, url aliases and breadcrumbs as well as recommended modules. Jody recommended that urls should be hackable. This means that all parts of the url should serve up a page. For example if the url is agile.coop/blog/drupalcon then agile.coop/blog should also be a working page. She also argued that breadcrumbs should always be used and should follow the url path and menu structure for consistency.
- use a single menu hierarchy across the site
- set pathauto to use [node:menu-link:parent:url:path][node:title]
('path' may not show up in tokens, but is always available)
- always display a breadcrumb
- https://www.drupal.org/project/habitat is a useful module to enable or disable modules on different environments (disabling devel module on production for example)
- Other modules that should always be used:
- Interesting blog post from Lary Garfield on how breadcrumbs work in Drupal 8
Thursday was the final day of sessions at Drupalcon, and in a slight departure from previous years, the day started with two keynote speakers from within community rather than from outside.
The first of the two keynotes was from David Rozas, who was invited to present some of the research findings from his PhD on the Drupal community and Commons-Based Peer Production at the University of Surrey. Firstly I was impressed that someone was doing a PhD on Drupal, but the fact that it was specifically about the community made me sit up and listen hard, which was just as well as he talked even faster than I do and had a hell of a lot of facts. I will try to find a link to his slides, as they went by pretty fast but conveyed some good info. He mentioned that the the future of open source survey 2015 pretty much says that ‘open source has won’ with 78% of companies confirming that they run on some or all open source.
He went on to talk about “a new model of socio-economic production in which groups of loosely connected individuals co-operative with each other to produce meaningful products without hierarchical organisation...” which sounds kind of familiar! The naming of the concept of ‘ant-rival’ was new to me, enshrined as “the more we use, the more other people benefit”. I must admit that this is often an important argument in use to convince myself to try to use open source software where there might be a slightly easier tool or solution that is proprietary, perhaps as a trial of ‘free’ version, but not open source. The more I use it and report back to the developers the better the software will become.
The next part I picked up on was his polarisation of objective and community contributions. Objective contributions being tangible work such as code, docs etc. and community contributions being local meetups, DrupalCamps, volunteering, community training, IRC conversations etc. He points out the the community contributions are far less visible but almost certainly not less valuable. As the global community scales, the local meetups are absolutely key to generating and maintaining a sense of community. (Note to self, do more at OXDUG).
We need a new way to measure value in the community that includes community contributions, to which he points us at p2pvalue.eu. Highlighting mentors as a current example, we look at the profile page on Drupal.org, which have recently changed from listing username to displaying Github profile images of people that a given user cites as their mentors.
- We need to value non 'objective' contributions much more.
- As the Drupal community grows, this will be ever more important.
- Local Drupal meetups are key.
Mike Bell was the second keynote, which was as touching as it was important and earned a well deserved standing ovation. He talked to us about the importance of mental health in the open source world and in life in general. Mike suffered something along the lines of a breakdown in the last couple of years which changed his world pretty much overnight, leaving him unable to work and with anxiety, depression and imposter syndrome. He is much better these days, thanks to family, friends, work, CBT and medication and I have much respect for anyone who can stand up in front of 2000 people. It is probably better to watch his keynote from the recording than for me to relate every last detail, but you’ll need to skip forward to about 49 mins to get to the start of Mike’s talk.
One point I will mention was how Mike highlighted the word health in mental health, pointing out that through stigmatisation the word health tends to get lost. We all need to look after our own and each other's mental health and perhaps even more so in a community of enthusiasts who end up dedicating lots of extra time to Drupal, both in and outside of paid work. This got me thinking a little more about the ways that we can do that more at Agile Collective. We have started surveying the team on a weekly basis to check in on general team morale, which is a great start, but perhaps something a little more prescriptive may help us to uncover any issues early and catch them before they grow too large. This is certainly something I will take back to the rest of the team at Agile Collective, so thank you Mike for sharing your experiences!
- We all need to be more aware of our own and each other’s mental health.
- Recognise how you feel and ask for help if you need it. You can talk to your GP about anything, and it is confidential, which is good to know if you don’t feel you can talk to work, family friends.
- Could we have regular mental health checkups at work?
- Positive feedback for contribution is incredibly important.
- Burnout - plan how to avoid it both in the workplace and in the community.
This was an unexpected little gem, introducing the module / tool that is Webprofiler. As stated on the session page “The Webprofiler module can help you in understanding how all the new fancy things in Drupal 8 interact to convert a request in a response. “
I installed it quickly on a local Drupal 8 site and played along as we were walked through the various steps of the Drupal 8 request pipeline.
- Webprofiler is an awesome little module to help understand Drupal 8 and debug your code.
Summary: we suck at what we do, we break our design once every 10 days by deploying new functionality, developers are afraid of the live site, for testing pingdom is often the best we do so “How do you know your site is working?”
Enter: http://shoov.io/ (apparently ‘shoov’ means ‘again’ in Hebrew).
Shoov is a fully open source project by Amitai and Gizra that makes it easy to perform automated visual regression tests. Basically this boils down to taking an screenshot of your page at a given point, ie. when your design is looking good. It then uses webdrivercss (open source from people at sauce labs) to take further images and compare the original with the new image, pixel by pixel, highlighting any changes.
Some clever pieces of functionality:
- can host this yourself, or use the hosted option
- can test using browserstack on multiple browsers and operating systems
- deals with dynamic content:
- we can exclude, remove, hide elements through dom selector
- visual diff can be run against different environments
- live / staging / dev / browserstack
- shoov doesn't mind what language tests are written in
Amitai raised the standard objection that it “doesn’t provide 100% coverage” if we are only testing some of the page, to which he counters that 40% is better than 0% (with suitably humourous expletives in a way that I think only Amitai can carry off at a Drupalcon).
Key take aways:
- Visual regression testing could save a hell of a lot of time in cross browser testing.
- Implementing visual regressing testing even on a single page of a production site could help to avoid nasty surprises when deploying updates.
So that's all from Drupalcon this year. Were you there? What were your favourite sessions?