The keynote on the second day was from Emer Coleman, formerly of Government Digital Service, recently moved to the Co-op Group’s CoopDigital.
Emer talked about ethics in technology companies, and the responsibilities that we have a tech companies and tech communities. She wants to make sure that the benefits of the digital economy are more evenly distributed so that we all benefit from this new economy, and she spoke at the end of the great fit between this outlook and the co-operative values that are enshrined in co-operative companies.
She finishes by calling for those working in the tech industry to:
- Consider broadly who is affected by your work.
- Treat human beings with due respect.
- Ask how the public if reasonbly informed would view your decisions.
- Ask how the least empowered will be affected by your decisions.
These all resonate strongly with me and with the values of Agile Collective, being a worker co-operative.
She encouraged any developers who are interested in working for an ethical company to get in touch with Co-op Digital (or presumably other digitial co-ops).
I’d encourage you to watch her talk if this interests you in the slightest, it was a very interesting keynote. Jump to 16:14 to miss the sponsors and announcements. https://events.drupal.org/dublin2016/wednesday-keynote
Advanced web services with JSON API
This was an interesting session, outlining how the JSON API can be used to standardise communication between Drupal REST services and front end clients. One benefit to this appraoch is that front end frameworks like React JS have libraries that consume standard JSON API and build out forms or other widgets. So by standardising on the format of JSON we can swap out different front end or back end services and evolve our applications more efficiently over time.
My key takeaways
- https://www.drupal.org/project/jsonapi is worth trying.
- Front end frameworks that have libraries that consume JSON API will make developing decouipled font ends much quicker.
Slides and video are at https://events.drupal.org/dublin2016/sessions/advanced-web-services-json-api
7 hurdles to reach Scrum Drupal Nirvana in projects.
A rapid talk outlineing the key points to avoid common pitfalls when applying Scrum to Drupa projects.
- You DO need a dedicated scrum master!
- The Scrum master has a similar mission to the DA
- The Product Owner should not be the customer! It should be someone on the supplier side.
- The RETROSPECTIVE is the most important tool: review, adapt, improve
I was heavily distracted by urgent emails in this talk, so didn’t take many notes, so I might go back and work out what the seven hurdles were!
How Al Jazeera built a future-focused Digital Platform with Drupal 8
An exciting overview of what Al Jazeera are doing with Drupal 8.
Drupal was obvious and natural choice based on the enterprise requirements of Al Jazeera. Multilingual and extensibility being crucial. Al Jazeera are building on top of the Lightening distribution, which is developed and supported by Acquia. Cutting edge Drupal 8, with many dev modules and many patches, it is aimed squarely at enterprise content management where content workflow is a key requirement.
Al Jazeera rely havily on multilingual functionality, with a requirements for 5 languages on both the front end and the content management interface.
- many modules
- complex admin
- complex process
Core D8 solves many issues with internationalisation over content translation. We saw a quick comparison of multilingual requiring 22 modules in D7 but only 4 in D8, all of which are in core!
file entity vs media entity, two different solutions for media storage. (Lightning uses media entity)
Entity browser + entity embed (something Stephen demonstrated recently at Oxford Drupal User Group)
- can create multiple entity browsers for different types of media content.
Using https://www.drupal.org/project/brightcove for video storage and retrieval.
Different teams have different workflows to produce a story. All workflows need to have common checks for editor review and redaction.
This is built on top of the Lightening workflow feature (based on workbench moderation) with custom states for draft / published / archived etc.
Testing: Behat (lightning comes with a load of Behat tests!!!) to make sure the complex workflows don't break.
Content gets published to multiple web properties.
As an editor, I need to see:
- recent content on the site
- my recent content
- recent content from the content repo.
This uses Drupal core rest module, with views rest export on the content repository.
Deploy module is used with
- RELAXed web services
add README.txt in custom modules, to explain to the next dev what is happening!
My key takeaways:
The Lightning distribution is a great place to explore Drupal’s curent state of content moderation workflow.
Continuous Integration to automate your Drupal workflow
Bas van der Heijden
The talk started by looking at the preferred git branching methodology, in this case using one branch for each environment.
- Topic branch for dev work on local.
- Master branch for the main branch on development server
- Pre-production branch for a pre production server
- Production for the live site
- + hotfix branches for security fixes
Anything pushed to production branch is automatically deployed to the production server.
Different development VM for each project allows configuration to match the production server.
- Vagrant: if web server is all on single server, Vagrant makes sense.
- Docker: to mimic more complex environments.
They use task runners to automate all the repeatable tasks. Mostly grunt, for example:
- grunt vm: to boot up local machine.
- grunt theme: compiles all css and assets
Depending on the project, this grunt theme might use different compilation methods, but developers can always use grunt theme to start the compilation.
They use npm to rule the rest of the package managers
Interestingly these guys us two repositories for each project.
This has everything needed to build the project
- just code to be able to run in production server.
- build artefacts: compiles css etc.
This is potentially a better workflow than rsync or tarball release etc.
- git workflow that everyone understands
- reproducible dev machines
- separate concerns
Testing (static analysis)
Every time a git commit is made, a grunt test command is triggered to test the static code for a number of issues.
- Coder / PHP Codesniffer
- PHP Mess detector https://phpmd.org/
- php security-checker https://github.com/sensiolabs/security-checker
- php copy paste detector phpcpd https://github.com/sebastianbergmann/phpcpd
- php reaper - https://github.com/emanuil/php-reaper
- JS hint (sane version of js lint)
- scsslint - https://github.com/brigade/scss-lint
They use self hosted Gitlab for code, issues and deployment via continuous integration with Gitlab CI
Build stages and tasks
All this is specified int he .gitlab-ci.yml
- tasks: can run a script like ‘npm install’
- tasks: can have artefacts, that are the outputs of the task
- tasks: grunt deploy: ssh stage, drush cr ,drush cim -y
My key takeaways
- Gitlab CI is pretty flexible if used with other task runners.
- Make use of static analysis for code testing.