Oct 29 2019
Oct 29

Hello from Amsterdam! Yes, the Amazees are on the road again, and it is time for Drupalcon Amsterdam 2019!

As my first-ever DrupalCon, I was excited to find out what the event had in store for me.  As a typical project manager, I had downloaded the app; decided which talks to attend, and was ready to go.

Luckily for me, Amsterdam is only a short hop skip and a jump from my hometown, Nuremberg, which meant I didn’t have to endure the more gruelling transatlantic flights that my colleagues had. 

Amazee Labs Barbara

With my bags packed, I headed to the airport, drank the obligatory coffee and boarded the flight for a comfortable one-hour to Amsterdam. As a Brit travelling between European countries, I always find it strangely unnerving to never have to show my passport.  

Embarrassingly, I seem to have my passport open and in my hand ready to prove who I am at every step of the journey. Even as I flapped my open passport at the airport staff at the gate, they looked at me as if to say, ‘unnecessary madam!’ 

The prospect of meeting Amazees with whom I normally only chat via video calls was exciting. Luckily a few of us had the same arrival time at Schipol Airport, so we met up there and headed to the hotel to unload the luggage before heading to RAI Conference Centre.

Arrival at Drupalcon

Firstly, the essential historical background. This year DrupalCon is being held at the RAI Conference Centre which is a lot older than I expected. Built in 1961, it sees over 2 million visitors through its doors per year and holds approximately 50 international conferences.

We arrived around 3 pm and promptly collected our badges. Then the first choice of the day was upon me, would I like a white lanyard or an orange lanyard? White would mean I didn’t mind being in photos, whereas the orange means that I did. As someone who notoriously takes a terrible photo (this is no exaggeration, it is a running family joke!) I sensed it would be better for DrupalCon if I took an orange lanyard, but I was living dangerously and opted for white. 

Amazee Labs DCA


The next stop was checking out the booth and lounge areas for amazee.io and Amazee Labs. The booth for amazee.io is situated near the main entrance and looks great! As an open-source container-based hosting company, the ‘container’ theme was strong on the booth, even the pens are held in a little blue container.

amazee.io Booth

Amazee Labs has a lounge in the Exhibit Hall which looks very welcoming, relaxed and is handing out blue rubber ducks!? Yes, you read correctly, blue rubber ducks! I had so many questions, why ducks? Why blue? Happily, a kind developer was on hand to explain the ‘joke’.

In the development world, there is a Rubber Duck Debugging theory. The theory comes from the book The Pragmatic Programmer and refers to how the software engineer would carry around a rubber duck and debug code by having to explain the debugging to the duck - genius! I was learning so much already. 

Amazee Labs Ducks

On a personal note, it was great to see Amazee faces in person and as always, the line ‘you are so much taller in real life’ followed. As we only really see each other from the shoulders up on video calls, we are genuinely surprised at the height of our colleagues.

The Talks

As I only arrived at 3 pm, I, unfortunately, missed the earlier events of the day, but to act as an introduction, the daily schedule looks quite similar throughout the week. The day starts with a Keynote talk and broaches a wide range of topics across the Drupal community.

The talks are divided into different categories: Business-marketing, DevOps-infrastructure, Drupal-backend, Drupal, frontend, Drupal community, Industry, and BOF’s. BOF stands for “Birds of a Feather” and is more of an informal gathering where like-minded individuals can dive deeper into certain topics of interest.

In the afternoon I attended a session by one of our own: Felix Morgan’s ‘The Good, The Bad, and The Data: Marketing Strategies for Open Source Companies’.

Amazee Labs DCA Program

As my background is in digital marketing, I find the topic of content marketing incredibly interesting, especially how many companies struggle with where to start when creating content.

Felix’s presentation was a perfect introduction to content marketing for open-source companies and acted as a guide on how to bite the proverbial bullet and start creating content.

Content creation is often considered time-consuming and smaller companies find it difficult to allocate necessary resources to this area of marketing. One main point I took away from the talk was the rule of three. If you need to answer a question three times, then you probably need content on that area. Also, content comes in all shapes and forms, such as documentation or conference talks. The Q&A session that followed was informative and particularly highlighted how employees from every job role can be involved in content creation.

Winding down for the evening

Following the close of the conference for the day, the Amazees headed off for a very educational tour at a local brewery, Bierwinkel. The friendly guide explained the brewing and fermentation process and then we all settled down for quite a few beverages and, in particular, a pinkish beer which seemed to be the most popular.

To soak up the pink beer, we enjoyed great conversation and tasty burgers before heading back to the hotel. I can’t express enough, the energy and warmth that Amazees share when we all come together. It has the atmosphere of a school reunion rather than a business conference.

Day one of Drupalcon completed and all I have left to say is, that I’m very much looking forward to the rest of the week.

Oct 02 2019
Oct 02

DrupalCon Amsterdam 2019 is almost here and Amazee Labs has been busily preparing to share our most valuable practices at this year’s open source, community-driven event.

DrupalCon Amsterdam gathers more than 1,500 of the top digital minds that use Drupal for collaboration, knowledge sharing, friendship, and moving their projects forward. As proud sponsors, presenters, and attendees, we can’t wait to bask in so much shared expertise, to help create collaborative solutions, build more relationships, and shape the future of Drupal, open source and the world.

Check out the details on all our Amazee session and other must-see events:

Monday, 28 October


Felix Morgan will be presenting The Good, The Bad, and the Data: Marketing Strategies for Open Source Companies. She’ll discuss how marketing strategies that focus on leads are only addressing one aspect of successful positioning for companies promoting and using open source software. In this introductory session, Felix covers marketing best practices specifically for businesses that are creating, customizing, and contributing to open source software for their clients. Topics covered will include:

  • Personas and Stakeholders: beyond just the buyer.
  • Community and Narrative: the stories we tell are important.
  • Data: what to measure and when.

17:15-1800 in Room G102

Tuesday, 29 October


Jamie Hollern and Mattia Simonato will be presenting a session called Storybook and Drupal: Seamless frontend integration for decoupled sites. This session will explain how to use Twig with Storybook and Drupal to bring all the advantages of UI component libraries into a decoupled Drupal project, and how to build a component library for decoupled Drupal sites. 

16:40-17:00 Room G106

Social Events 


Make sure you join us for the official kickoff on Monday night! Located within the Exhibition Hall, the opening reception for DrupalCon promises to be a great time, followed by The International Splash Awards, celebrating the best Drupal projects in the world. 

On Wednesday, all women, trans* individuals, and those who identify outside of the gender binary are invited to Women in Drupal Luncheon to have lunch, mingle and meet Professor Sue Black and enjoy a small introduction before her Keynote speech: “If I can do it, so you can”.

Wednesday night, test out your Drupal knowledge! In the grand tradition of pub quizzes, capture the title of Drupal trivia champion and win small prizes to boot! You can even SUBMIT TRIVIA QUESTIONS here.

During the con, make sure you stop by Amazee Labs Lounge to kick back and charge up. We hope to see you in Amsterdam for all the passionate presentations and in-person, peer-to-peer discussions with Drupal Leaders.

Sep 25 2019
Sep 25

Our dedicated Global Maintenance Team works diligently with our clients to keep their sites updated, secure, and fresh. In this blog, we’ll outline three common maintenance practices we use to keep our clients happy and their sites running smooth. 

Quick Response Times

Regular maintenance can prevent many common issues, but even properly updated sites can have problems. And, when they inevitably do, clients need a quick response – that’s precisely where our team excels. Whether a site is down or clients need help editing content, we’re ready to help. 
 
We use the same channels of communication both internally and externally and this is one of the reasons we have such quick response times. All of our client conversations about projects take place in Slack, so clients can raise an issue at any time and get a quick reply from anybody on the team. This can mean we can take action immediately, whether it's by troubleshooting over chat, creating a ticket for support, or escalating the task for immediate action.

In all cases, we’re able to deliver swift and transparent solutions for our clients because we are able to communicate directly with them.

Backups

Accidents happen, and when they do we can help. In one recent situation, a client deleted a user and subsequently deleted all the content associated with that user as well. It wasn’t immediately clear what had happened, but the site’s performance was suffering. We jumped in to investigate and found the root cause. From there, it was only a matter of contacting amazee.io (our favourite hosting provider) to restore the old back-up on production. After that, everything came back to life and went back to normal. We were able to investigate and solve the client's issue in a transparent and timely manner.  

amazee.io Drupal Example

Audits

We have maintenance and support clients that come to us after building their sites with our Amazee Labs Development Team, as well as clients who hire us to take care of sites built elsewhere. Maintaining existing sites built by other agencies means the code may or may not be in great shape. Every time we onboard a new client, we audit their site. During this process, we check if the modules or core are hacked, patched or up to date. We also check the caching settings and any custom code. Once we’ve done this, and fixed potential issues, we fully onboard new clients into our systems and tools (Github, Lagoon, Jira, etc). 

Site Audit Example

Drupal updates (... and patch parties)

We help our clients understand the importance of frequently updating their sites. In most cases, updates are lightweight and come with instant benefits, like performance and security. Updating the core and modules that make up a site is a common task for our team. For clients that prefer to update their sites less frequently, these updates can be done periodically or in batches. But critical security updates are a different story. 

Security Advisories Example

Every now and then, critical security updates are released for Drupal core or specific modules. These updates need to be pushed immediately because neglecting them can make a site vulnerable to hacking, a loss of data, or both. For critical security updates to be implemented quickly, the maintenance team holds patch parties. 

During a patch party, we get team members from all around the world to focus on making sure all our clients’ sites are secure. For some sites, we have automation scripts, for others, we need to do things manually. Either way, we get all hands on deck to monitor everything and keep our clients updated.

During these concerted efforts, it’s great to have a globally distributed team so we can work continuously to make sure every site is updated, functional, and secure. 

Important events

One of the benefits of keeping our client communication in Slack  –  it’s visible to everyone on the team. That way someone is always available to help and the client is able to monitor its progress.

For important events on certain sites (newsletters, leads exports, etc) we use Slack integration to make sure everything runs smoothly and everyone knows what’s happening and when. You can read more on the subject in this blog post.

With the right tools and our dedicated team of experts, we make sure our clients' sites stay secure and up to date. Stay tuned for more blog posts in this series. 

If you’d like to learn more about the benefits of keeping your website well maintained and ahead of the competition, drop us a line. We’d love to hear from you. 
 

Aug 22 2019
Aug 22

The first part of this article described why and how the stakeholders of a project can contribute to Drupal. This developer-oriented article is a summary of the Drupal.org documentation for new code contributors. We will cover: how to work on the issue queue, how to publish a project, and how to approach this process with Drupal 9 in mind. 

Before we start, let’s just remember two things:

  • Contributing is easy and not only for senior developers. Even the smallest contribution matters, this is the summation of those contributions that make the community and the codebase strong.
  • You are part of a community. A great way to get started with contribution is to find a mentor at a Drupal event, and there is always someone ready to help on the Drupal Slack #contribute channel.

The Drupal.org issue queue

While working on client projects, you might encounter core or contributed bugs or you may need a new feature.

Chances are that this issue has already been discussed in the issue queue that covers the Drupal core or all projects, including contributed. If your issue is not yet in the queue, use the issue template summary to file one. You might also check this page about creating good issues.

The main process for an issue is Active > Needs work > Needs review > Reviewed and tested by the community (RTBC) > Fixed > Closed.

When the issue is fixed or closed, the project maintainer will include the changes in the codebase (dev branch) and will most probably wrap it with several other closed issues into a  release. Read about the semantic versioning model.
If you need the patch before the release, you can include it in your client project with Composer.

If the issue has not been reviewed/tested yet, just make sure that you are using the right version of the Drupal core or contributed project.

Project Version

From there, the main tasks you can contribute to as a developer are:

  • When the issue needs review: manual or automated testing
  • When the issue needs work: re-roll or create a patch.

We will summarize the process of creating a patch below:

You can also find novice issues and continue your reading with the Novice code contribution guide and the New contributor tasks: programmers.

Create a patch

Now that the codebase is on GitLab, there was a proof of concept for fixing a trivial issue on Drupal.org using only the issue queue and GitLab.

For most cases, you still need to use the following flow.

Create the patch from the issue branch

The branch is the one from the Version meta on the issue.

Drupal core: https://www.drupal.org/project/drupal/git-instructions
Contributed project: click on the Version control tab

Version control tab

Follow then the git instructions on the page to create the patch, basically:

  • Create a new branch: git checkout -b [patch_branch]

  • Make your changes then review them with git diff

  • Add your changes with git add

  • Output them as a patch file
    git diff [base_branch] > [description]-[issue-number]-[comment-number].patch

Submit the patch

Once your changes have been made, upload the patch on the issue, then include a comment that describes your solution and everything that will facilitate the review, like screenshots or interdiff.

If there are unit tests available, request a test for your patch, then set the issue status as “Needs review”.

Needs review

Contribute a full project

Workflow

There are several ways to go, but this procedure works well for us while working for client projects on a module (or theme) that could be contributed.

The first iteration is built straight on the client project repository with a generic name until the related ticket testing is finished, so that:

  • reviewers can check all the code in one place and most likely they already have an environment running with exhaustive data for testing.
  • if the ticket is reopened, the process is simplified (there is no release to maintain or Drupal.org process involved).

Using a generic name still favours reusability among other client projects if we decide that it will not be contributed on Drupal.org yet. We can then isolate it in a dedicated repository, then include it via Composer.

Publish it on Drupal.org

1. Make sure that your project contains the following files

  • The composer.json file that contains the project metadata + system requirements (e.g. ext-json), third party libraries (e.g. solarium/solarium) and Drupal dependencies (e.g. drupal/search_api).
  • The [your_project].info.yml file with the Drupal dependencies, prefixed by their namespace (e.g. drupal:node or webform:webform_ui).
  • A readme with the use case, the dependencies, related projects (and how this one differs), a roadmap if the project is not feature complete.

2. Fix and check coding standards

  • Autofix with phpcbf: phpcbf --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md /path/to/project
  • Check what needs to be fixed manually: phpcs --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md /path/to/project

3. Create the project page

Most likely, it will be a Module or a Theme: https://www.drupal.org/project/add

Give it a name and a machine name.
Add the key points: project classification, description (the project readme is a good start) and organization. Make also sure to add other maintainers if you are working in a team.

4. Create a first, unversioned, dev release

  • Create a dev branch (e.g. 8-x-1.x) and push the code
  • Follow instructions on the Version control tab.
  • Not mandatory, but it is recommended to create a clean installation with the latest release of Drupal so we’re sure about 2 things: all the composer based dependencies are resolved properly and there are no side effects caused by the client project.
  • At this stage, other developers might include your code in the project with composer require drupal/your_project:1.x-dev
  • On your client project, as there is no semantic version release yet (e.g. 8.1.0), it is a good habit to add the commit hash so you make sure that you keep control over the codebase that is actually used:  composer require drupal/your_project:1.x-dev#commit

5. Create intermediate versioned releases

When the development is ready, you might create alpha then beta releases.
Beta releases should not be subject to api changes.

  • Check out the latest dev branch commit: git checkout  8.x-1.x
  • Tag it: git tag 8.x-1.0-alpha1
  • Push it: git push origin tag 8.x-1.0-alpha1
  • Create the release and document it. This article from Matt Glaman provides great information about creating better release notes.

6. Create a stable versioned release

When there are no open bugs and the project is feature complete, a first stable release will tell site builders that the module is ready to be used (e.g. 8.1.0). Follow the same steps as 5.

7. Apply for permission to opt into security advisory coverage

Follow the security review process.

8. Create a new major release

If there are backward compatibility changes, creating a new major release (e.g. 8.2.x)  will indicate site builders and developers that there are BC breaks.

Read more with Best practices for creating and maintaining projects.

Be prepared for Drupal 9

TLDR; Drupal 9 should be released in June 2020. The first version will be about removing deprecated APIs and getting new versions of third-party libraries (Symfony 4 or 5, Twig 2, …). So, if a Drupal 8 project does not use deprecated code, it will work in Drupal 9 :)

Drupal 8.7 started the deprecation work and 8.8 will define the full deprecation list.

Code contribution is needed there as well: on the core with issues like deprecating legacy include files, or by helping contributed modules to be Drupal 9 ready and fixing contributed modules Drupal 9 compatibility issues.

Codebase analysis tools

Several tools are here to help if you are contributing to issues or maintaining a project.

The upgrade status module scans the code of the contributed and custom projects you have installed, and reports on any deprecated code that must be replaced before the next major version.

Drupal-check, a static analysis tool based on PHPStan, will check for correctness (e.g. using a class that doesn't exist), deprecation errors, and more.

Further read about Drupal 9, how to prepare for it and analysis of top uses of deprecated code in Drupal contributed projects in May 2019.

Developer toolbox

Here is a brief recap of the tools that might help you while contributing.

Other ways to contribute than code

There are more ways to contribute, even if you are not a developer, the Drupal community is looking for

Read more about contribution on the Getting Involved Guide.

Jul 29 2019
Jul 29

Decoupled Days is a conference for anyone who works with decoupled Drupal technology: developers, architects, executives, and even marketers like me. It’s been around since 2017 and focuses on sharing knowledge about back-end CMS development as a content service as well as front-end development for applications that consume that content.

Amazee Labs has specialized in innovative decoupled development for years, and we were excited to sponsor and speak at this annual event. Amazees travelled from all over the world to present, learn, share, and enjoy the chance to hang out face-to-face with coworkers we usually see only on computer screens. As a non-developer attendee, I was there to help man the booth, share what was happening on our blog and social media, and make sure our usually-distributed team got plenty of chances to enjoy the city and each other’s company. 

DD Team Working

After getting settled at our charming hotel in the middle of Manhattan, I met up with Amazees from all corners of the world for drinks at a rooftop bar with beautiful views of the city. I sat at a table with colleagues from Cape Town, Zürich, the UK, Taiwan, Spain, and even Upper Manhattan. We talked shop, of course, but also got to have some much needed social time. Amazee has such a rich distributed culture that I often forget I haven’t met certain team members in person until I’m surprised by how tall they are. On Zoom, I suppose, we’re all same height. 

DD Table

On the first day of the conference, we set up our table, featuring some cool swag including some custom headless horseman stickers we made specifically for the event. The Drupal community is unique in its tight-knit community and at every event, I’m struck by people’s passion and excitement to share their knowledge across companies and specialities. What a difference an open-source perspective makes. 

DD Jamie

DD Fran

DD Bryan

There were some great technical sessions over the course of the conference including Stew West’s Intro to GraphQL and Twig, Jamie Hollern’s presentation on Storybook and Drupal, Fran Garcia-Linares talking about GraphQL V4 and John Albin Wilkins presentation about Gatsby and GraphQL Schema Stitching.

From a business perspective, Pascal Kappeler and Stephanie Lüpold discussed an interesting case study and Bryan Greenburg talked about how to Decouple Your Team.

Michael Schmid shared two sessions from the amazee.io perspective, one was a look at best practices from over three years of building and hosting decoupled sites, and one about caching decoupled websites to improve speed.  

DD Amazee Ladies

It was a lot to cover in a couple of days, but everyone at the conference seemed energetic and excited to be there. On breaks, we got coffee and found cute lunch places to meet up with people we knew, or people we’d just met. For me, the highlight of the week was our team dinner, where we sat down as a group to eat, drink, and laugh together as an Amazee family. 

Jun 26 2019
Jun 26

We are proud to announce that Zürich Tourism has been chosen as this year's recipient of the annual German Brand Award in the categories of Excellence in Brand Strategy and Creation, and Brand Communication (Web and Mobile) for its work on zuerich.com -- a collaborative project with Amazee Labs and Studio Marcus Kraft.

Zürich Tourism is at the helm of the region’s national and international destination marketing.The province of Zürich receives hundreds of thousands of visitors from all corners of the world each year. The Zürich Tourism website serves a wide range of tourists from different cultural backgrounds, as well as online interests and needs. 

zuerich.com is now a central content hub within Zurich Tourism’s content marketing strategy to show the city and region at its best. Since the site was relaunched, the new website for zuerich.com has impressed visitors and users by balancing abundant content with exceptional navigation and UI.  

This project is a milestone for the client. Amazee Labs was tasked with overhauling an extensive amount of code made from multiple agencies over time. The result is a state-of-the-art Drupal CMS that allows for smooth content editing, a dynamic filter with theme pages tailored to the users with a modern CI / CD and exciting visual experience created by Studio Marcus Kraft, a Zürich-based design agency. This social content encourages and inspires people to discover Zürich and the surrounding area in ways that appeal to different kinds of visitors. 

We’d also like to thank our partners for making this project such a soaring success -- our client Zürich Tourism, for this incredible opportunity, and Studio Marcus Kraft!

To all of this year’s winners and nominees -- Congratulations!
 

Jun 19 2019
Jun 19

As a follow up of the articles from my colleagues Philipp and Blaize regarding Open Source as a business model and a career perspective, I would like to describe WHY and HOW we can contribute to Drupal in our daily work, on client projects.

This article is aimed at the stakeholders of a project. The second one from this series will focus on the technical aspect of contributing to Drupal in this context, and thus will be more developer oriented.

The WHY


The Developer Perspective
I will cite my colleague Blaize here: This is not simply about developing your taste, or reading code, but learning about the collaborative nature of programming. Contributing is the perfect opportunity to apply some inherent collaboration principles. Mentoring and pair programming enables your team to share knowledge and skills, cultivates mutual respect and ultimately improves the quality of the codebase and the documentation.

The Client / PM Perspective
Among other benefits, generalizing the components of a client project for Open Source can lower costs and technical debt and favours a clear and well-documented maintenance flow. Generalizing these components enforces modularity and documentation and thus offers flexibility while working with several teams or onboarding new team members. Gathering feedback from a broader user group helps to identify earlier new use cases and edge cases.

The Community
The Drupal ecosystem is powered and diversified by contributions, so encourage your team to join community initiatives and promote the company expertise.

The HOW


Identify Opportunities
Here is an excerpt from our internal documentation that summarises pretty well the leading theme that drives our development team:

Maximize open source: Lower initial costs, technical debt and maintenance costs by using and contributing to open source code as much as possible. For every feature required by a project that is not solvable by configuration or theming, try to find a generic solution that can be contributed (...)

Set the Contribution Scope


Extend an existing Drupal project
Contributions should improve the ecosystem by checking if existing solutions are already matching a use case. Extending an existing project can be achieved by:

  • Porting a project to Drupal 8
    
The required solution could exist for a previous version of Drupal. The Drupal 8 Contrib Porting Kanban can be used to get an idea of the remaining tasks. 

  • Creating a patch or a submodule

    An existing contributed project could meet, let’s say, 90% of your use case. The 10% left can be covered with a patch then contributed back.

  • Writing unit tests

    If the contributed project is critical for your use case, widening the test coverage might be a good way to ensure that every feature is working properly.

  • Making a project Drupal 9 ready

    Help to remove deprecations for Drupal 9 compatibility.


Create a New Project
The initial development of a generic solution can cost more (time/budget-wise), averaging between 2 or 3 times more. So before starting, here are a few points that could be considered. Does it implement a generic feature? Can the exceptions be configurable? Can this set of features be shared between projects? If they can be deployed in at least 2 or 3 projects as is, that is probably a good indicator.

Can the feature be isolated into a generic (packagist) library or reuse a generic library? This is often the case for third-party libraries like APIs. Is the initial release feature complete or does it allow progressive enhancements? It will give a hint about the needed maintenance time. Can it be maintained by the company that develops it? Does it fit internal or community feedback/contribution?

Integration to the Company Culture


Defining a development workflow will save you time
As a first evaluation, if it’s uncertain that the project will be reused, choose a generic name (not client specific) so it could be shared at a later stage without modifying the codebase. Use an easy-to-grasp name, one that reflects a single responsibility. If the project is doing too many things, it could be divided into several projects or submodules. 

Create a readme to allow quick developer onboarding. Move it as a standalone repository (GitHub, GitLab, Drupal.org, ...) and require it via Composer. If possible, split the generic features into packagist libraries and wrap them into your Drupal project.

If you are using untagged branches (e.g. a unique dev branch) set a commit hash via Composer to be sure that you are using the right version in your client project. Make your project discoverable internally, also to non-developers. Especially when there are several teams, so it will favour cross-project management. Make it public by creating a Drupal.org release and discoverable externally: document it, share it on social media, write a blog post.

Developer Onboarding and Documentation
If the project is released on Drupal.org, make sure that your team is familiar with the contribution processes like semantic versioning, maintenance, release and external contribution policy, and the code of conduct.

Add your team members as project maintainers and remote contribution tools: like how to do patches and interdiffs, apply coding standards (phpcs / phpcbf), write unit tests, …

The sprint participant cards could be a great way to gamify your internal contribution sprints.

Sprint participant cards

Open up your project to an internal/external contribution by making sure everybody can start quickly. Create or update the readme file and project documentation (site builder and developer) and set a clear roadmap by creating task issues on Drupal.org so the goals and current status are clear. Use the issue template summary and compare other related modules on the project page.

Resources

In our next article, we will give a brief introduction to the following points:

  • Work on the Drupal.org issue queue: create patches, re-rolls and reviews

  • Publish a project on Drupal.org and be prepared for Drupal 9



Jun 12 2019
Jun 12

Decoupled Days 2019 is almost here and Amazee Labs has been busy gathering the most valuable practices we’ve discovered since last year to share with the community.

Amazee Labs is proud to sponsor Decoupled Days, a conference for architects, developers, and business people involved in implementing decoupled CMS architectures. Since successfully debuting in 2017, its mission of sharing the experiences with both back-end CMS development as a content service and front-end development of non-CMS applications consuming CMS content (especially those in JavaScript) has been a success for everyone who’s chosen to be involved.

See what we’re sharing at this year’s conference:

Wednesday, 17 July

Jamie Hollern will be presenting a session called Storybook and Drupal: Seamless frontend integration for decoupled sites. This session will explain how to use Twig with Storybook and Drupal to bring all the advantages of UI component libraries into a decoupled Drupal project, and how to build a component library for decoupled Drupal sites. 

13:45 pm in Room 2 
 

Learn how to Decouple your teams using GraphQL with Bryan Gruneberg. In this lighting talk, he will present strategies to decouple your team by putting GraphQL at the centre.

16:30 pm in Room 3 


Pascal Kappeler and Stephanie Lüpold take on Shaping the future of decoupled Drupal: An unusual case study. This session they’ll show how an SME can drive technical innovation at scale, but that it is made possible with the help of a corporate partnership. If you are interested in getting a first-hand account of how two very different companies work together, in order to push technical boundaries, this is the right session for you.

15:45 pm in Room 2 
 

Join Fran Garcia-Linares who will delve into the question GraphQL V4: what's next? In this session, Fran will outline all the exciting new features that are (or will be) included in the 4th version of GraphQL module for Drupal and the new possibilities they open up for us/for those in the know -- like support for SDL based schemas!

16:00 pm in Room 2 
 

Thursday, 18 July

John Albin Wilkins will discuss Gatsby and GraphQL Schema Stitching with Drupal, the benefits of a universal GraphQL graph over traditional web services like REST and JSON:API, configuring Gatsby’s gatsby-source-graphql plugin and more. A demo website, including full Git repository, will be provided for attendees to try out.

11:15 am in Room 1 

Decoupled Drupal is the future, but learning an entirely new stack can be daunting. Stew West presents GraphQL and Twig, a beginner’s guide and demo on how to use GraphQL and demonstrate the advantages of changing the Drupal push model to a pull model by letting the template define its data requirements.  

16:15 pm in Room 1

You should also check out these sessions from amazee.io and Michael Schmid

In this session, Michael will demonstrate how Caching decoupled websites is hard, but freaking fast if done right and share his best practices around caching of decouple websites, things that work, things that didn't work and how we are running websites today.

18th Jul at 09:00 am in Room 1

Michael Schmid presents 3 Years Decoupled Website Building and Hosting - Our Learnings. In this session, he shares what we’ve learned as a business so far and what we envision for the future. Attendees will walk away with insights into how decoupled projects can affect everything from hiring and client relationships to profits, processes, maintenance and more. 

18 July at 11:15 am in Room 2

Catch up on a year’s worth of Amazee Labs’ best practices in just two days at Decoupled Days 2019.

May 23 2019
May 23

Through the late 90s and through the early to mid-2000s there was a great rivalry, Open Source versus closed, proprietary software. At times it got ugly - any of us working at that time will remember the “Linux versus Windows” flamewars and the Microsoft-as-the-Borg memes (before “memes” were a thing). But all the ire directed at MS could arguably be justified - recall the so-called “Halloween Documents” or Steve Balmer declaring that “Linux is cancer”.

How different did things look to a programmer at the end of the second decade of the 21st century? To some extent, the “war” is over. Open Source Software is ubiquitous across the entire stack, from server infrastructure to front end frameworks.

My guess is that you’d be hard pressed to find a modern software project that doesn’t involve Open Source in some way.

If I were to attempt to answer the question “how can you use open source to your advantage” twenty years ago, the overall thrust of my suggestions would look a lot different than they do today (and possibly a lot angrier). I don’t have to convince you or the utility of Open Source. History has already done that for me.

If you’d like a rundown of the reasons that people ordinarily use to justify why you should investigate/use Open Source, you’d be hard pressed to find a better summary than Michael Tiemann’s whitepaper “How open source can save the ICT industry $1 Trillion per year”.

I’d like to suggest a few, more personal, reasons how you might use Open Source to your advantage. Think of them as expanding circles of concern, first for yourself, then your immediate community, and then for the world as a whole.

What others give to us

I’m not suggesting that you can use Open Source software to beef up your resume, which I’ve seen argued again and again. Rather, I’m speaking to those programmers who genuinely care about becoming better at what they do.

There’s a deep satisfaction in progressing at your craft - whether that be writing poetry, painting, or coding - and there are at least two parts to this. The first is actually producing, writing new poetry or code. That’s vitally important. But there’s a second, arguably more important, and often forgotten part.

That is, developing your taste.
Your eye.
Your sensibilities.

Ira Glass, in his much-shared piece, speaks about “the gap” that exists in any artist between their taste and what they can produce at any time.

The suggestion is that becoming a better artist is about producing a lot of work so that what you’re making begins to line up with what you consider great. Your taste guides your practice.

With visual arts or prose, developing your taste seems to be simpler. Those writers can read a lot of poetry. Those artists can visit galleries and view hundreds of the best works that history has to offer. Further, there’s a long tradition of critical literature that reaches at least as far back as Aristotle that can help inform us, help further develop our taste.

While the field of critical code studies is relatively new and we don’t yet have quite the mass of critical literature as poetry or visual arts (it does exist, though -- this is a wonderful example), the fact that there are just so many examples of truly great code that we’re able to read and learn from means that the problem of developing taste, and thus knowing what great code is in your bones, is made far simpler.

Fabian Sanglard, for instance, suggests that anyone wanting to become a great C programmer should read the source of the games Doom and Quake. Closer to my own concerns, being a web developer, I might suggest to a junior on our team to read something like Elloquent’s Collection class for an example of an elegantly structured set of abstractions, or the code for the Slim Framework to get a clear idea of how precisely middleware works.

What we can give to others

This might be the most personal (for me) of the three ways you can leverage Open Source software, and I doubt it will resonate with everyone - but it might, so it’s worth mentioning.

The first time you ask a question can be terrifying.
The first time you submit a bit of code to a project can be terrifying.
Making a mistake in either of these can be mortifying.

And yet, learning to be brave enough to ask questions, to make suggestions, to submit PRs - is a vital step to becoming a better developer.

For some, these steps are taken in their first jobs, within the context of a team, sometimes with a mentor. For most, I’d bet, this is not the case.

Open Source projects are the perfect place to get this kind of feedback, to experience what it’s like working with other programmers, asking questions etc.

This is not simply about developing your taste, or reading code, but learning about the collaborative nature of programming.

Open Source projects are a fantastic space in which to get this kind of experience for new programmers. But we need to be mindful.

There is a certain style of communication in “tech” that’s needlessly aggressive. When there is a community that, or individual who has adopted this kind of communication style, it can be chilling for those who are just getting started. I’m not sure what causes some people to use their knowledge and experience as a weapon, but the mere presence of someone adopting that kind of style can be crippling.

I’m not suggesting there shouldn’t be standards or that anything should go in terms of code. It’s good and right to worry about quality and correctness. But this style of communication can drive people away who might otherwise make great contributions, who may eventually be great programmers. It can drive them away faster and more successfully than any kind of intrinsic difficulty there is in programming.

And so, my second suggestion about leveraging Open Source has two parts.

First, Open Source may be an important place for beginners to take their first steps collaborating and learning “in the open”, sure. But here I’m not really interested in the in beginners.

The second and more important aspect is for more experienced programmers. Working in Open Source gives us the opportunity to be kind to those taking their first steps, those just learning to be brave. We can listen, we can answer with patience, we can learn how to guide people without hardening ourselves towards them and their feelings. We can learn to put aside our frustrations, and when we can’t, learn how to express them humanely, in ways that don’t belittle and crush.

Furthermore, when we successfully demonstrate this kind of behaviour towards others, we’re acting as a positive example for the next generation of programmers.

What we can change

I mentioned at the beginning that Open Source has won, at least in terms of global adoption and acceptance by businesses. But this is only a partial victory.

Open Source, and free software more generally, has never simply been about business value. It has to a large degree been underwritten by the notion that we can change the world.

What I’m suggesting is that we should remain alert to this revolutionary undercurrent in Open Source, to not forget it.

It seems to me that in Open Source software we have a strange win-win situation - we have the opportunity to deliver business value while at the same time making the world a better place. This is what has always drawn me to work with and in Open Source Software. Installing Linux used to feel like a small act of resistance.

And even now, the code you contribute to a project like Drupal or Laravel doesn’t simply make, say, a form easier to place on a page, but it can help, in some small way, say, a startup in Zimbabwe with no access to capital to build a viable business.

It can help charities and governments save many millions of dollars on software licenses, money that is far better spent elsewhere.

In a very real way, Open Source Software has already changed the world. We should never forget that.

My third suggestion for leveraging Open Source is to use it both as an example of how to change the world and as a vehicle to do just that again and again.


Resources:

May 16 2019
May 16

Drupalcamp Spain 2019 took place last week in the beautiful city of Conil, in the South of Spain. We had not only great weather, food, company… but also great sessions! This year’s schedule also included the Spanish Splash Awards, Business Day and even a side-event for those accompanying attendees, called Family in Drupal, where they did activities such as yoga, surfing, horse-riding, etc.

Drupalcamp Spain was a great gathering of people from not only Spain but many other countries. In fact, they offered two separate tracks, one in Spanish and one in English. As usual, it was difficult to choose which sessions to attend, but I think I got a really good mix and enjoyed them all thoroughly.

It’s also worth mentioning the registration bag that included a (very discreet) T-shirt, a bottle of wine (so my wife would be okay with me leaving her with the kids), a bottle of olive oil, some local tuna (Conil is a fishing town) and some other goodies.

Conil

I especially enjoyed the Friday afternoon English-track, which was “all about decoupled”. We saw an example of a project which started as a Drupal commerce site with some React components, which eventually became an app built in React native, integrating seamlessly with Drupal via GraphQL.

That was the perfect introduction to my talk, which was up next, about “GraphQL and Twig”, where I went through the whole process of installing, configuring and using GraphQL queries in your Twig templates, as a way of soft-decoupling some parts of your site. You can view the slides here: https://slides.com/fjgarlin/graphql-twig-drupalcamp-spain-2019.

Presentation

Fran

I was very glad to see that my session seemed interesting and useful to attendees and I enjoyed getting to answer some questions right after the session and the following day. People were surprised about how easy it is to get up and running and how powerful this combination can be as well. The closing session on Friday afternoon was about Drupal + GatsbyJS, showing how easy it is to connect those two technologies and doing a live demo about it.

Saturday was also loaded with interesting content, and I ended up going to sessions on topics ranging from QA, SEO, UX, Migrations, Continuous Integration, Content architecture… that’s a good mix for a day, isn’t it? The speakers were really engaging and I must say that I learned a lot on that day. I also enjoyed learning how other agencies work, how we all face similar problems and solve them in different (or sometimes similar) ways. It’s always refreshing to listen to other people's experiences. I must say that most of these learnings happened in-between sessions, chatting and walking around Conil, etc.

Attendees(Photo credit: Jorge Carpio)

I want to give a big, big thanks to all the people who made this event possible: organizers (Ruben Tejeiro, 1xInternet, Drupal association Spain), speakers, photographer (Jorge Carpio), volunteers and attendees from all over.

Looking forward to next year’s edition, ¡muchas gracias por todo!

May 06 2019
May 06

Using UI pattern libraries in Storybook allow us to build a collection of front end UI components that can be used to build bigger components, even full web pages. However, frontend/backend integrations can be fraught with difficulties. In this piece, I’ll explain our process to make these challenges easy, even when using GraphQL fragments inside Twig templates.

What Drupal and GraphQL do well

At Amazee Labs, we build decoupled web applications using GraphQL and Drupal. We’ll touch on the reasons that we use this approach in this article, but if you’d like to know more, check out these blogs:

Drupal is known for its complex and unwieldy theming and rendering system. Data to be rendered comes from across the system in the form of templates, overrides, preprocess functions and contributed modules such as Panels and Display Suite. Sometimes trying to track down where data is being generated or altered is like a murder mystery. 

Thankfully, GraphQL Twig simplifies the situation massively. Each template has an associated GraphQL query fragment that requests the necessary data. This “pull” model (as opposed to Drupal’s normal “push” model) means that finding where the data comes from and how it is structured is really easy. We don’t need to worry about preprocessing or alteration of data, and this method lets us keep the concerns separated.

Advantages of UI component libraries

The main advantage of using a UI component library (also known as a pattern library) is that it facilitates the reusability of components. This means that when a component is created it can be used by any developer on the project to build their parts of the front end and in turn can be used to make larger and more complex components.

There are multiple extra advantages to this, the most obvious being the speed of development. Since all components are simply made up of smaller components, building new ones is usually much quicker, since we don’t need to reinvent the wheel.

This also makes maintenance a breeze, since we’re only maintaining one version of any component. If we decide that all buttons on the frontend need to have an icon next to the text, we simply change the button component and this change will apply everywhere that the component is used.

Finally, the reusability of components in a pattern library means that the UI is consistent. Often, web projects face difficulties where there are multiple versions of various components, each with their own implementation. This is especially true of larger projects built by multiple people, or even multiple teams, where no single person knows the entirety of the project’s implementation details. Thanks to the reusability of our components, we only have one implementation per component.

Challenges of using Drupal, GraphQL, and Storybook together

If done poorly, using pattern libraries like Storybook can be difficult and cause problems during the integration phase(s) of development. The main issue is usually that the frontend and backend developers have different approaches and different goals when developing. 

The frontend developer wants to create the best UI they can in the most efficient way possible, using the paradigms and approaches that are standard or preferred. Unfortunately, at times the implementation doesn’t sync well with the data structure that the backend developers receive from Drupal, so the frontend needs to be refactored or the data structure needs to somehow be altered.

How to make it work

I won’t go into detail on our implementation of the Storybook library, but we keep Storybook in the same repo as our Drupal application, outside the root. We then define a base storybook theme and using the Components module (built by my talented colleague John Albin), we define our path to the Storybook Twig templates as a component library in our .info.yml file. This way, the Drupal theme has access to all of our templates.
 

component-libraries:
  storybook:
    paths:
      - ../../../../storybook/twig

We then create our project-specific theme, which extends the base Storybook theme, and start to work on our integration. A generic page.html.twig file might look like this:
 

{#graphql
query {
  ...Header
  ...Footer
}
#}
{% extends '@storybook/page/page.html.twig' %}

{% block header %}
  {% include '@storybook/navigation/header.html.twig' with graphql only %}
{% endblock %}

{% block content %}
  {{ page.content }}
{% endblock %}

{% block footer %}
  {% include '@storybook/footer/footer.html.twig' with graphql only %}
{% endblock %}


So, how does GraphQL tie in here? Well, this is the really clever part. Our developers can create the GraphQL snippets to get the data needed for a specific component, and Storybook allows us to use JavaScript to use this data as mock fixtures. This means that the frontend can be built with realistically structured data, so no refactoring of templates or data alteration on the backend is needed. And since we already have the GraphQL snippet, this automatically works when run in Drupal. 

Conclusion

At Amazee, we use a UI component library because it makes sense to build a maintainable, reusable and consistent set of components for our frontend that also encourages faster development. We also try our best to streamline our integration processes so that all of our developers are more closely aligned and developing solutions that make it easier for their colleagues to use, learn and extend easily. 

Storybook gives us the power to build a component library using mock data that is structured in the exact manner that our GraphQL queries deliver it. This means no refactoring, building both queries and templates only once and an overall smooth integration process. 

Want to know more about using GraphQL and Twig? Check out our webinar
 

May 06 2019
May 06

Using UI pattern libraries in Storybook allow us to build a collection of front end UI components that can be used to build bigger components, even full web pages. However, frontend/backend integrations can be fraught with difficulties. In this piece, I’ll explain our process to make these challenges easy, even when using GraphQL fragments inside Twig templates.

What Drupal and GraphQL do well

At Amazee Labs, we build decoupled web applications using GraphQL and Drupal. We’ll touch on the reasons that we use this approach in this article, but if you’d like to know more, check out these blogs:

Drupal is known for its complex and unwieldy theming and rendering system. Data to be rendered comes from across the system in the form of templates, overrides, preprocess functions and contributed modules such as Panels and Display Suite. Sometimes trying to track down where data is being generated or altered is like a murder mystery. 

Thankfully, GraphQL Twig simplifies the situation massively. Each template has an associated GraphQL query fragment that requests the necessary data. This “pull” model (as opposed to Drupal’s normal “push” model) means that finding where the data comes from and how it is structured is really easy. We don’t need to worry about preprocessing or alteration of data, and this method lets us keep the concerns separated.

Advantages of UI component libraries

The main advantage of using a UI component library (also known as a pattern library) is that it facilitates the reusability of components. This means that when a component is created it can be used by any developer on the project to build their parts of the front end and in turn can be used to make larger and more complex components.

There are multiple extra advantages to this, the most obvious being the speed of development. Since all components are simply made up of smaller components, building new ones is usually much quicker, since we don’t need to reinvent the wheel.

This also makes maintenance a breeze, since we’re only maintaining one version of any component. If we decide that all buttons on the frontend need to have an icon next to the text, we simply change the button component and this change will apply everywhere that the component is used.

Finally, the reusability of components in a pattern library means that the UI is consistent. Often, web projects face difficulties where there are multiple versions of various components, each with their own implementation. This is especially true of larger projects built by multiple people, or even multiple teams, where no single person knows the entirety of the project’s implementation details. Thanks to the reusability of our components, we only have one implementation per component.

Challenges of using Drupal, GraphQL,
and Storybook together

If done poorly, using pattern libraries like Storybook can be difficult and cause problems during the integration phase(s) of development. The main issue is usually that the frontend and backend developers have different approaches and different goals when developing. 

The frontend developer wants to create the best UI they can in the most efficient way possible, using the paradigms and approaches that are standard or preferred. Unfortunately, at times the implementation doesn’t sync well with the data structure that the backend developers receive from Drupal, so the frontend needs to be refactored or the data structure needs to somehow be altered.

How to make it work

I won’t go into detail on our implementation of the Storybook library, but we keep Storybook in the same repo as our Drupal application, outside the root. We then define a base storybook theme and using the Components module (built by my talented colleague John Albin), we define our path to the Storybook Twig templates as a component library in our .info.yml file. This way, the Drupal theme has access to all of our templates.
 

component-libraries:
  storybook:
    paths:
      - ../../../../storybook/twig

We then create our project-specific theme, which extends the base Storybook theme, and start to work on our integration. A generic page.html.twig file might look like this:
 

{#graphql
query {
  ...Header
  ...Footer
}
#}
{% extends '@storybook/page/page.html.twig' %}

{% block header %}
  {% include '@storybook/navigation/header.html.twig' with graphql only %}
{% endblock %}

{% block content %}
  {{ page.content }}
{% endblock %}

{% block footer %}
  {% include '@storybook/footer/footer.html.twig' with graphql only %}
{% endblock %}


So, how does GraphQL tie in here? Well, this is the really clever part. Our developers can create the GraphQL snippets to get the data needed for a specific component, and Storybook allows us to use JavaScript to use this data as mock fixtures. This means that the frontend can be built with realistically structured data, so no refactoring of templates or data alteration on the backend is needed. And since we already have the GraphQL snippet, this automatically works when run in Drupal. 

Conclusion

At Amazee, we use a UI component library because it makes sense to build a maintainable, reusable and consistent set of components for our frontend that also encourages faster development. We also try our best to streamline our integration processes so that all of our developers are more closely aligned and developing solutions that make it easier for their colleagues to use, learn and extend easily. 

Storybook gives us the power to build a component library using mock data that is structured in the exact manner that our GraphQL queries deliver it. This means no refactoring, building both queries and templates only once and an overall smooth integration process. 

Want to know more about using GraphQL and Twig? Check out our webinar

Apr 16 2019
Apr 16

I was so excited about going to DrupalCon Seattle, I started packing one week in advance. Granted, I decided to travel light, so my carry-on suitcase quickly showed the task wouldn’t take long.

Every DrupalCon I have been lucky enough to attend has been special in their own way. This was my first time going back to the States after moving out almost two years ago, so after an airport hiccup (protip: make sure to apply for a new ESTA if you happen to renew your passport after you felt very accomplished getting it ready so much time in advance) I was happy to set my regular-sized foot onto its northwest corner.  

Looking up to Columbia Center, the tallest building in Seattle and the state of Washington.

The week started very nicely, with some time to explore the city and enjoy a selection of its fine food. As there weren’t any sessions on until Wednesday, Tuesday was mostly hanging out with teammates and other friendly faces in the contribution room.

Bathroom doors Anyone else noticed how in the US bathroom stall’s doors never quite make it to the edge?

After a delicious and fun dinner where all Amazees gathered, it was party time. One of the highlights of the week was getting to attend the Museum of Pop Culture at Pantheon’s party, which featured some awesome exhibits. My favourite part was a sound lab where one could learn how to play real instruments (Louie Louie anyone?).

Pantheon Party“Next DrupalCon we need a setlist."

Wednesday and Thursday were packed with brain-revving sessions. Gatsby, data-fetching strategies, and front-end performance were a few of the topics that got a lot of circulation on the printed schedule. But it was diversity and inclusion that rightfully took the main stage at the keynotes. Dries Buytaert began his speech acknowledging that Open Source is not a meritocracy, and Marcy Sutton and Nythia Ruff closed with essential insights on how to use our collective power to build inclusive communities and products.

All in all, there were many moments that made this past week remarkable. Many involved spending time with the team, others meeting new people. Some were expected, like the Women in Drupal luncheon. Others were not, like the Movement BoF that got me walking as if I was auditioning for the Ministry of Silly Walks.

Maria's Session

One remarkable moment was definitely getting to give my (first ever) presentation at a DrupalCon (I can confirm, the Speakers-only room has special catering!). All of these moments made me once more very grateful for being able to be a part of this. I’m looking forward next time I get to play suitcase Tetris and find out what will make the next DrupalCon a one-of-a-kind experience.

Apr 16 2019
Apr 16

I was so excited about going to DrupalCon Seattle, I started packing one week in advance. Granted, I decided to travel light, so my carry-on suitcase quickly showed the task wouldn’t take long.

Every DrupalCon I have been lucky enough to attend has been special in their own way. This was my first time going back to the States after moving out almost two years ago, so after an airport hiccup (protip: make sure to apply for a new ESTA if you happen to renew your passport after you felt very accomplished getting it ready so much time in advance) I was happy to set my regular-sized foot onto its northwest corner.  

Looking up to Columbia Center, the tallest building in Seattle and the state of Washington.

The week started very nicely, with some time to explore the city and enjoy a selection of its fine food. As there weren’t any sessions on until Wednesday, Tuesday was mostly hanging out with teammates and other friendly faces in the contribution room.

Bathroom doors Anyone else noticed how in the US bathroom stall’s doors never quite make it to the edge?

After a delicious and fun dinner where all Amazees gathered, it was party time. One of the highlights of the week was getting to attend the Museum of Pop Culture at Pantheon’s party, which featured some awesome exhibits. My favourite part was a sound lab where one could learn how to play real instruments (Louie Louie anyone?).

Pantheon Party“Next DrupalCon we need a setlist."

Wednesday and Thursday were packed with brain-revving sessions. Gatsby, data-fetching strategies, and front-end performance were a few of the topics that got a lot of circulation on the printed schedule. But it was diversity and inclusion that rightfully took the main stage at the keynotes. Dries Buytaert began his speech acknowledging that Open Source is not a meritocracy, and Marcy Sutton and Nythia Ruff closed with essential insights on how to use our collective power to build inclusive communities and products.

All in all, there were many moments that made this past week remarkable. Many involved spending time with the team, others meeting new people. Some were expected, like the Women in Drupal luncheon. Others were not, like the Movement BoF that got me walking as if I was auditioning for the Ministry of Silly Walks.

Maria's Session

One remarkable moment was definitely getting to give my (first ever) presentation at a DrupalCon (I can confirm, the Speakers-only room has special catering!). All of these moments made me once more very grateful for being able to be a part of this. I’m looking forward next time I get to play suitcase Tetris and find out what will make the next DrupalCon a one-of-a-kind experience.

Apr 12 2019
Apr 12

DrupalCon been a very productive conference so far. The first two days of pre-conference sprinting resulted in fixing the testing pipeline of the webpack module, a prototype for using Drupal as a datasource for Gatsby using GraphQL instead of JSON:API and even solved an unexpected issue for the devel module to provide a way to load dump an entity with all its references embedded inside. You can read more about these solutions here.

After a good Wednesday afternoon, breathing in the calming air of Seattle, Thursday came and it started for me with a breakfast with Victor. He ordered his favourite meal - the Fresh French Croissant and after a short meal, we headed to the venue.

I decided to start the day with the Web components BoF led by Salem Ghoweri. Pega systems use web components a lot and it was interesting to learn about the advantages and pitfalls. IE 11 seems to be the biggest obstacle, especially when it comes to the shadow dom. Polyfilling it is very expensive computationally, so what they did is to actually ditch the shadow dow in browsers that don’t support it natively. In general, looks like web components are getting traction and IE is the main problem, so same as 5 years ago.

The next spot was the GraphQL 101: What, Why, How session by my friend Maria Comas. It started with a brief history of the query language followed by its definition.

Maria Comas

I learned that the reason to build the GraphQL spec at Facebook was because of the need to find a tool that is powerful enough to handle everything Facebook does while staying simple enough so that it’s easy to comprehend by the product developers. The thing Maria likes most about GraphQL is that it is a tool that changes human behaviour.

The session finished on time and there were hardly any questions so we had time to get the best seats for the next Amazee session:  CSS-in-JS and Drupal sitting in a tree... by John Albin Wilkins. On our way there Victor, grave as always decided to make use of his hipster camera and take this photo of me. No comment.

Blazej

John is a natural so his sessions are always entertaining and packed with great content. In this one, he compared 3 different ways of doing CSS-in-js which are:

John Albin

The session summarized the two years of our adventures with the topic while doing both fully and progressively decoupled projects. TLDR; John recommends CSS modules, mostly because it’s the only tool that makes it possible to share the styles between javascript and Drupal. If you’re interested in this topic I would encourage you to check out the recording for the reasoning and lots of interesting details.

After that, I headed to the Considerations of Federated Search and Drupal session by Adam Bergstein. The ability to find content that originates from many different websites is a hard topic which is required by the enterprise clients quite often, so I thought it might be interesting.

Nerdstein started with a high level, generic overview of the system. The structure is similar to what we have in Drupal migrations. He recommended using scrapy. It’s a tool from the python ecosystem which is great because there are many great data manipulation and natural language processing packages. Scrapy also has many destination plugins, e.g. for elastic search, so it’s easy to insert data directly into the search index.

Next, there was lunch and an unexpected booth on the way there - a box with cute, fluffy creatures.

Bunny

I’m not really sure how they ended up there but they definitely made lots of people happy. Here are some photos. Hopefully, they will make you happy as well.

Bunny

Apr 12 2019
Apr 12

DrupalCon been a very productive conference so far. The first two days of pre-conference sprinting resulted in fixing the testing pipeline of the webpack module, a prototype for using Drupal as a datasource for Gatsby using GraphQL instead of JSON:API and even solved an unexpected issue for the devel module to provide a way to load dump an entity with all its references embedded inside. You can read more about these solutions here.

After a good Wednesday afternoon, breathing in the calming air of Seattle, Thursday came and it started for me with a breakfast with Victor. He ordered his favourite meal - the Fresh French Croissant and after a short meal, we headed to the venue.

I decided to start the day with the Web components BoF led by Salem Ghoweri. Pega systems use web components a lot and it was interesting to learn about the advantages and pitfalls. IE 11 seems to be the biggest obstacle, especially when it comes to the shadow dom. Polyfilling it is very expensive computationally, so what they did is to actually ditch the shadow dow in browsers that don’t support it natively. In general, looks like web components are getting traction and IE is the main problem, so same as 5 years ago.

The next spot was the GraphQL 101: What, Why, How session by my friend Maria Comas. It started with a brief history of the query language followed by its definition.

Maria Comas

I learned that the reason to build the GraphQL spec at Facebook was because of the need to find a tool that is powerful enough to handle everything Facebook does while staying simple enough so that it’s easy to comprehend by the product developers. The thing Maria likes most about GraphQL is that it is a tool that changes human behaviour.

The session finished on time and there were hardly any questions so we had time to get the best seats for the next Amazee session:  CSS-in-JS and Drupal sitting in a tree... by John Albin Wilkins. On our way there Victor, grave as always decided to make use of his hipster camera and take this photo of me. No comment.

Blazej

John is a natural so his sessions are always entertaining and packed with great content. In this one, he compared 3 different ways of doing CSS-in-js which are:

John Albin

The session summarized the two years of our adventures with the topic while doing both fully and progressively decoupled projects. TLDR; John recommends CSS modules, mostly because it’s the only tool that makes it possible to share the styles between javascript and Drupal. If you’re interested in this topic I would encourage you to check out the recording for the reasoning and lots of interesting details.

After that, I headed to the Considerations of Federated Search and Drupal session by Adam Bergstein. The ability to find content that originates from many different websites is a hard topic which is required by the enterprise clients quite often, so I thought it might be interesting.

Nerdstein started with a high level, generic overview of the system. The structure is similar to what we have in Drupal migrations. He recommended using scrapy. It’s a tool from the python ecosystem which is great because there are many great data manipulation and natural language processing packages. Scrapy also has many destination plugins, e.g. for elastic search, so it’s easy to insert data directly into the search index.

Next, there was lunch and an unexpected booth on the way there - a box with cute, fluffy creatures.

Bunny

I’m not really sure how they ended up there but they definitely made lots of people happy. Here are some photos. Hopefully, they will make you happy as well.

Bunny

Apr 11 2019
Apr 11

When conversations began a few months back about DrupalCon Seattle, I was so thrilled about the prospect of heading west and being fully indoctrinated with all things Drupal for the first time! As a newcomer to the field, I have been eager to simply be surrounded by, and learn from, so many in this community. Additionally, DrupalCon is providing the perfect opportunity to hang out with some incredible colleagues.

The Day Begins: People

The feel of day three was noticeably more vibrant as the surge of conference attendees began to fill the halls of the Washington State Convention Center. It’s been great to see representation from all over the country and be surrounded by an association with such rich diversity.

I learned quickly that there is no lack of learning opportunities at DrupalCon. The number of sessions to choose from felt like a buffet for your mind -- where you could pick and choose, and tailor your experience to be as uniquely tailored to you as you want.

I chose sessions that I knew would provide helpful reminders to me on practices and processes I already have in place, as well as topics in which I simply want to increase my awareness or hear a different perspective.

IO Booth

Wednesday Learnings

Much of the late morning to the afternoon was spent in periodic spurts of catching up on work, popping into sessions and dropping by our booth. Here are a few of the sessions I went to, with three key learnings from each:

Getting an Angry Wet Cat to Purr: Turning an Unhealthy Client Relationship Into a Productive One (Donna Bungard, Project Strategist at Tandem)

  • Communication: Everything comes down to having an open, honest, direct conversation. This is the key manner in which you build trust with your team.

  • Hearing is good. Understanding is better.

  • There are always the next steps to be taken. You simply need to identify them.

Lead, Follow or Get out of the Way: Managing Global Teams Harmoniously (Yuriy Gerasimov, Organizer at Drupal Ukraine Community and Clyde Boyer)

  • Active Trust is foundational to team success.

  • A common mistake on distributed teams is not recognizing isolation in your team members. Take notice if the communication style of a team member changes (this may point to something not being well in their world).

  • You don’t talk your way to trust. You have to earn it, mostly with time.

Design Strategies: Our Process for Building User-centered Websites (Valerie Neumark Mickela, Board Member at Full Circle Funds and Andrew Goldsworthy, Co-Founder at Rootid)

(I actually sat down in this session by mistake, but by the time I realized, it was too late to leave without causing disruption . . . it wouldn’t be a full conference experience without a mishap along the way, right?!)

  • Design and development communications can be challenging: You absolutely cannot rely on assumptions.

  • In design, you are most often thinking through a psychological lens, versus a creative one.

  • When considering a feature, don’t ask “Is it possible?” (all things are possible with time and money!) Ask “Is it hard?” (this will provide a more realistic barometer for time and cost)

Finding Your Way: Practical Strategies for Navigating Your Career (Gus Childs, Senior Software Engineer at Mondo Robot)

  • Be selfish with your career - you should be doing work that’s fulfilling.

  • You should be excited about these three things when it comes to your career: People, Projects and Money.

  • Never burn bridges.

Seattle

The Day Ends: Splash Awards and Ping Pong Party

The awards ceremony was held at a beautiful location, inside a music venue called The Triple Door, just a couple blocks from the Pike Place Market. After being at the conference for a few days, meeting new friends and getting to know my colleagues better, Splash Awards was a perfect opportunity to catch up and talk about work and life with everyone who attended. While Amazee did not walk away with any awards, it was really fun to celebrate with others, and celebrate the incredible Amazee work that was nominated:

Splash Awards

From the Splash Awards, we walked over to Spin Seattle for one of the evening parties. Spin was packed from wall-to-wall with conference attendees and was a really fun way to end the day.

In closing, I will just say that I have been really encouraged by how warm the Drupal community is, and am so grateful for the opportunity to be at DrupalCon Seattle 2019.

Apr 11 2019
Apr 11

When conversations began a few months back about DrupalCon Seattle, I was so thrilled about the prospect of heading west and being fully indoctrinated with all things Drupal for the first time! As a newcomer to the field, I have been eager to simply be surrounded by, and learn from, so many in this community. Additionally, DrupalCon is providing the perfect opportunity to hang out with some incredible colleagues.

The Day Begins: People

The feel of day three was noticeably more vibrant as the surge of conference attendees began to fill the halls of the Washington State Convention Center. It’s been great to see representation from all over the country and be surrounded by an association with such rich diversity.

I learned quickly that there is no lack of learning opportunities at DrupalCon. The number of sessions to choose from felt like a buffet for your mind -- where you could pick and choose, and tailor your experience to be as uniquely tailored to you as you want.

I chose sessions that I knew would provide helpful reminders to me on practices and processes I already have in place, as well as topics in which I simply want to increase my awareness or hear a different perspective.

IO Booth

Wednesday Learnings

Much of the late morning to the afternoon was spent in periodic spurts of catching up on work, popping into sessions and dropping by our booth. Here are a few of the sessions I went to, with three key learnings from each:

Getting an Angry Wet Cat to Purr: Turning an Unhealthy Client Relationship Into a Productive One (Donna Bungard, Project Strategist at Tandem)

  • Communication: Everything comes down to having an open, honest, direct conversation. This is the key manner in which you build trust with your team.

  • Hearing is good. Understanding is better.

  • There are always the next steps to be taken. You simply need to identify them.

Lead, Follow or Get out of the Way: Managing Global Teams Harmoniously (Yuriy Gerasimov, Organizer at Drupal Ukraine Community and Clyde Boyer)

  • Active Trust is foundational to team success.

  • A common mistake on distributed teams is not recognizing isolation in your team members. Take notice if the communication style of a team member changes (this may point to something not being well in their world).

  • You don’t talk your way to trust. You have to earn it, mostly with time.

Design Strategies: Our Process for Building User-centered Websites (Valerie Neumark Mickela, Board Member at Full Circle Funds and Andrew Goldsworthy, Co-Founder at Rootid)

(I actually sat down in this session by mistake, but by the time I realized, it was too late to leave without causing disruption . . . it wouldn’t be a full conference experience without a mishap along the way, right?!)

  • Design and development communications can be challenging: You absolutely cannot rely on assumptions.

  • In design, you are most often thinking through a psychological lens, versus a creative one.

  • When considering a feature, don’t ask “Is it possible?” (all things are possible with time and money!) Ask “Is it hard?” (this will provide a more realistic barometer for time and cost)

Finding Your Way: Practical Strategies for Navigating Your Career (Gus Childs, Senior Software Engineer at Mondo Robot)

  • Be selfish with your career - you should be doing work that’s fulfilling.

  • You should be excited about these three things when it comes to your career: People, Projects and Money.

  • Never burn bridges.

Seattle

The Day Ends: Splash Awards and Ping Pong Party

The awards ceremony was held at a beautiful location, inside a music venue called The Triple Door, just a couple blocks from the Pike Place Market. After being at the conference for a few days, meeting new friends and getting to know my colleagues better, Splash Awards was a perfect opportunity to catch up and talk about work and life with everyone who attended. While Amazee did not walk away with any awards, it was really fun to celebrate with others, and celebrate the incredible Amazee work that was nominated:

Splash Awards

From the Splash Awards, we walked over to Spin Seattle for one of the evening parties. Spin was packed from wall-to-wall with conference attendees and was a really fun way to end the day.

In closing, I will just say that I have been really encouraged by how warm the Drupal community is, and am so grateful for the opportunity to be at DrupalCon Seattle 2019.

Apr 10 2019
Apr 10

Normally I would invest my time in writing about attending sessions and/or how talks went from our speakers or BoFs and other social events. But since I spent the better half of Monday on a plane somewhere over the Atlantic, I will be taking this opportunity to compare this weeks experience to the one I had from four years ago. 

Besides the summits and the different ways you can buy the ticket nowadays, not much has really changed. DrupalCon remains the biggest Drupal event in the world, and you will meet an overabundance of incredibly friendly people there.

Part 1: The journey to Seattle

Like all DrupalCons for me, this one also began with an elongated trip through several airports, first a 1h 5min hop from Zurich to Amsterdam, followed by a roughly ten-hour flight to touch down at Seattle Tacoma International Airport.

Zurich to Seattle

Italy vs. France

The flights went smooth and apart from the occasional shakedown, I didn’t notice much uneasiness. That is until I was served lunch. There were several intriguing options, I had to make a comprehensive decision between Caesar salad, a vegetarian mozzarella pizza or a turkey and cheese croissant. Naturally given my never-ending love for Italian cuisine I opted for the pizza but it seemed that by the time the food cart reached my row, they were out.

"Fresh Croissant"

Instead, I received a box that read “Fresh Croissant“ in big, classy letters printed on a reasonably attractive shell showcasing a map of Paris. Trading Italy for France couldn't be that bad, surely. But upon opening my small box of doom I was treated to what must have been the remains of a gutter rat, shipped directly from the catacombs of Paris onto my food tray. It‘s hard to describe the shape, consistency, and scent of the box innards without using chemical compositions or comparison to what floats around in a sewer. The temperature also seemed to vary quite a bit from top to bottom, further confirming my theory of it being alive at one point.

Whatever this was, it wasn't a “Parmesan Cheese, Mature Cheddar Cheese & Turkey” croissant.

Order at the border

Once landed I was keen to leave the rat behind and make my way through the checkpoints. I last visited the US in 2015 and have an ESTA, so I was sure I would be able to get through quickly and effortlessly. 

There were only 2 lines, US/Canadian citizens and ESTA/VISA holders, the latter was full of the majority of the passengers from my flight. Because of my seating arrangements, I exited the air tube quite late. The wait was long enough that every so often a disgruntled passenger reached terminal annoyance and broke down before attempting to bargain with the officer who was making his rounds or one of the airport staff members. Results of these interactions varied between total denial and instant gratification. I didn't bother trying to negotiate, I wasn't in a particular hurry, but after thirty minutes of barely any movement, my knees were getting unhappy.

At some point, one of the staffers approached me and asked if I had visited the US since 2008. When I answered positively he immediately pointed me towards line 1. Now, I’m no UX expert but perhaps that information could have been included on the signs. When others within my vicinity heard about my redirection, they promptly followed suit. Soon I was racing most of line two as they migrated like a flock of seagulls to line 1. We waited again.

But that wasn't the end of it. After I checked through the automated migration ATM I had to stand in line again for the final stamp of approval. There were 6 border control officers working that day. Some faster than others and some nicer than others, one, in particular, was having a rough start to the week. To say the least, officer McNasty wasn't exactly welcoming, in contrary, in German there is a word for people like that, we call them “Arschloch”.

He must have smelled the gutter rat on me because he wasn't exactly thrilled when I approached. Our interaction went something like this:

Officer McNasty: “You here for business or pleasure?”
Me: “Both.”
Officer McNasty: “There is no both, there is either business or pleasure. Are you here for business or pleasure?”
Me: “One week business, one week holiday.”

He responded with a frown that would have put my math teacher to shame, but a few minor questions later I finally received the approving stamp as he silently pointed me towards the escalator down to the baggage claim. I was free. Sort of.

Baggage Claim

The first one to spot both me and my suitcase gets a drink at DC Seattle. 

At last, I made it to Seattle, riding into the city I was treated with tall, striking buildings and a glimpse of the Harbour.

Hello Seattle!

Part 2: The venue and playing “Guess who?”

The fortress of not so solitude

This year, DrupalCon is being held at the Washington State Convention Center. Built in 1988, this large 415’000 sqft complex is humongous compared to the European counterparts. It’s also located in what I would call “Downtown” Seattle. Take that with a grain of salt though as I base this on the six hours I’ve been in the city.

The building also sits on top of a freeway, which you can spot and overlook while you’re inside of it, neat!

Seattle

When I first arrived, it took me some time to find the entrance. The building, depending on where you approach it from, is rather defensive and resembles a fortress more than a convention centre (think of the freeway as the moat). Even after finding the entrance, if you come in from the west you’ll have to use 4-6 escalators before you see any rooms. 

After collecting my badge from the friendly volunteers I made my way through the halls and started to look for familiar faces. DrupalCons are always tricky, you end up meeting a lot of people who seem to know you (or not) and I often have trouble remembering if I’ve met them. 

During times like these, I’d like to play the good old “Guess who?” game. The goal is to keep the conversation going until you can figure out who you’re talking to before your cover gets blown. 

Game

Admittedly I've never successfully finished a session, but the strategy I’d recommend is starting the conversation with “Oh wow, it's been quite a while hasn’t it? What have you been up to since we last met?”. Hopefully make your opponent reveal some crucial information about their job, location, and where you met previously. If you're lucky one of these things will tip you off and trigger a spark to put that name on that face.

If you find yourself on the receiving end of my blank stare, I apologize. it's not you, it's me.

The booth, the booth, the booth is unattended

This is one of the first years Amazee Labs doesn't have a physical booth, but our sister company amazee.io does. I was giddy with my freedom to wander and check out the exhibition hall and while it was still under construction. 

If you’re around the exhibit hall you can find some Amazees, of both the io and Labs variety hanging out at the io booth. Come and say hello!

Giving back

While the booth was being constructed several of our peeps dug themselves into the contribution hall on the 6th floor.

John Albin Wilkins

Blazej

Maria

You can easily spot John from about 600 miles away as he overlooks the kingdom of room 6A with his standing desk contraption. It’s a great conversation starter really, for the time I sat there I witnessed several hundred people approaching him and asking about every little detail of his mobile turret unit. 

So if the makers of this product are reading this post I think they should consider making John the official global ambassador of this mobile standup desk unit solution that fits into a backpack and gets a pass from the TSA.

Part 3: Extracurricular activities and the endless consumption of beverages

Monday evening presented itself with several social offerings, amongst which was a pub crawl that was attended by a few of the fellowship.

Walking to dinner

– Image courtesy of Josef Dabernig (@dasjo)

Since I began to fall asleep while walking (I was still running on Zurich time so technically it was around 3 am) I decided to skip the crawl as that would have ended up in a different kind of pizza.

But before that, I realized that for the first time ever, I forgot to pack a toothbrush and some paste. So after taking a nap for about an hour, I was forced to venture out again, this time to find the holy brush.

City

It’s a restaurant

Tuesday evening also saw the Amazee dinner, were we collectively gathered and feasted on quality beverages in a place called “Outlier”. The food was indeed fantastic, some people even dropped phrases such as “this is the best _________ I ever had in a restaurant”. 

Everyone seemed equally amazed about the quality of the provided liquid but not the selection. Which is why several of us left afterwards in search of alternatives to quench one's thirst.

In the end, it was a great, cosy dinner, filled with friends and family alike.

Team Dinner

Part 4: Conclusion and final thoughts

Should you go or should you stay?

So, then you wonder, what's this all about, what is the meaning of this stretched out the first impression? To be honest, I’m not sure. You probably noticed that I didn't compare it all that much to L.A., the reason for it is very simple, there is not much comparing needed.

While the venue and sessions may change, and the outside activities like the pub crawls are fun and inviting, there’s not really a wrong way to do DrupalCon. You can find your own way, roam around freely in town and every now and then you might run into some Drupal people that couldn’t be more different but somehow share the same passion.

Apr 10 2019
Apr 10

Normally I would invest my time in writing about attending sessions and/or how talks went from our speakers or BoFs and other social events. But since I spent the better half of Monday on a plane somewhere over the Atlantic, I will be taking this opportunity to compare this weeks experience to the one I had from four years ago. 

Besides the summits and the different ways you can buy the ticket nowadays, not much has really changed. DrupalCon remains the biggest Drupal event in the world, and you will meet an overabundance of incredibly friendly people there.

Part 1:
The journey to Seattle

Like all DrupalCons for me, this one also began with an elongated trip through several airports, first a 1h 5min hop from Zurich to Amsterdam, followed by a roughly ten-hour flight to touch down at Seattle Tacoma International Airport.

Zurich to Seattle

Italy vs. France

The flights went smooth and apart from the occasional shakedown, I didn’t notice much uneasiness. That is until I was served lunch. There were several intriguing options, I had to make a comprehensive decision between Caesar salad, a vegetarian mozzarella pizza or a turkey and cheese croissant. Naturally given my never-ending love for Italian cuisine I opted for the pizza but it seemed that by the time the food cart reached my row, they were out.

"Fresh Croissant"

Instead, I received a box that read “Fresh Croissant“ in big, classy letters printed on a reasonably attractive shell showcasing a map of Paris. Trading Italy for France couldn't be that bad, surely. But upon opening my small box of doom I was treated to what must have been the remains of a gutter rat, shipped directly from the catacombs of Paris onto my food tray. It‘s hard to describe the shape, consistency, and scent of the box innards without using chemical compositions or comparison to what floats around in a sewer. The temperature also seemed to vary quite a bit from top to bottom, further confirming my theory of it being alive at one point.

Whatever this was, it wasn't a “Parmesan Cheese, Mature Cheddar Cheese & Turkey” croissant.

Order at the border

Once landed I was keen to leave the rat behind and make my way through the checkpoints. I last visited the US in 2015 and have an ESTA, so I was sure I would be able to get through quickly and effortlessly. 

There were only 2 lines, US/Canadian citizens and ESTA/VISA holders, the latter was full of the majority of the passengers from my flight. Because of my seating arrangements, I exited the air tube quite late. The wait was long enough that every so often a disgruntled passenger reached terminal annoyance and broke down before attempting to bargain with the officer who was making his rounds or one of the airport staff members. Results of these interactions varied between total denial and instant gratification. I didn't bother trying to negotiate, I wasn't in a particular hurry, but after thirty minutes of barely any movement, my knees were getting unhappy.

At some point, one of the staffers approached me and asked if I had visited the US since 2008. When I answered positively he immediately pointed me towards line 1. Now, I’m no UX expert but perhaps that information could have been included on the signs. When others within my vicinity heard about my redirection, they promptly followed suit. Soon I was racing most of line two as they migrated like a flock of seagulls to line 1. We waited again.

But that wasn't the end of it. After I checked through the automated migration ATM I had to stand in line again for the final stamp of approval. There were 6 border control officers working that day. Some faster than others and some nicer than others, one, in particular, was having a rough start to the week.

He must have smelled me because he wasn't exactly thrilled when I approached. Our interaction went something like this:

Officer McNasty: “You here for business or pleasure?”
Me: “Both.”
Officer McNasty: “There is no both, there is either business or pleasure. Are you here for business or pleasure?”
Me: “One week business, one week holiday.”

He responded with a frown that would have put my math teacher to shame, but a few minor questions later I finally received the approving stamp as he silently pointed me towards the escalator down to the baggage claim. I was free. Sort of.

Baggage Claim

The first one to spot both me and my suitcase gets a drink at DC Seattle. 

At last, I made it to Seattle, riding into the city I was treated with tall, striking buildings and a glimpse of the Harbour.

Hello Seattle!

Part 2: The venue and
playing “Guess who?”

The fortress of not so solitude

This year, DrupalCon is being held at the Washington State Convention Center. Built in 1988, this large 415’000 sqft complex is humongous compared to the European counterparts. It’s also located in what I would call “Downtown” Seattle. Take that with a grain of salt though as I base this on the six hours I’ve been in the city.

The building also sits on top of a freeway, which you can spot and overlook while you’re inside of it, neat!

Seattle

When I first arrived, it took me some time to find the entrance. The building, depending on where you approach it from, is rather defensive and resembles a fortress more than a convention centre (think of the freeway as the moat). Even after finding the entrance, if you come in from the west you’ll have to use 4-6 escalators before you see any rooms. 

After collecting my badge from the friendly volunteers I made my way through the halls and started to look for familiar faces. DrupalCons are always tricky, you end up meeting a lot of people who seem to know you (or not) and I often have trouble remembering if I’ve met them. 

During times like these, I’d like to play the good old “Guess who?” game. The goal is to keep the conversation going until you can figure out who you’re talking to before your cover gets blown. 

Game

Admittedly I've never successfully finished a session, but the strategy I’d recommend is starting the conversation with “Oh wow, it's been quite a while hasn’t it? What have you been up to since we last met?”. Hopefully make your opponent reveal some crucial information about their job, location, and where you met previously. If you're lucky one of these things will tip you off and trigger a spark to put that name on that face.

If you find yourself on the receiving end of my blank stare, I apologize. it's not you, it's me.

The booth, the booth, the booth is unattended

This is one of the first years Amazee Labs doesn't have a physical booth, but our sister company amazee.io does. I was giddy with my freedom to wander and check out the exhibition hall and while it was still under construction. 

If you’re around the exhibit hall you can find some Amazees, of both the io and Labs variety hanging out at the io booth. Come and say hello!

Giving back

While the booth was being constructed several of our peeps dug themselves into the contribution hall on the 6th floor.

John Albin Wilkins

Blazej

Maria

You can easily spot John from about 600 miles away as he overlooks the kingdom of room 6A with his standing desk contraption. It’s a great conversation starter really, for the time I sat there I witnessed several hundred people approaching him and asking about every little detail of his mobile turret unit. 

So if the makers of this product are reading this post I think they should consider making John the official global ambassador of this mobile standup desk unit solution that fits into a backpack and gets a pass from the TSA.

Part 3: Extracurricular activities and the endless consumption of beverages

Monday evening presented itself with several social offerings, amongst which was a pub crawl that was attended by a few of the fellowship.

Walking to dinner

– Image courtesy of Josef Dabernig (@dasjo)

Since I began to fall asleep while walking (I was still running on Zurich time so technically it was around 3 am) I decided to skip the crawl as that would have ended up in a different kind of pizza.

But before that, I realized that for the first time ever, I forgot to pack a toothbrush and some paste. So after taking a nap for about an hour, I was forced to venture out again, this time to find the holy brush.

City

It’s a restaurant

Tuesday evening also saw the Amazee dinner, were we collectively gathered and feasted on quality beverages in a place called “Outlier”. The food was indeed fantastic, some people even dropped phrases such as “this is the best _________ I ever had in a restaurant”. 

Everyone seemed equally amazed about the quality of the provided liquid but not the selection. Which is why several of us left afterwards in search of alternatives to quench one's thirst.

In the end, it was a great, cosy dinner, filled with friends and family alike.

Team Dinner

Part 4: Conclusion and final thoughts

Should you go or should you stay?

So, then you wonder, what's this all about, what is the meaning of this stretched out the first impression? To be honest, I’m not sure. You probably noticed that I didn't compare it all that much to L.A., the reason for it is very simple, there is not much comparing needed.

While the venue and sessions may change, and the outside activities like the pub crawls are fun and inviting, there’s not really a wrong way to do DrupalCon. You can find your own way, roam around freely in town and every now and then you might run into some Drupal people that couldn’t be more different but somehow share the same passion.

Apr 02 2019
Apr 02

Amazee Labs webinars allow us to share our knowledge and experience with the community. Last week we discussed the challenges in choosing the right CSS-in-JS solution and the advantages of using CSS modules.

After a couple of years of building decoupled sites, the Amazee Labs team has tried several different CSS-in-JS solutions and found this one to be best suited to the needs of our development team.

CSS Modules is a mature project with a syntax that is a superset of CSS, similar to Sass. It makes it easy for you to “think in components” without having to worry about BEM class naming. It automatically generates locally-scoped CSS class names, so you can use “.wrapper” in multiple files without conflict.

It also allows integration of “global” class names from other code (like JS libraries or 3rd party CSS). With CSS Modules you get automatic dead-code elimination as only the CSS used on the page is ever sent to the browsers. Best of all CSS Modules can be used with any JavaScript framework, including React, Angular and Vue.js.

Watch the webinar recording online to learn about:

  • Components without BEM

  • Locally-scoped class names

  • Dead-code elimination

  • Multi-platform support

  • Nested rulesets

  • Cross-component composition

  • Sharing variables between your JavaScript and your CSS


Catch up on our previous webinars here:

Sharing knowledge and learnings is a key value at Amazee Labs. Keep an eye out for future webinars here!

Mar 27 2019
Mar 27

We’re excited to attend and present at DrupalCon Seattle this year. Here’s a breakdown of what we’re looking forward to day by day, and information about where you can see Amazee sessions throughout the week.

Monday, 8 April

Monday and Tuesday will be a time for summits, sprints, and BoFs. Be sure to check out Michael Schmid as part of the Performance and Scaling Summit. In the evening you can join the DrupalCon Monday Night Pub-Crawl for community and drinks.

Tuesday, 9 April

In addition to the many summits and sprints be sure to check out the First-time Attendee Networking Breakfast if you're new to DrupalCon. After hours you can join a group run or one of several parties.

Wednesday, 10 April

In the morning, don’t miss the annual DriesNote where you can hear about the current state of Drupal as well as what the future holds. In the evening, the prestigious Splash Awards will showcase the best of Drupal from 2018 in the inaugural global international edition of these awards.

Thursday, 11 April

Thursday will be a day full of Amazee sessions. First up, Maria Comas will host her session GraphQL 101: What, Why, How from 09:45 - 10:15 in Room: 606. Be sure to check it out to get a basic overview of GraphQL and how to get started using it.

Catch John Albin Wilkins and his session CSS-in-JS and Drupal sitting in a tree… from 10:45 - 11:15 in Room: 6B. John will discuss the learnings from Amazee Labs trying several different CSS-in-JS solutions and why we finally decided on using CSS Modules.

In the afternoon, Michael Schmid will present Best Practices: How We Run Decoupled Websites with 110 Million Hits per Month at 13:00 in Room: 6C.

Finally, you can finish out Thursday with the popular social event Trivia Night where you can test out your Drupal knowledge with a chance to win prizes or earn the title of Drupal trivia champions, and win small prizes to boot!

Friday, 12 April

On the final day of DrupalCon, the community comes together to make contributions before saying goodbye until next year. We can’t wait to see all of you at DrupalCon 2019!

Mar 14 2019
Mar 14

Day one

The weather was snowy and cold and caused some transportation delays. Though I arrived later than planned, I was able to attend afternoon workshops and work on some Drupal Contribution projects. The day finished with an Apéro, where everyone gathered for good drinks and great conversations. To finish the night, the Amazee team left to have dinner together.

Apéro

Day two

The 2nd day of Drupal Mountain Camp began with a discussion by a panel made up of Nick Veenhof, Imre Gmelig Meijling, Yauhen Zenko and Vincent Maucorps, to discuss the future of Drupal communities. The panel was moderated by Rachel Lawson. They took questions from the audience members, which included:

  • How can we attract young talent?
    By targeting students, as they have the most time. Having a DrupalCamp in a university shows them what the community has and can to offer. This can also be achieved by getting Universities to add Drupal to the course curriculum. Another way is offering a training initiative or talking to agencies.
  • What can we do about International collaborations?
    Related to the previous question, maybe offer a base camp or training day. This allows those who wouldn’t be able to attend a larger event to learn. Live streaming is a good option for those not able to attend in person.
  • What are the benefits of sponsoring events, such as Drupal Mountain Camp?
    Sponsoring is a great way to find talent and increase brand recognition, particularly to companies that are new.

GraphQL 101: What, Why, How

This session was presented by fellow colleague Maria Comas, as a beginner’s guide to GraphQL. Throughout the presentation, it became clear why GraphQL is so powerful. I really liked the abbreviation WYGISWAF (What You Get Is What You Asked For), because that is essentially what GraphQL does. It will return only the data that you need. Maria showed us how this is achieved through demo code, before letting people know that this is already available in Drupal through the GraphQL module. As it was International Women’s Day, it was fitting that Maria ended the session with the following quote by computer scientist, Grace Hopper.

The most damaging phrase in the language is "We’ve always done it this way!"
- Grace Hopper
 

Maria Comas

Mob Programming: An interactive session

Next was Daniel Lemon, whose session was all about mob programming. Having already introduced a scrum team to mob programming, Daniel wanted to share the experience. This presentation gave a broad overview of mob programming. What impressed me most about this session was that Daniel didn't just want to explain to the audience what mob programming is, but got members of the audience to participate in a live mob session. This meant that those involved and those watching could see how mob programming works.

Participants were tasked with creating a gallery page and menu to the Drupal Mountain Camp site, within 15 minutes, taking turns of 2 minutes each, being the driver or navigator. After introducing the task, the 5 participants were able to create a basic implementation of the gallery page. The session ended with a quick retrospective, in which participants were truly motivated to try this within their own company. Many felt it was a nice switch from the ordinary single-developer experience, but some observed it could be difficult to keep up especially in the role of the driver.

On stage

Splash awards, fondue, sledding, and drinks!

The Splash Awards is about awarding the best Drupal projects of the year. Amazee Labs won an award for Zuerich.com in the category of Design/UX.

During the awards, Jeffrey McGuire treated us to sounds from the Alphorn, which I, personally, had never heard before. The sound produced was truly beautiful. After the awards, everyone made their way to the funicular station to collect their sleds and made their way up to the Belle Epoque restaurant. I was unable to go sledding as I didn’t have the right footwear, so I went to eat fondue with fellow colleagues Victor, Bastian, and Michael. There really is nothing better than ending the day with fondue.

Splash Awards

Day three

Day three started with a keynote, presented by Matthew Grill about the Drupal Admin UI & JavaScript Modernisation initiative, in which he informed us about the current progress of the administration. After the initial showing at DrupalEurope, it was clear that existing modules wouldn’t be compatible. This led to the team creating extension points, which would allow current modules to bundle and transpile the JavaScript to be used with the AdminUI, without having an extra build step.

It was clear that this was still a work in progress but nonetheless, it was nice to hear the latest update about the initiative. After the session, everyone was invited to the group photo. Say “Drupal”!

Group Photo

Current state of the Drupal Admin UI Redesign

The next session was again about the Drupal Admin UI, however, this time about the design. This was given by Sascha Eggenberger and Cristina Chumillas, they both explained and showcased the new design system, wireframes, and the current state of designs the initiative is proposing. It was clear that the design process was long and opinionated after they explained that designing a button wasn’t as straightforward as expected, due to many states and types. The team are hoping for a release in Drupal 8.7. but it was clear, after someone asked, that it seems to be a slow process, that this might not happen in time. It was noted that they also need help from contributors.

If you want to help or just know more about the above, head to the Admin UI & JavaScript Modernisation initiative.

Optimise your JavaScript

Saša Nikolić gave his session on optimising JavaScript. After a short history of the internet, in which I learned that Drupal came before Facebook. Saša also covered data loading. Loading lots of data, with lots of data manipulation is not a good idea for the user as this will slow down page loads.

The session also explained how to address various scenarios and the general rules that every JavaScript developer should be familiar with in order to boost your site’s performance. This includes using tools like Google Chrome dev tools, and Lighthouse. Tree shaking was another suggestion, by including only the functions that are needed. I also came to learn about prepack, a JavaScript bundle optimiser. Another useful piece of advice was to utilise CSS. Why use JavaScript for animations when CSS can take care of this? If unsupported browsers are the reason, leave it out, and make it look graceful as possible. I also enjoyed the joke about “eval() = bad”.

Network was the bottleneck, now it’s JavaScript.
- Saša Nikolić

Open source contribution

This was my favourite session of the day in which I learned about the opinions of Christina Chumillas, Miro Dietiker, Kevin Wenger, Michael Schmid, and Lukas Smith about everything to do with open source. This was an open forum, moderated by Josef Dabernig, in which an audience member was encouraged to ask a question they had about open source.

  • What motivates you to contribute to open source?
    It is concrete, you can see what you have done. People will code review, this will not only help make it better but will make oneself better. On a side note, people should just work together, join forces, this is the mindset of Drupal.
  • What is the advantage of open source software over proprietary software?
    Not only does it help with the maintenance of the code, but having different backgrounds, helps with the innovation of the code. Proprietary software means being on your own, which sometimes is not productive.
  • What is a good way to avoid maintainer burnout?
    Having a coach is a good way to let them, and other people, know of any problems and get help from them. Avoid those that don't have your best interest at heart. Share the knowledge, don't let one person do everything, and don’t let yourself be only one to complete someone just for the credit.

It was really nice to hear those answers and I couldn’t agree more. As someone who loves to contribute to open source, I think the biggest benefit is that your code will only become stronger if you share your code with others. After all, two heads are better than one.

Closing

Lukas Smith gave a very thought-provoking and inspiring closing session titled "Diversity & Inclusion: Why and How?". Lukas shared personal insights into becoming active in improving diversity and inclusiveness. He challenged the audience with some shocking statistics on the low amount of female to male programmers across Switzerland and the United States and then revealed that in open-source this percentage is even lower.

What can we do to better ourselves and improve Diversity? He also finished off the session with several tips to improve Diversity, some of which I find important to highlight:

  • Challenge your cognitive biases.
  • Consider following specifically people from marginalized communities in your chosen field.
  • Believe when members of marginalized communities point out issues with bias even if you have never encountered them.
  • Work on using inclusive language.

While talking about inclusion, I, along with everyone who attended, was happy to see that there were three sign language interpreters at the event. This meant that those who are deaf or with hearing difficulties were not excluded from the camp. This was another reason why this camp was exceptional.

If someone points out an offensive statement, make an effort to not become defensive. Listen, learn, move on.
- Lukas Kahwe Smith

After the closing everyone was invited for the ice hockey match between HC Davos and Rapperswil. This was my first time watching an ice hockey game, so it was wonderful to attend. It was a great match, with both a great atmosphere and great people. With that ended the great weekend that was Drupal Mountain Camp. I can honestly say that I had such a great time, especially spending time with my team and the Drupal community.

Finally, you hear it all the time, “thank you to all the sponsors”, but honestly, it cannot be expressed enough. Without them, great camps like Drupal Mountain Camp wouldn’t be possible.

The Game

Mar 11 2019
Mar 11

It’s hard to imagine life without mobile devices. While a developer controls the display of the site and its structure, editors are the ones adding content to a site on a regular basis. One tool that developers can use with editors in mind is Responsive Preview.

Difficulties during content creation can range from complex interfaces to performance problems. Each of these problems can be multiplied when you add in responsive design.  

Responsive Preview is a module that provides you with a quick way to preview how the website's pages will appear with various screen dimensions.

Benefits

Response Preview helps editors when they need to try out new layouts or add new content to preview the page. This means they can make sure everything works on the most commonly used devices before publishing on the live site. The module provides a quick approximation of how the page and the layout will look on any device.

How it works

From the development perspective, the module creates an iFrame with provided configs. This means it doesn't have to go through the trouble of getting all the frontend code and all the styles compiled and rendered in the backend to show a preview. Instead, we just load the iFrame which displays the frontend view.

The module provides a config entity “Preset” with the fields that describe “device” including  “width”, “height”, “rotation”, and more. On a node view page, there is a select with our options. Selecting an option opens an overlay with a preview of the current page.

iframe

.css({

width: width,

          height: height

     });

This way we get a preview of everything we need. Simply create a controller and put a link to the source attribute of the iFrame.

Responsive Preview Module Screenshot

Conclusion

When creating a site, developers should think not only about end users but about editors who will need to work on the site daily. Drupal is a great solution for content management, but sometimes it lacks ease of use.

It’s not enough to only have a mobile, tablet, and desktop design anymore, as many devices fall in between those dimensions. Phones can be the same size as small tablets and the new iPad Pros have a larger screen than some laptops. Responsive Preview provides the flexibility to configure the module as an admin. This makes it easy to add new presets when new devices are released.

Got a project that needs editor-friendly responsive design? Get in touch with us today!

Feb 26 2019
Feb 26

With the announcement of Drupal 9 we want to talk about how this affects our customers, what to expect when new versions come out and to let you know what we do at Amazee Labs to ensure the transition will be painless.

“The big deal about Drupal 9 is … that it should not be a big deal.”

- Dries Buytaert, Drupal Founder
 

Background

The changes to Drupal between versions 7 and 8 were, quite frankly, enormous. Drupal previously had a justified reputation for doing its own thing and ignoring burgeoning standards and practices utilised elsewhere in the PHP community. So, when Drupal 8 was announced, one of the main goals of the release was to get off the Drupal island and start to utilise some of the millions of lines of open source code and documentation available elsewhere.

There were many great sides to this upgrade. The code was being built on a more solid and tested foundation, principally being based on the Symfony framework and leveraging numerous other systems and libraries. This helped Drupal become more enterprise focussed whilst opening the development field to engineers of other systems who were already familiar with the standards and practices now utilised in Drupal.

Unfortunately, the major technical upgrade to Drupal also introduced some headaches. Migrating between Drupal 7 and Drupal 8 can be time consuming and expensive. As a result of this, businesses who undertook such a migration can be forgiven for worrying about Drupal 9 being released just 5 years after Drupal 8. Some clients have expressed concern about using Drupal 8 when another expensive upgrade seems to be just around the corner.

Why Drupal 9 is different

In short, if you keep your Drupal 8 website up-to-date, there will be no major upgrade worries. The core maintainers of Drupal want to make Drupal upgrades easy forever from now on. The Drupal team has a plan to ensure that Drupal 9 will essentially be a minor process. This is possible because Drupal 9 will be built in the same manner as Drupal 8, with the same practices and core libraries. Unlike Drupal 7 to Drupal 8, there will be no major architectural or structural changes to the codebase. 

The main changes, other than bug fixes, improvements and new features will be the upgrades to Drupal’s core libraries. For example, Symfony 3 (the library upon which Drupal is built) comes to its end-of-life in 2021, so it makes sense to have Drupal 9 running on Symfony 4 at that point.

End of support flow chart

How is this easy upgrade achievable? Well, the Drupal team will continue its 6-month release cycle until Drupal 9 is released. In these releases, the code will be deprecated and upgraded to bring it closer to the components and libraries that will be used by Drupal 9, ensuring that when the time does come to upgrade everything will be in place for an easy transition.

Maintenance is key 

Keeping up with new releases and updates ensures that your website stays relevant and secure, and also means that switching from Drupal 8 to 9 will be much more routine. By partnering with us even after your website is created, we can take proactive steps such as making sure there’s no deprecated code in your site before the newest release.

Feb 15 2019
Feb 15

The recent post on Dries’ blog about REST, JSON:API and GraphQL caused a bigger shockwave in the community than we anticipated. A lot of community members asked for our opinion, so we decided to join the conversation.

Apples and Oranges

Comparing GraphQL and JSON:API is very similar to the never-ending stream of blog posts that compare Drupal and Wordpress. They simply don’t aim to do the same thing.

While REST and JSON:API are built around the HTTP architecture, GraphQL is not concerned with its transportation layer. Sending a GraphQL query over HTTP is one way to use it, and unfortunately, one that got stuck in everybody’s minds, but by far not the only one. This is what we are trying to prove with the GraphQL Twig module. It allows you to separate your Twig templates from Drupal’s internal structures and therefore make them easier to maintain and reuse. No HTTP requests involved. If this sparks your interest, watch our two webinars and the Drupal Europe talk on that topic.

So GraphQL is a way to provide typed, implementation agnostic contracts between systems, and therefore achieve decoupling. REST and JSON:API are about decoupling too, are they not?

What does “decoupling” mean?

The term “decoupling” has been re-purposed for content management systems that don’t necessarily generate the user-facing output themselves (in a “coupled” way) but allow to get the stored information using an API exposed over HTTP.

So when building a website using Drupal with its REST, JSON:API or GraphQL 3.x extension and smash a React frontend on top, you would achieve decoupling in terms of technologies. You swap Drupal’s rendering layer with React. This might bring performance improvements - our friends at Lullabot showed that decoupling is not the only way to achieve that - and allows you to implement more interactive and engaging user interfaces. But it also comes at a cost.

What you don’t achieve, is decoupling, or loose-coupling in the sense of software architecture. Information in Drupal might be accessible to arbitrary clients, but they still have to maintain a deep knowledge about Drupal data structures and conventions (entities, bundles, fields, relations…). You might be able to attach multiple frontends, but you will never be able to replace the Drupal backend. So you reached the identical state of coupling as Drupal had for years by being able to run different themes at the same time.

The real purpose of GraphQL

Back when we finished the automatically generated GraphQL schema for Drupal and this huge relation graph would just pop up after you installed the module, we were very proud of ourselves. After all, anybody was able to query for any kind of entity, field, block, menu item or relation between them, and all that with autocompletion!

The harsh reality is that 99.5% of the world doesn’t care what entities, fields or blocks are. Or even worse, they have a completely different understanding of it. A content management system is just one puzzle piece in our client's business case - technology should not be the focus, it’s just there to help achieve the goal.

The real strength of GraphQL is that it allows us to adapt Drupal to the world around it, instead of having to teach everybody how it thinks of it.

Some of you already noticed that there is a 4.x branch of the GraphQL module lingering, and there have been a lot of questions what this is about. This new version has been developed in parallel over the last year (mainly sponsored by our friendly neighbourhood car manufacturer Daimler) with an emphasis on GraphQL schema definitions.

Instead of just exposing everything Drupal has to offer, it allows us to craft a tailored schema that becomes the single source of truth for all information, operations, and interactions that happen within the system. This contract is not imposed by Drupal, but by the business needs that have to be met.

A bright future

So, GraphQL is not a recommendation for Drupal Core. What does that mean? Not a lot, since there is not even an issue on drupal.org to pursue that. GraphQL is an advanced tool that requires a certain amount of professionalism (and budget) to reap its benefits. Drupal aims to be used by everyone, and Drupal Core should not burden itself with complexity, that is not to the benefit of everyone. That's what contrib space is there for.

The GraphQL module is not going anywhere. Usage statistics are still climbing up and the 3.x branch will remain maintained until we can provide the same out-of-the-box experience and an upgrade path for version 4. If you have questions or opinions you would like to share, please reach out in the #graphql channel on drupal.slack.com or contact us on Twitter.
 

Feb 12 2019
Feb 12

Amazee Labs is proud to sponsor Drupal Mountain Camp in Davos, Switzerland 7-10 March 2019.

Come by and see us in the exhibit area or at one of the social events, and be sure to check out these Amazee sessions: 

On Friday, from 14:40 till 15:00, join Maria Comas for GraphQL 101: What, Why, How. This session is aimed at anyone that might have heard or read about “GraphQL” and is curious to know more about it. The session will give a basic overview and try to answer questions like:

  • What is GraphQL?

  • Is GraphQL only for decoupled projects?

  • Advantages to using GraphQL with Drupal

  • Getting started with GraphQL

Follow this up on Friday from 15:00 till 16:00, with Daniel Lemon who will present Mob Programming: An interactive session. The basic concept of mob programming is simple: the entire team works as a team together on one task at the time. That is one team – one (active) keyboard – one screen (projector of course). It’s just like doing full-team pair programming. In this session you’ll learn:

  • What are the benefits to a team?

  • How could this be potentially integrated into your current workflow

  • The disadvantages to Mob Programming and why it might not work for certain types of companies (such as a web agency).

Additionally, don’t forget to check out this talk from Michael Schmid of amazee.io Best Practices: How We Run Decoupled Websites with 110 Million Hits per Month. This session will lift the curtain on the biggest Decoupled Websites run by amazee.io and will cover:

  • How the project is set up in terms of Infrastructure, Code, Platform and People

  • How it is hosted on AWS with Kubernetes, and what we specifically learned from hosting Decoupled within Docker & Kubernetes

  • Other things we learned running such a big website

Hope to see you in Davos soon! 

Jan 23 2019
Jan 23

What is “Open Source”? Is it really free?

Publishing software under an open source license means that you grant people the right to use, study, modify and distribute it freely. It does not imply that this process is free of charge. The legal framework just ensures that the operator - at least in theory - has full control over what the software is doing.


That being said, charging for open source isn’t common. The simple reason is that it's hard or in some cases even impossible to track where the software is used. Even if the maintainer added some kind of license check, the open source license grants the user the right to remove it, so any effort in that direction is futile.

Most open source developers generate revenue either by relying on donations or charging for support and maintenance. Since they don’t have to provide a warranty for each installation of their code, these strategies can often at least cover their expenses. In some cases, it’s even enough to make a living.

Should my code be open source?

Writing a piece of code that does something useful can lead down three different paths. These three options could be called lazy, crazy and safe. And that makes the decision a lot easier.

1. Lazy: Just keep that piece of code within the project

In the best case scenario, you will remember it if you stumble upon a similar problem four months down the road and copy it over to project B. You will probably find some bugs and do some improvements, but stakes are not high that they will make it back to project A.

In the worst case is that the lines of code are just left and forgotten and the problem will be solved once again, at the cost of the next project B, while keeping the full maintenance costs in project A.

2. Crazy: The solution is super-useful and so fleshed out that you decide to sell it under a propriety license model

Going down this road means serious marketing to achieve a critical mass, providing guarantees and warranty to customers, and paying a host of lawyers to make sure nobody steals the intellectual property or uses it in unintended ways.

This all boils down to starting a*high risk business endeavour*, and in most cases, it doesn’t make sense.

3. Safe: The solution is moved into a designated package

In the worst case, the code just stays in this package and is never re-used. More commonly, it can be picked up for project B, and all improvements immediately are available for project A. The maintenance costs for this part are shared from now on.


And in the best case, this package is made publicly available and somebody else picks it up and improves it in some way that directly feeds back into project A and B.

Advantages of Open Source in an agency

Client Value 

From our perspective as an agency, there is hardly ever a case where open source is not the best option. Our business model is to get the best possible value out of our clients' investment. We achieve that by contributing as much as we can since every line of code gets cheaper if it can be reused somewhere else. Some clients actively encourage us to share projects even in their name and some don’t care as long as we get the job done.

External Collaboration

Our core business value is our knowledge and experience in providing software-based solutions, not the software itself. And as long as our client agrees, we use our position to spark collaboration were it wouldn’t be without us. If we see requirements that pop up across different projects, we can align these and share the effort, which ultimately helps our customers saving money.

Internal Collaboration



Another reason for us investing into open source is our own setup. As a heavily distributed team, information flow and structure is even more important than for co-located companies.
I often see code not being published openly due to tightly coupled design, missing tests, or insufficient documentation.

The investment to increase quality is often billed against “contribution costs” and therefore the first thing to fall off the edge. But it actually is part of “doing your job properly”, since software should also work reliably and stay maintainable if its only used once.

Since proper architecture and documentation become vital as soon as different timezones need to cooperate on a single codebase, contributing has to become the standard process instead of the exception.

Apart from that, threatening developers with publishing their creations has proven to be a terrific instrument for improving code quality.

Open source products

If the produced software, or - more general - produced knowledge, itself is the product or would expose business critical information then it might not make sense to go open source. But even in such cases, interesting exceptions have happened.



Tesla’s heavily discussed move to release all its patents for electric cars to the public back in 2014 is not exactly the latest news. Some praised Elon Musks goodwill, while others called it a marketing stunt. The fact is, Toyota cancelled the partnership with Tesla around the same time and released its first hydrogen fuel cell car. A behemoth like Toyota focusing on hydrogen cells could have become a serious threat to the electric car industry in total. Releasing the patents was a way to strengthen the technology enough to overcome this obstacle. I wouldn’t dare to judge if the undertaking was successful, or if we would be better off with hydrogen cell cars. But this case illustrates how sharing knowledge can be as powerful as keeping it for oneself.



Another example is our sister company, amazee.io, who decided to open source their hosting platform “Lagoon” some time ago. Full transparency on how applications are hosted is a huge deal for technical decision makers, and it becomes a lot easier to gain their trust if they can see what’s going on. Sure, you *could* just grab the code, try to get your hands on some amazee.io-grade engineers, and strap them in front of their computers 24/7 to get the same level of reliability and support. But I doubt there is a legal way to do this with less money than just hiring the creators themselves.

Should everything be open source?

This might ignite some discussions, but I don’t think so. The open source community has suffered a lot from being associated with pure goodwill and altruism. And this has led to serious problems like developer burnout and subsequent oversights that shook platforms as a whole.

The “no license fee” bait did a lot more damage than it helped. There might be no fee, but that doesn’t mean work is for free. Compensation just works through other channels. And if this is not possible, it’s sometimes better to pay for a license than relying on an unsustainable open source solution. 


I personally see open source as a business model that embraces the fact that distribution of information is free. Instead of wasting resources on artificially locking down intellectual property, it focuses on creating actual value. And since I'm making a living of creating this value, I consider this a good thing.

Open Source as a model is one tool that gives us the ability to create innovative and ambitious projects for our clients. Get in touch with us today!

Jan 18 2019
Jan 18

March 2019 sees the return of Drupal Mountain Camp, in the picturesque town of Davos in Switzerland. The call for sessions closes at midnight CET on Monday, 21 January, so be sure to submit your talk today.

We’re proud to be part of the organising team as well as a Gold sponsor for this awesome community run event. We’ve submitted several talks and hope you do the same.

About Mountain Camp

The camp is designed to combine the beauty of the snow-covered Swiss Alps, with the warmth of the Drupal community. It's a perfect combination of fresh tracks for those who ski or snowboard, with inspirational talks by amazing people. This will, of course, be accompanied by some world famous Swiss cheese and chocolate.
 
The camp takes place from 7 - 10 March 2019, at the Davos Congress Centre.

Davos Congress Centre

Final call for sessions

Call for sessions close on Monday, 21 January, so don’t delay, be sure to submit yours today! 

Along with the great sessions, there will be 2 confirmed keynotes. The first on Friday, entitled "The Future Of Drupal Communities", by Drupal community leaders Nick Veenhofand and Imre Gmelig Meijling, and the second on Saturday by Matthew Grill, about the "Drupal Admin UI & Javascript Modernisation Initiative."

If that sounds interesting and you want to know more about the topic submission process, read on:

How can I submit a session?

  1. So you've got something you'd like to talk about, awesome, here's how you can submit a session:
  2. Head on over to the submit a session link.

  3. Think of a catchy title and fill in the Session Title.

  4. What is your talk about? Try to write 4-5 lines about what you'd like to talk about in the Description textbox.
    Note: you can add images if it helps to portray your talk.

  5. Select what kind of Session Type (how much time) you'd like.

  6. Input the appropriate Tracks - you may select multiple if your talk covers various topics.

  7. Select the Level of Expertise - is it more of a beginner talk or does it become quite advanced with technical terms?

  8. Don't forget to add your Speaker Name and Contact Email.


Session Talk

Why should I submit a session?

Preparing and then presenting helps to entrench your knowledge on the topic. You'll also learn from your peers who attend your talk, through feedback and questions.

Be sure to take note of the following, when considering your topic and submission:

  • Giving a talk will require a lot of work and preparation, but don't let that put you off. It will pay off in the end.

  • People who attend your talk are generally looking for help in your specific topic, so this will be a great time for networking.

  • You'll be noticed and people will tell you that you're cool.
 
  • Ok, maybe you don't want to be noticed, and maybe you're fine with not being called cool, but you'll definitely have fun talking.

  • You'll feel way more confident afterwards, which might be a good enough boost for you to jump on a snowboard and hit the slopes on the weekend.


Check out some of these great proposed sessions for inspiration:

I hope this has inspired you! Now go ahead and submit your talk and we'll see you in March in Davos, Switzerland. Till then, follow the Camp on Twitter.
 

Swiss Alps
 

Nov 28 2018
Nov 28

Once I got a task to fix a bug. While bug itself was easy to fix, I had to find the commit where it was introduced. To describe why I had to do it, I have to explain a bit our development process.

Our branching model

The exact branching and deployment workflow may differ from project to project, but we have two mainstream versions. One is for legacy amazee.io hosting and one is for Lagoon.

Here is the common part. The production instance always uses the latest prod branch. When we start to work on a new task, we create a new branch from prod. When the task is tested and demoed, we deploy it. Separately from other tasks.

We do this to speed up the delivery process, and to make our clients happy.

If a project lives on the legacy hosting system, it usually has PROD and DEV environments. For a task to be tested and demoed we have to deploy it to DEV first.

With Lagoon, we have a separate environment for each task, and this is awesome!

The bug I had to fix was on a project hosted on the legacy system. Also the bug was found on the DEV environment, and it was not present on PROD. So one of the active tasks introduced it (and at that time we had lots of active tasks). I had to find which one.

The bug

An element was appearing on a page, that it should not have appeared on.

The project

The backend is built with Drupal. The frontend is also Drupal, but we used progressive decoupling to embed dynamic Vue.js elements. In between - our beloved GraphQL. No test coverage (nooooooooooooooo.com) yet, but we have a plan to add it with some end-to-end testing framework. Most probably it will be Cypress.

Cypress

It's a modern e2e testing framework. It has lots of cool features, and some of them, like time traveling, help you not only to write tests but to develop in general. Just watch the 1-minute video on the Cypress website and you'll love it.

Git bisect

This is a very easy and very powerful Git tool. To make it work, you just need to give it three things:

  • a commit where things are good
  • a commit where things are bad
  • a command to test if things are good or bad

The result would be the first bad commit.

Docs: https://git-scm.com/docs/git-bisect

The search

Finally, I can share my experience in combining these two tools.

Since we don't yet use Cypress on the project, I installed it globally on my machine with npm i -g cypress and created cypress.json in project root with {} contents. That's all Cypress needed.

To run Git bisect, I used the following commands:

The my_test.sh was looking like this:

(I actually was lucky that for Drupal I only had to run cache clear after each Git jump. If, for example, there would be Drupal core updates in between bad and good commits, then running drush cr would not work. But in this case I could install Drupal every time from an existing configuration. It would have been a bit slower.)

And here is the Cypress test which I put into the path/to/vue/cypress/integration/test.js file:

It took a little time to set this all up. The result was good - I was able to identify the commit in which the bug was introduced.

Sum up

Modern e2e testing frameworks are easy to set up and use. They can do more than just automated testing. All it takes is some your imagination.

For example, once a colleague of mine had a task to do a content update on a project using an Excel file as a source. One way to do it was to do everything by hand, copy-pasting the data. The other way would be to write a one time importer. But instead, he turned the Excel file into JSON data and used TestCafe to do the click-and-paste job. This was faster than the first two options. And it was quite cool to see the visualization of the automated task - it's so nice when you can see the result of your work.
 

Nov 27 2018
Nov 27

Over 300 people attended this year, many of them backenders but also frontenders, designers, business strategists, and other stakeholders all coming together to share learnings, experience, and excellent local beers in the city of Ghent.

DrupalCamp Ghent was organised by the Drupal community, and we want to say  thanks to all the organisers for making all of this possible, with a special mention to Peter Decuyper who enlightened us with his sketch notes of the sessions.

It is the essence of camps to make the (difficult) choice between the sessions you will attend, so here are the highlights of the ones that we attended.

The organisers paid extra attention to the relationship between sessions, so many talks nicely complemented each other.

Decoupling and the future of Drupal: about UX, code, design and humans

The position of Drupal is constantly being re-evaluated. One of the values of the Drupal is paying attention to the people. The work of these last months brought one more time the proof of this value by covering a large variety of persona.

Authors and site builders

UX was covered in many ways, Clément Génin has been debunking the myths about user-centric design, and he explained the what by talking about a mindset and not a magic formula that can be applied on an existing project. I perceived his session as a way to build a love story between the designer and the end user.

Cristina Chumillas demonstrated the how by showing us the path that was followed for the Drupal Admin UI since 2017 and what we might expect for Drupal 8.7. If you want to help or just know more about this work, head to the Admin UI & JavaScript Modernisation strategic initiative.

Preston

Preston So gave us even more perspective, he started his keynote with the history of the Drupal frontend to continue with the emergence of wearables, digital signage, augmented reality, and conversational UI. Then, he introduced the concept of contexteless / universal editing with a multipolar Drupal that can reduce the custom work needed for decoupling. A good example of this trend is GraphQL. Content is like water: when the shape changes, it should adapt to its context rather than being context specific.

When it is about content, the editor is one of the most important stakeholders. Ruben Teijeiro provided a few answers to problems like page refresh, too much site building, or keeping the link between content editing and decoupling. Among other solutions, he mentioned modules like Elementor, Content Planner, Glazed Builder or Editable.

Designers

Dries Van Giel gave us an introduction to Sketch, a fully vector-based tool suited for web design, that leverages features like components (symbols), shared styles among documents and element export in multiple formats. This meets the current approach of component-based design (like Pattern Lab or Fractal does) and reusability.

Developers

GraphQL is all the rage nowadays, Peter Keppert talked about

  • When to use decoupling: multiple frontends for one CMS, Single Page Apps, …
  • The benefits of using GraphQL for that purpose: a self-documented schema, that is strongly typed and that allows to cache queries in the database.
  • The points that need attention compared to other solutions: possible information disclosure and the complexity that induces a change on the team.
  • The integration in the Drupal contrib ecosystem with Paragraphs and Box

GraphQL

Fabian Bircher explained how the Configuration Management (CMI) has evolved since Drupal 8.0. At the time, it was designed to cover the basic flow of deploying without modifications. Contributed modules have implemented several other use cases like configuration split or ignore, Drupal 8.6 added the installation of a site from a given configuration and Drupal 8.7 will introduce the new ConfigTransform service. Using Drupal as a product can also be implemented with the Config Distro module.

With his typical sense of humour, Branislav Bujisic gave us an introduction to Functional Programming. The foundation of his session was a comparison between Alan Turing states and Alonzo Church functions. He introduced concepts like immutability, static typing, and side effects elimination to improve testing and caching (memoization), with a control over complexity and more performant code. Even if PHP is not a functional language, a few of these principles can still be applied. Truly inspiring!

Testing and code quality

If you are looking for a way to contribute back to the Drupal, a lot of core and contributed projects needs manual testing. Just have a look at the 'Needs review' status on the Drupal issue queue. Automated testing is also welcomed, Brent Gees gave us all the keys to get started seamlessly with Unit, Kernel or Functional tests in his presentation How to get started with writing tests for contrib.

When it is about client work, the time that can be spent on tests may be more limited, and the approach is more about testing the assembly of components, so a pragmatic solution is to use fast Functional Testing with solutions like Behat. Tom Rogie showed how to configure Behat for several environments and browsers in a Continuous Integration workflow, but more importantly, what to test.

Improve easily the quality control tomorrow in your projects. Yauhen Zenko provided a nice way to run tools like PHP Linter, coding standards compliance and mess detection, wrapped in a Composer based solution.

Search

Joris Vercammen covered the best practices for Search API configuration, demonstrating in the meantime that most common use cases can be covered by a plain database server.

For a live demo, head to http://drupalsear.ch, that exposes most Search API features with the new Drupal Umami profile.

Advanced topics like machine learning and AI were illustrated by the maintainer of the Search API Solr Search module and the Solarium library, Markus Kalkbrenner with streaming expressions, graph queries and the inner workings of the Solr, sweet!

DevOps

Serverless is a buzzword that can lead to confusion. Robert Slootjes explained it with Functions as a Service (FaaS) and the action of removing the hassle of server provisioning and scaling.

Thijs Feryn, the author of a Varnish book, adopted the perspective of caching by diving deep into the http protocol. It was nice to get detailed explanations about the foundations of the web and the Symfony framework. The session was also demonstrating that Drupal already implements most of the best practices regarding caching.

It was awesome to see how many things can be learned in such a small amount of time, and we are already looking forward to the next edition!

Dinner closing

Nov 21 2018
Nov 21

For the past ten years, the Drupal community organises a yearly DrupalCamp held in various cities of Belgium. This time, it will take place in the lovely city of Ghent.

As usual, the organisers are broadening the audience of this event with content aimed at developers, designers, site builders, and business strategists. They also contribute to this goal by maintaining low ticket prices.

The sessions are raising the bar too, with hot topics such as search, accessibility, functional programming, chatbot, testing, GraphQL, and serverless.

I’m excited to take this opportunity to enjoy the community, expand upon my knowledge of the Drupal ecosystem, and prove once and for all to my fellow Amazees, Dan and Vijay, that there is no comparison between Belgian and Swiss chocolate.

View the full programme here.

Oct 31 2018
Oct 31

Join us on November 5th for the Zurich Drupal Meetup at the Amazee Labs Zürich office.

Agenda

  • The File Management Module for Drupal 8 - Lightning talk + Q&A by David Pacassi Torrico
  • Outlook Drupal Switzerland Activities 2019 - Discussion by Josef Dabernig (Amazee Labs)
  • Propose your topic in the comments!


General Information 

The Zurich Drupal Meetup is dedicated to people interested in the Content Management System & Framework Drupal.

We welcome everybody from beginners to Drupal ninjas and would be happy to see you present a recent project of yours or talk about any other Drupal-related topic.

Talk Formats

  • Lightning talk (max. 10 minutes)
  • Short talk (max. 25 minutes)
  • Full talk (max. 45 minutes)

If you would like to join us, sign-up here: https://www.meetup.com/Zurich-Drupal-Meetup/ 

Oct 23 2018
Oct 23

A full rebuild of a website can be a time consuming and expensive process. Upcycling is an incremental approach to relaunching existing websites. This blog will explain more about what upcycling is and why it might be the right choice for your website

Why upcycle?

Most websites will be rebuilt every three to six years to keep up with online trends, because of technical debt, or simply to refresh their appearance. At Amazee Labs, we have helped many clients transition from their legacy web systems onto Drupal 8 but not everyone is ready to do the move all at once. This is where upcycling can come into play.

As upcycling is intended to be an incremental approach it might not be suitable for every use case or every client. Upcycling de-prioritizes the “one-big-bang-launch-wow-effect” and allows us to partner with our clients to meet one primary goal: reduce time to market for big website improvements and maximising the value of time spent.

When to upcycle?

If you have a well-established web system that has been operational for several years, and you aren’t ready to spend the time and money to do a full rebuild, upcycling might be the answer.

Upcycling Process

As you can see, upcycling can be performed at any stage of an existing web project. Depending on the size of the upcycling project, we might transition from the maintenance and extension mode back to implementation. Alternatively you might do a smaller upcycling project within the maintenance & extension cycle. Large upcycling projects will often mean moving all the way back into a conceptual consulting & discovery mode before we start implementing new features or functionality.

What to upcycle?

We’ve designed an upcycling questionnaire to guide the conversation with the customer with regards to different aspects of the website. Although these are common areas for upcycling, we use this questionnaire as a starting point to discuss what will be the best fit for each project.  

Upcycling Areas

For each of these upcycling areas, we have a set of questions to validate the potential and need for upcycling. For example, when we talk about design we would ask if the look and feel of the website is perceived as outdated or if there are any inconsistencies within the current design implementation.

If we identify an area that could benefit from upcycling, we will provide a set of recommended steps for improvement. In this case that might be a design refresh, establishing a design system, or rebuilding the frontend.

We also provide upcycling case studies to show our clients what is possible with upcycling, and help build on their ideas to improve their website without starting from scratch.

How to upcycle?

Upcycling demands that we are in a position to split things up.

An example is Sonova.com. The main website has been running on Drupal 7 since 2014. Last year, we started relaunching individual country pages using Drupal 8. These new pages allow the content managers on the client’s side to benefit from the better editorial features of Drupal 8 early on without needing to wait for a relaunch of the entire website. Gradually we keep relaunching country page by country page on Drupal 8.

Upcycling Sonova Drupal 7

Sonova Country Page Version in Drupal 7

Upcycling Sonova Drupal 8

Sonova Country Page Version in Drupal 8

The next step in upcycling this site will be a relaunch of the main website on Drupal 8. When we are ready for that step we can build upon the incremental steps we started for the country pages.

As well as the additional editorial features, we also worked with the client to choose a different Drupal theme. . This means sites running on Drupal 7 feature a different design than the sites running on Drupal 8. So instead of merely optimizing for consistency across all country pages, together with the client, we chose to allow to innovate and bring newer design versions to the local markets without waiting for the relaunch of the whole site.

How does upcycling relate to decoupling?

If your site has some complex backend logic that you don’t want to rebuild but you are eager to relaunch the frontend, upcycling could be the solution. Usually, we would relaunch the frontend within Drupal’s theme layer. But in certain cases, it makes sense to relaunch the frontend as a decoupled site and then integrate the existing backend. We recently did this for a customer that wanted to get started with Drupal 8 but had some complex Drupal 7 Backend logic that needed to be maintained.

On the other hand, if the backend really needs an overhaul and you want to keep the existing frontend without rebuilding it, upcycling could work for that too, after decoupling the backend.

Decoupling your architecture will enable you to upcycle individual parts and bring value to the end user faster but it also comes at a price of added complexity. In the end, it’s important to compare the advantages and disadvantages

Pros of upcycling Cons of upcycling

Get the most out of your existing website infrastructure

Benefit from user experience, design or frontend performance improvements without the need to wait for a big relaunch

See your investments as quickly as possible

Potentially added complexity when maintaining two systems at once.

Potentially inconsistencies in the appearance if sections are upgraded separately.

Partly you need to invest into a legacy platform rather than spending everything on the new one

More details on upcycling can be found in this presentation.

What’s your experience & challenges when it comes to upcycling? Do you have an existing project that you would like to improve? Let us know in the comments or reach out via the contact form.

Oct 11 2018
Oct 11

The second Amazee Labs webinar took place last Friday, 28th September 2018. Philipp Melab gave a stunning presentation on “Atomic Design in Drupal with GraphQL & Twig”. Here's a short recap of what we learned together.

We kick-started the webinar with a summary of what we learned in the first webinar, in case you missed that you can read up on it here. This time our focus was to build a real-world example website for a fictional web agency called Amazing Apps.

Amazing Apps design

Philipp wanted to pack as much information as possible into the webinar, so he set up a Github repository with everything you need to get started. We were shown a brief design of the end goal then jumped straight into the meat of the presentation by dissecting the git history of each commit in the repository together.

Clean, concise, & a well-structured frontend.

Fractal is a tool to help you build and document web component libraries and then integrate them into your projects. We were led through the basics of what Fractal provides as a starting point. Then we jumped through the repository to a point where we had a couple of components built, along with colours defined using CSS variables along with demo text content.

As part of Atomic Design, we explored and learned the use of atoms, molecules, and organisms. Atoms demonstrate all your base styles at a glance, such as a logo or a button. Molecules are UI elements containing two or more atoms functioning together as a unit, such as a menu. Organisms are relatively complex UI components containing multiple molecules, atoms, or other organisms, such as the header or footer.


fragment Menu on Menu {
  links {
    label
    url {
      path
    }
  }
}

Once we got to the menu component, we were treated with the first GraphQL fragment, from here we could navigate up the templates from molecule to the header organism, and then to the page layout template which called the twig block named header. We can then override these blocks with the use of the twig tag extends to inject our Fractal based templates as necessary along with our GraphQL fragment.

GraphQL Twig should be used to decouple things where it makes sense, building a fully decoupled solution still costs a lot regarding development; therefore GraphQL Twig is the right solution to enhance and modernise a site in a feature based manner.

Learnings as a webinar host

It was our second webinar, so we had a few learnings from our first edition which we incorporated into the new session. We made sure to start earlier with the marketing campaign to ensure a good turn out, and ideally a larger audience; we ended up with over 40% increase in the total audience!

Check out the Github repository and accompanying videos:

Amazee Labs would like to thank everyone who attended the live session, we enjoyed being able to share this with you, and we look forward to hosting another Amazee Labs webinar in the future.

You can watch the entire webinar here:

[embedded content]

Sep 19 2018
Sep 19

So here we are, post-Drupal Europe 2018. Talks have been given, BOFs attended, way too much coffee and cake have been consumed, and now I’m tasked with summarizing the whole thing.

The problem faced by anyone attempting to wrap up the whole of an event as momentous as Drupal Europe is that you have two options. On the one hand, you can give a fairly anemic bullet-point summary of what happened and when. The advantage of approaching a summary like this is that everyone who was at Drupal Europe 2018 can look at the list and agree that, “yes, this is indeed what happened”.
Fair enough. Maybe that would be a better blog?

But that’s not quite what I’m going to be doing since (as you’ll find in the links below) my colleagues have done a stellar job of actually covering each day of Drupal Europe in their own blogs. What I’m going to do, rather, is tell you about my Drupal Europe. And my Drupal Europe was far less about talks and BOFs (and coffee and cake) than it was about the people in the Amazee Group and the Drupal community in general.

Reasons to get off the Island

For background, I live in a smallish town (we have a mall and everything) down here on the South of the North Island in New Zealand. Getting myself to Darmstadt involved nearly 30 hours in those metal torture tubes we commonly call “airplanes”. Under most circumstances I’d avoid this kind of travel, but Drupal Europe was an exception because it presented me with the one opportunity I had this year to spend time with and around my teammates in Amazee Labs Global Maintenance specifically, and the rest of the Amazees at the conference in general.

I came to Drupal Europe in order to have the kind of high-bandwidth conversations that (very) remote work almost never allows. It allowed me to meet some of my colleagues in person for the first time, in some cases people who I’ve been speaking and interacting with online for more than a year. Outside of the hours of strategic meetings we all had, it was a joy spending time sharing screens IRL and looking at code, eating kebab (so much kebab), and (wherever we could) doing a bit of real work in-between.

And while my reason to get off my island was really my colleagues at Amazee -- being present, alongside, and with them -- the importance of the wider Drupal community is not lost on me and attending Drupal Europe highlighted to me, once again, just how special that community is.

Beer hall at dusk

We’re hiring, by the way.

In her deeply moving talk about her journey from being a freelancer to being the Head of Operations for ALGM, Inky mentioned the principle of Ubuntu. This ethical and metaphysical principle is often rendered in English as “I am because we are”. In one interpretation, at least, it suggests that our existence as individuals is inextricably intertwined with the existence of others. I think that something like Ubuntu is true of both Amazee and the wider Drupal community.

What makes Amazee special is the remarkable individuals that comprise it, indeed, I doubt I would’ve been as enthusiastic as I was to travel so far if they weren’t remarkable individuals. But I have to wonder whether those individuals would shine quite as brightly in any other company? Amazee gives us the space to be the best we can be and whatever shine we have as individuals makes Amazee glow that much brighter.
Zooming out a little, Amazee, as an organization, would not exist as it does without the wider Drupal community. And the Drupal community would be poorer, at least in my opinion, without the work that Amazee does.

It’s circles within circles within circles, each strengthening the other.

Showing your work.

This was a theme in the Amazee talks at Drupal Europe. Stew and Fran, in their discussion of Handy modules for building and maintaining sites ended things off with a note encouraging everyone who manages to solve a Drupal problem to consider how they might contribute it to the wider community. Indeed, Basti made this the theme of his entire talk, discussing the benefits of open sourcing your work and the material advantages the IO team has experienced by open sourcing their platform, Lagoon. And in terms of open sourcing code, Stew’s talk on Paragraphs has already lead to the creation of a brand new Drupal.org module from an internal Amazee project. Is this an example of upcycling, hmm, Josef?

Stew and Inky, showing their work.Stew and Inky, showing their work.

We’re off the Island now, time to go farther.

Speaking of circles, in some respects the move in the Drupal community in the past few years has been to expand our circles even further into the wider programming communities. Drupal 8 adopted much “external” code from the supporting PHP communities. But to some extent, we’re moving even further away from the Drupal island than simply playing-nicely with the PHP community. Decoupling Drupal, a major research topic right now, is at least in part about getting Drupal to be less monolithic, for it to serve content to systems and in contexts that aren’t necessarily Drupal specific. It’s no exaggeration to say that Amazee is ahead on the curve on this, as was evidenced by Michael and Philipps' talks. Michael discussed the “implications, risks, and changes” that come from adopting a decoupled approach, while Philipp simply dazzled a packed room with his demonstration of staged decoupling with GraphQL integration into Twig.

Drupal Europe art installation

This was Drupal Europe.

This was Drupal Europe. Not just talks, or coffee, or BOFs, or the (delicious) lunches. Rather, it was the opportunity to really dive in, experience, and behold the interlocking circles of individuals, friends, companies, and community that holds this sprawling structure we call the Drupal ecosystem in place. To get a sense where we are and where we’re going.

Previous Drupal Europe Blogs

Sep 14 2018
Sep 14

Vijay tells us about the fourth day's highlights in Darmstadt, Germany.

Keynote

The 4th day of Drupal Europe began with a discussion by a panel made up of Dries Buytaert, Barb Palser, Heather Burns, Hurley Mautic, and Timothy Lehnen, about the future of the open web and open source. Some interesting points were made, especially how we have the responsibility of making open source better, and how we can better protect the four software freedoms principles.

First session

Decoupled Drupal: Implications, risks and changes from a business perspective

Next up was our very own Michael, who gave a presentation on Decoupled Drupal. Some interesting points were made in this presentation. As a developer I love the fact we can experiment with technology, however, I never really gave a second thought about how this can have an impact, both for the company and potential clients. Decoupling for sure has success and failures that we all are going to experience. For example, time to train the team to be up to date with the latest technology and with this come cost. In the end, however, it is an investment. One clear message from this presentation that I took was we should expect failure, and we should not get discouraged by it, but rather learn from it. We should also celebrate the success.

JavaScript Modernisation Initiative

The third presentation I went to was the JavaScript Modernisation Initiative, presented by Lauri Eskola, Matthew Grill, Cristina Chumillas, Daniel Wehner, and Sally Young. As a contributor to this initiative, it was great to hear how this idea came about as this was something I didn't really know. I came to learn that it all began at DrupalCon Vienna, where the idea of how to create a decoupled backend, with a redesigned, and modern administration experience in Drupal came up. As of now, the product is clearly in the prototype stage, with plans to remove the current implementation of Material UI and update using the design created by Christina, which is in the early stages of concept. If you would like to get involved in this initiative, you can find out more on the Drupal website.

Improving the Editor Experience: Paragraphs FTW

After lunch, it was time for Stew to give his second presentation of the week, this time on his own. His presentation was all about paragraphs, a beginners overview of using paragraphs to make the editors experience more fun. Stew went on to explain how to give more control over content layout, and the pros and cons of some of the contrib modules that support paragraphs. Even though this presentation was about Paragraphs, Stew did mention that there were other alternatives to this great module. Way to go Stew, two presentations in one week.

Stew's session

Decoupling Drupal with GraphQL & Twig

The final presentation I attended was by Philipp. He explained what GraphQL is and what it is not, and how much more it can do, such as Search API indexing, and feed Twig templates. One exciting part of this session was the reuse of fragments, meaning you can write one query and reuse it across many templates. It is clear to see why GraphQL is very popular, however, one interesting point that was brought up was that it isn't the same as injecting SQL into Twig. Phillip responded by saying a GraphQL query is not something that is executed, it is a definition of requirements, which you request from the implemented backend. Phillip also thanked Sebastian Siemssen, who happens to be both a core maintainer of the GraphQL module and an ex amazee.

Phillipp's session

Closing

After the conference, we headed back to the hostel to refresh and then headed out to eat for our final night in Darmstadt. After that we headed back to the venue for trivia night, this was my first time at trivia night, and it was full of fun, great people, atmosphere, food and drink, and great questions. After six rounds of questions, lots of laughter, and a small hiccup with their Google doc, the scores were tallied, and team 16 had won first prize, of which included Stew and Mostfa.

Winners

You could also say that Day 4 was pretty “Amazee-ing” with lots happening with our team. Congratulations to all from everyone at Amazee, both at the conference and those left behind.

I would also personally like to thank the Drupal Association for giving me a diversity ticket without which I would not have been able to attend this great conference and have a week of both excellent presentations and being able to continue to contribute to great initiatives.

Sep 13 2018
Sep 13

Mustapha tells us about the third day's highlights in Darmstadt, Germany, and some exciting announcements!

Drupal Europe 2018 - Wednesday 

The third day of Drupal Europe was a big day, we had the prenote and the Driesnote with some exciting announcements, the group photo, and a lot of interesting sessions.

The Prenote:

Our big day started at 8:15 with the prenote, which is very important because it shows you how awesome this community is. We were singing together and laughing very loudly about some "geek" jokes which would seem strange to others but not to us because we are living those jokes each day. The prenote is important because it makes you feel that you're not lonely, but you have all this family from around the world.

prenote

Driesnote:

At every Drupal conference, Dries Buytaert, the leader of the Drupal project, shares updates on the current state of Drupal and makes some announcements on the way forward.

Dries

He firstly spoke about the Drupal 8.6 release which has some great content management improvements, which can be discovered here. Then the announcement party started and here are some of the highlights: 

- The adoption of React and JSON API to build a new decoupled administration UI.

- Drupal 9 will be released in 2020.

- Drupal 7 will have an end of life by 2021.

- Drupal 8 will too have an end of life by 2021, but it will be an easy upgrade to Drupal 9.

- Drupal.org <3 Gitlab: drupal.org code will be moved to Gitlab.

- There will be a Drupalcon next year organized by the Drupal Association and it will be held in Amsterdam.

Amsterdam

After those exciting announcements, everybody went outside the Darmstadtium for the Group Photo which was taken by our own, Josef Dabernig.

Talking about Josef, he had a great a session entitled "Upgrading vs. Upcycling - How to stay ahead of the curve". It covered the life cycle of a Drupal project, how to audit your Drupal website, and which improvements you can propose to clients.

Josef

Last but not least, after such an exciting day, we went to do our Amazeeng "Team Dinner" and finished off our big day with lots of fun.

Team dinner

Thursday's Program: 

Thursday's speakers:

Sep 12 2018
Sep 12

Maita tells us about the second day's highlights in Darmstadt, Germany!

Tuesday, Day 2: Drupal Europe 2018.

From day one I was blown away by Darmstadt and seeing so many of the Drupal community all in one place. This is my first big Drupal event and I'm so glad to have this opportunity. 

One of the things I struggled with, was choosing which talks to attend. How do you know which one is most beneficial? I did my best to choose sessions I found interesting, and listening to Benjamin talking about Dynamic Virtual Reality apps with decoupled Drupal did not disappoint.

Drupal Europe

After the first session, we had a long lunch break and I can happily say that the food was amazing. We shared some Drupal stories over lunch and found that everybody has a different story. That's what makes the whole event and the Drupal community, so special.

Drupal Europe

After lunch, Tim and I attended Willy Wonka and The Secure Container Factor where Dave Hall gave us great tips on how to make our containers more secure and how to shorten our build steps. We also got to indulge in a small chocolate treat. We have recently started using Docker, so I felt attending this session would shed more light on it, especially when there's a lot of chocolate involved.

Drupal Europe

The next session, after lunch, was Fran and Stew's on choosing the right modules to install when building and maintaining Drupal websites. They gave a list of modules which were a must to install, as well as a detailed explanation of their benefits.

Handy modules when building and maintaining your site 

Drupal Europe

Another session that happened around the same time was Basti's. He talked about the benefits of open sourcing code. He mentioned how last year they (amazee.io) open-sourced all the code that runs in their production environment for everyone to see and contribute, and how it made a huge difference for their team and managed to speed up development. His main point was to encourage people to start getting open to the idea of open sourcing their code.

Basti

The last session of the day was from Inky. She gave a very intimate talk on her journey to becoming the Head of Operations for the Amazee Labs Global Maintenance team. She talked about the good, the bad and the ugly and how all that made her the most suitable person for the job.

Drupal Europe

There were a lot of other happenings throughout the day, that I, unfortunately, didn't manage to attend. Next time I am going to get myself a Time Machine so I can be in two places at the same time and I don't have to miss out on anything. Until then, I'm grateful that each session is recorded. See you tomorrow, Drupal Europe!

Wednesday's Program: 

Wednesday's speakers

Sep 11 2018
Sep 11

Stew gives an account of the first day's events in Darmstadt, Germany: team bonding, furniture assembling, and community.

Monday, Day 1: Drupal Europe 2018.

Picturesque buildings from history surrounded me, as I looked out the window of our hotel room at Hessenpark Open Air Museum, just north of Frankfurt. The Global Maintenance team workshop weekend was about to draw to a close and a week of Drupal Europe was about to begin. This would be my first international Drupal event, ever!
 

Hessenpark Museum


Our morning started with a delicious continental breakfast and strong coffee. The team went for a productive 'walk and talk', discussing ideas about our international and growing team, multiple projects, and how we will manage maintenance and new features.
 

Hessenpark Natural amphitheatre


From there, we all took off for Darmstadt, saying goodbye to Kathryn and Kristy (who were headed back to Austin, Texas) and Jason and Ltisch (heading to Zurich).

Walking into the enormous conference venue was a treat, seeing all the sponsors and companies putting up their stands and displays. I even got to see Dries walk by. I didn't think I'd be such a fanboy, but my smile was brimming. While Tuesday is the official starting day, there were several workshops already occurring when we arrived.
 

Darmstadt stadium

We constructed our Amazee lounge and it almost became a team building exercise. We got to use the trusty tools we brought all the way from South Africa to open boxes but found that well, everything was included. Of course, reading the IKEA manual helps...

The Amazee Global Maintenance team setting up the Lounge

After that, we got served a delicious lunch at the venue and then caught up with some work and conference preparations.

Amazee LoungeThe end result: The Amazee lounge couch.

We found our DJH Youth Hostel and got checked in, only to quickly go out again to share a Thai dinner which was very, very good.

As I complete this blog I am sitting next to Amazees from around the world: Mustapha (Tunisia), Michi (USA), and Basti (Switzerland). It's a great feeling when the team gets together from around the globe and I can't wait to see what tomorrow will bring. Check out some Amazee sessions and stop by our lounge to kick back and relax.

Tuesday's Program: 

Tuesday's Speakers:

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web