Highlights from day 2 at DrupalCon Dublin

Yesterday, Emer Coleman discussed technoethics and what it means for both creators of technology platforms and society as a whole. Technology platforms and leaders (plus the large volumes of personal data) are a potentially dangerous combination for exploitation. 

Emer touched on the importance of democratic activism as a means of keeping these platforms and government policies in check. The takeaway message, for people who develop and work on these platforms, is to keep asking questions. Who does the work affect, what might be the consequences of that work and if, with reasonable explanation, would the average person affected be able to comprehend and accept the results of the new feature or product?

Mateu Aguiló Bosch delivered a superb overview of why JSON API matters to modern day software development. Not only does it reduce the amount of time consuming discussion around standards and other details (aka ‘bikeshedding’), but it also provides a common manner for other JavaScript based libraries, frameworks or connected applications to exchange data in a more efficient manner. 

Drupal 8 modules permit the ability to expose entities via the JSON API standard, and because configuration is now entity based, it potentially creates the ability to administer Drupal over an API. This could be very useful in decoupled applications, if you want to retain a single point of administration in a related application, but want to avoid giving administrative access to the native Drupal backend. 

Minds were blown at this prospect. OK, OK… probably just Johan’s! To top it up, libraries such as the JSON schema generation, or schemaform.io allow for self-generated API documentation and useful user interfaces for interacting with the API. We foresee lots of nice projects in this area in the near future.

Tom and Johan attended a BoF talk on ‘how to create self-organising, happy, distributed teams’. A lively discussion ensued and some common trends indicated that as agencies expand, traditional ways of organising teams (back end/front end development, design, marketing) can lead to inefficiencies and bottlenecks. 

A common thought pattern, is to explore the implications of creating smaller, focused teams within the organisation. The aim being to bring back the flexibility, accountability and client services that smaller agencies traditionally have. It’s not all plain sailing though and some common pitfalls include how to ensure accountability, quality, freedom and efficiency is retained without losing sight of the main organisational goals and objectives. For remote workers and teams, tools such as Screenhero received a nod and old favourites like Google Hangouts and Skype are still popular.

I learned lots from the ‘Practical caching in Drupal 8’ session. Much discussion was had relating to Drupal 8’s lazy builder functionality, which allows dynamic page components to be loaded at the latest possible opportunity and cached for as long as is reasonably possible. 

The cache bubbleability (hierarchy and dependencies over multiple levels) and the different variations (such as cache keys) were explained in a simple, yet effective manner. The code examples provided a few a-ha! moments and were well received. Another hat tip was given to the Renderviz module which helps to visualise and debug complex caching issues, as well as the webprofiler module/toolbar that has been inherited from Symfony. 

Bas van der Heijden from Dutch Drupal agency Immer gave a thorough and comprehensive overview of automating quality tools into the development workflow. 

Tools such as PHP code sniffer, PHP mess detector, SASS linters, JS linters and package managers such as composer, bower and npm are all marshalled by a task runner such as grunt or gulp. Your preference for any of these tools is purely subjective. By enforcing strict standards and performing static analysis of code, the quality of code produced is improved. Bas’ recommended workflow is oriented around merge requests (pull requests for Github fans) - which not only encourages code review but it simultaneously kicks off automated deployments… reducing developer involvement in what can be error prone, manual deployments. 

Interestingly, Bas’ team employ one code repository for development and another, totally separate repository for build artifacts and deployment. Separating concerns reduces complexity and makes it easier to roll back any problematic deployments. Bas also recommend Gitlab for its nice UI, features for continuous integration workflows and event issue tracking. 

We'll be back again tomorrow, to share highlights from day 3. If you have any questions for our dedicated DrupalCon team, why not message them on Twitter. @joblogs83, @wigglykoala, @rupertjabelman, @zerolab, @tomreadings and @rosenichols are more than happy to answer any questions you have.