Developers' Day Schedule

A quick introduction to the day's events from a member of the committee.

Open Source communities allow us to contribute to so many things. There will always be work available and it never stops. It's all too easy to get caught up in everything and neglect our own health and wellbeing. We naturally want to help out, to improve something, to support others, to take on responsibilities, and to make our ideas a reality. This session aims to give you the advice and tools to support your Open Source ambitions without ploughing yourself into the ground.

Humans are not designed to work tirelessly and endlessly. At times we have to stop to look after ourselves. Taking a break might not be the easiest or most obvious thing to do. Many of us have responsibilities within the community and a lot of pressure sitting on our shoulders. It's okay to stop and look after yourself. This session explains how to activate self-care mode to let yourself recover. All whilst not letting anyone down in the process.

Many of us in the community are plagued by worrying concerns that hinder us in some way. Such things as, imposter syndrome, feeling overwhelmed, not feeling heard, not feeling accepted, and feeling scared. This session will face these demons head on.

Communicating effectively online is key within an Open Source community. We are a huge team from all over the world, and the majority of our communication takes place online. Miscommunication is all too easy when posting online. Worst case scenario it can lead to unnecessary frustration, conflict, upset, exclusion of others, and people leaving the community. This session contains the facts about online communities plus best practices for communicating online.

If we are to be part of an Open Source community, we must support others. We are all in this together and we depend on each other to get things done. Beginners need support to become part of the community. Long time contributors also need support, more than you think. We have witnessed people crash and burn, and also leave the community completely. There are many simple things we can do to support each other, this session will provide the tools to do so.

Imagine a venn diagram of your last software project. Consider three parts: what the code should do, what the code actually does and what the developers think the code does. The greater the overlap the more successful and bug free your software is likely to be.

This talk examines how to increase this overlap. We'll look at the importance of type hinting, assertions and things called value objects. We'll then look at how these techniques can be combined with modern IDEs.

By the end of the talk you'll have picked up tips on how to write cleaner software with fewer bugs that does what it's supposed to do.

An exploration of what happens from the moment a request is received by Drupal 8 and a response is returned.

I was once taught to 'code obvious, not clever’ - as a freelancer, it is critical that the code I handover is easy to understand, extend and integrate.

Let me take you through my process of developing pattern libraries and show the myriad of benefits this approach offers all aspects of the development cycle.

Drupal has themes, git has branches, gulp has tasks. What happens when your Drupal project has many themes and modules that all require task runners, when your git repo has overlapping work streams with different conflicting deployment dates and your sass, javascript and icon font resources are split between all of this. In an ideal world you build against this issue, in a real world you have to work around or with it. I'd like to share my thinking and experiences of creating a shared theme resource for a giant, global, multi-lingual, legacy, Drupal site.

Drupal 8 makes use of Composer - a tool widely used in PHP for managing dependencies.

Composer's introduction hasn't been plain sailing. There are now several different ways you can install Drupal, and a concern that this is one more barrier to entry for new Drupal users.

We'll try to address some of the confusion surrounding Composer, by answering these questions:

• What problem does Composer solve? Do we even have that problem?
• Drupal's documentation mentions "drupal/drupal" and "drupal-composer/drupal-project" as two alternative ways to install it? What's the difference? Can't you just tell me which one to use?
• The installation instructions I see talk about "8.x-dev". What if I don't want to use a dev version?
• I'm not very familiar with the command line. Is that now essential for Drupal development?

We'll also look at some practical tips if you decide to use Composer:

• Should I use exact versions or patterns for module dependencies?
• Do the dependencies go in the code repository?
• Do I need to run composer on my server?

A look at how making accessibility a key concern results in higher quality web experiences for everyone. Covering why accessibility matters, common challenges and how the web content accessibility guidelines can inform a better build.

I recently worked on a complex Drupal website for an insurance company. I'll be going through how architectural decisions were made, the challenges and solutions chosen. I'll be helping you avoid mistakes that were made or nearly made.

I'll be showing how I built a Quote builder in Webform, and based on the criteria selected, chose relevant Drupal Commerce products from a list of 5000 and added them to the cart. I'll be sharing how I harnessed the power of the Group module to build 4 tiers of access control including staff, branches, head office and client.

Public facing web sites are constantly under attack and keeping websites protected is an arms race, yet security rarely gets a look-in at specification and budget allocation stages of delivering a web site - or at best is an afterthought. Yet everyone has an expectation of security and QOS that implies it is central to every project.

Security considerations should pervade all stages of a project from initial specification, throughout development and testing and on to ongoing hosting and maintenance.

In this session I will cover:

• Common threats to web security with real world case studies of compromised sites,
• Simple approaches to mitigating common threats/vulnerabilities,
• Defence in depth – an overview of the various components of web security,
• Drupal specific measures that standard penetration testing often does not account for.
  An overview of how to benefit from:
• Security monitoring and log analysis
• Intrusion Detection Systems & Firewalls
• Security headers and Content Security Policies (CSP).

In this talk Adam and Louis, from miggle, will talk through some examples of ‘headless’ Drupal in both D7 and D8, where the user interface hasn’t been Drupal (or even screen-based).

We’ll cover:

• How we integrated Drupal 8 with The Student Room’s page building layer/machine; Nova, all of the other technology they use and the considerations we had to make.
• How we explored other methods of data presentation by writing Alexa skills for the Amazon Echo
• How we used Drupal 7 to manage JSON feeds which were used by other display media, like OOH billboards

Employers always want the best developers. Developers want to be the best. Blog posts, Twitter and Medium articles are rife with tips and tricks to be better, to hack/sling/ship/craft/bodge out better code more quickly, to be more productive etc etc... and if you're not top of the heap you're doing it all wrong and everything sucks! Allegedly.

I'm a web developer, now also managing a team of developers at an award winning digital agency (Torchbox). In this session I want to share my understanding of what qualities, priorities and behaviours really make a difference for developers of all skill levels and how to apply them to deliver value into any project or organisation you happen to be in.

This is a site builders level talk, and focusses on some of the breakthrough ah-ha moments I have had in my time as a freelancer.

I did this talk at Drupal Show & Tell, London at the beginning of the year. The idea for the talk came about when I was talking about how I wished that somebody had done a talk to try and bridge that knowledge gap and nudge people that don’t code into the right direction, using some of the more simple terminal commands and definitely drush and some drush aliases for syncing.

Once I started to use some of these tools my workflow became “supercharged” …

I also briefly go into some things in that area: about what it is like to be a freelancer and how the right tools for the job help us out here too ...

A short and light-hearted talk on why I'm a maker, told through a story from when the seed was planted to now. Talking about projects I've made or am planning, I aim to promote making in general, but also by drawing comparisons to other aspects of life, career etc. I'll go on to show examples of what other people are up to as well, to demonstrate the accessibility of making.

We know that code reviews are considered an important part of creating high quality software and to making ourselves and our teams better - some of us even do them! Why are they beneficial though, what pitfalls are there and how could the process be improved?

Lee talks about some of his experiences with the code review phase of the development process and the steps he is taking to try and make it more informative, smoother and quicker for the entire team.

Final closing remarks from the committee members.