Collective

We’re a worker-owned agency that designs, builds and supports websites for organisations we believe in.

DrupalCon Europe 2020 - Finn's daynotes - day 1 morning

DrupalCon Europe 2020 skyline

An early start for us in the UK, with the first sessions starting at 8:15am! Still, at least we don’t have to find our way to the conference centre from an AirBnB after a late night catching up with old Drupal friends.

Session 1: Gitlab deep dive for Drupal developers

What better way to start the day than with a deep dive into Gitlab? At Agile Collective we use Gitlab to self host all our code repositories, and are increasingly using its other features such as issue tracking, so it was good to hear how others are using it for continuous integration and deployment. The session was presented by VladimirAus from Australia who spoke well and brought a number of features of GitLab to my attention.

Key takeaways from the session

  • Gitlab has a WebIDE built into the browser, so you can create files, edit code and commit changes directly from the web browser.
  • Gitlab’s issue tracking, kanban board and project and milestones makes it easy to track work and issues on a project by project basis.
  • Running automated checks on code is easy with Gitlab CI. This makes it easy to
    • check for PHP and Drupal coding standards
    • run automated tests such as PHPUnit or Behat
    • run any other scripts you might want to run after a commit
    • make merge requests dependent on successful passing of checks.
  • Using Gitlab CI to automatically deploy code to the hosting environments saves time and increases consistency.

 

 

The Gitlab web IDE
The Gitlab web IDE. Is the future is developing fully in the cloud?

Session 2: 4 years of Thunder: Why Hubert Burda Media went for open source

Thunder is a Drupal distribution for publishing houses. I am particularly interested in learning from other Drupal distributions to help us to improve LocalGov Drupal. The session was presented by Julia Pradel, Product Owner and Daniel Bosen Lead Developer of the Thunder project. Burda Group has over 600 products (online magazines), so they were looking for a more efficient way to develop, deploy, maintain and support all the sites. So they built Thunder.

They selected specific core modules and specific contrib modules that would help service the needs of a publishing house and then extended the distribbution with custom modules for the missing pieces of baseline functionality and to add all the 'glue code' needed to make sure that all the modules work well together.

Each site then builds on Thunder core and extends with their own modules and importantly, their own frontend theme. Thunder has no frontend!

4 years in and they have 30 websites using Thunder. Within the publishing industry, Burda Group are pioneering this commitment to, not only use open source, but also to be open source and contribute back to the Drupal community. They are hoping that what works for Burda should work for others. They see no reason why this shouldn’t model shouldn’t be adopted by other peers in the industry. Nothing to lose, lots to gain.

Julia related a big challenge in the culture shift required to be working in the open and to working with a wider community of Drupal developers. When new people join the Thunder team there is a need to explain again and again why the project is open source. From a personal level, I wonder how this same challange will emerge in the UK public sector with projects like LocalGov Drupal.

Interesting aspects of the thunder distribution:

  • No front end! They made a conscious decision not to try to make a front end theme. Allows us to focus on the essentials.
  • Happy editor UX is crucial:
    • easy and flexible sorting of paragraphs and deleting paragraphs
    • no sidebar - hidden by default
    • save / preview buttons are always visible, sticky at the footer

On the topic of working closely with Drupal core and contrib modules: 

  • The closer you work to Drupal core, the more complex the issues get.
  • Lots of conversations, takes lots of time.
  • But any common solution is better than a local patch. This discussion improves the quality of the system.

On testing, we automate the testing of as much as possible, including:

  • integrations with other systems
  • updating from old versions of Thunder to new version of Thunder
  • visual regressions
  • installing against future Drupal versions

On managing updates:

  • Drupal core is updated with composer on any specifc installation, so we don’t ship core.
  • For configuration, we use the Update helper module - only updates configuration that is exactly as we shipped it (avoiding the risk of overwriting configuration that has evolved on the target site)

What’s next for Thunder?

  • API First
  • Claro as an admin theme
  • Drupal 10

My key takeaways from the session:

  • Working in the open might be slower but does result in better quality
  • The content editor experience is crucial
  • LocalGov Drupal has much to learn from Thunder and other distributions.

 

 

 

 

Session 3 Documentation: Why and how to do it now!

A motivating talk from Qymana Botts (qymanab) to inspire us all to write more documentation and write better documentation.

Having spent a while collaborating on documentation for LocalGov Drupal at https://localgovdrupal.org/ I am keen to get any tips that might help us to foster a cultrure of writing great documentation as we go.

Qymana remindsds us that the purpose of documentation is twofold, to provide information about:

  1. how a system functions
  2. the context around a system

Documentation is dependent on the audience. Qymana divides it into "How docs" and "Why docs". She then breaks it down into the five Ws

  1. Who? Everyone. Everyone should contribute to documentation. If you do something that someone else might need to know how to do, document it!
  2. Where? Wherever people can find it!
  3. When? Now!
  4. Why: increase efficiency, improve workflow, mitigate ambiguity
  5. W... (I'm not sure what the fifth W was.... sorry)

How to do it:

  • Keep it concice, simple and navigable.
  • Don’t over-document.
  • Try recordoing it and then transfering it to text, you might be less likely to ramble or miss bits.

My key takeaways from the session:

  • It helps to have a super enthusiastic person to encourage other people to write documentation! (Nominate a documentation lead?)
  • Don't worry about perfection first time, write it and ask others to review!
Meet the Authors
Back to blog