Feb 13 2020
Feb 13

Amazee Labs has been awarded the Daimler Key Supplier Inspiration Award for 2020! 

Markus Schäfer, Member of the Board of Management of Daimler AG and Mercedes-Benz AG, responsible for Group Research and Mercedes-Benz Cars Development, Procurement and Supplier Quality, presented the award to Amazee Labs CEO, Stephanie Lüpold on 12 February 2020 in Stuttgart’s Carl Benz Arena.

In presenting the award for outstanding suppliers, Mr Schäfer said “In order to fulfil our role as innovation and technology leader in the future, we also expect courageous impulses with inspiring visions in all areas from our partners. Together we are creating ground-breaking mobility solutions that are in line with our social, environmental and economic targets.”

Amazee Labs Daimler Supplier Awards

Amazee Labs won the award for developing the content management system for Daimler’s new smart.com website. They were able to set new standards in mapping internationalization processes thereby turning a former challenge of Drupal into a major advantage. 

Stephanie Lüpold, CEO of Amazee Labs is exceptionally pleased: "We want to thank Daimler for the award. As a strong player in the Drupal open source community, Amazee Labs has solved one of the top challenges faced by Drupal by developing a new, revolutionary and easy way to manage content internationally. Not only have we solved this issue for Drupal, but it’s also helped Drupal achieve a significant advantage over other systems. The team has done an outstanding job. We are extremely pleased that our solution is already being used successfully by several multinational companies, including Daimler. This award is recognition of our hard work and great motivation to continue to do everything possible for our customers".

Amazee Labs - Daimler Supplier Awards

Amazee Labs wants to congratulate all the other winners, it’s an honour to be included in such esteemed company.
 

Jan 20 2020
Jan 20

Conferences and camps are the lifeblood of the Drupal community. They provide in-person opportunities to grow our skills, our learnings and our projects beyond our current limitations and perspectives.

DrupalCon 2019 in Amsterdam was no exception! The open-source community was out in full force, doing what we do best — asking questions and seeking the smartest answers/solitons to our most challenging questions/problems.

From the Driesnote to the Women in Drupal Luncheon, from the First-Time Contributor Workshop to Bird’s of a Feather sessions, DrupalCon Amsterdam tackled such a wide range of exciting topics, we had to find a way to show you some the highlights as we look forward to another great year of open source community and events. 

Check out the entire highlights video below -- see you at DrupalCon Minneapolis! 

[embedded content]

Jan 17 2020
Jan 17

Last year I embarked on a personal open source challenge, focused on Drupal. Very easy to say: “12 months 12 patches”. Some months my work lent itself naturally to contributions, but when it didn’t, I got creative. Here’s how I made it happen, and inspired others on my team to follow suit. 

Drupal


I’ve been working with Drupal for quite a few years now. Drupal is open source, and thanks to that, we (and so many other companies) can build powerful websites that match our client’s expectations. Drupal has a very powerful and capable core which offers CMS functionalities that allow you to build powerful sites by clicking around the Drupal UI.

It also has contributed modules, which aren’t used on every site and you can choose to enable for your new site if you need that functionality. There is also a big pool of base themes that you can build upon that will give your site a great starting point and make it look nice.

We often build on top of existing modules and themes. We enhance them or create our own, sometimes tailor-made to the site’s context, sometimes generic enough so the module or theme can be made available to Drupal and therefore to the whole community. 

I’ve always loved this. By sharing it you make the product bigger, more robust, better in general and we don’t need to reinvent the same wheel over and over. 

Modules and Patches


However, building a whole new module or theme is usually not a quick task, or even desired in some cases (if something similar is out there already). So we often find ourselves trying to leverage existing modules. 

Probably the easiest way to contribute to an already big community and an already big set of modules and themes is to help them improve by either fixing little bugs, or by adding new features to them. This is done usually via what we call “patches” (which under other platforms could be called a “pull request”). A patch is just a file that contains changes to the existing source code that will fix or enhance the given project.

For example: if the webform module lacks a type of field for emails, we could create a patch that adds that capability and submit it for the community to review it, and to the maintainer to merge it into the main project. If all goes well, then the webform module will now support emails as a field type, so everybody will benefit from it when updating the module.

The Challenge


At Amazee Labs, we encourage a workflow that lends itself to both contribution and client projects. I knew I wanted to incorporate contribution into my work on an even more regular basis, so my 2019 resolution was to submit (at least) one patch a month to a Drupal module. 

Some months it was easy, especially when opportunities for the contribution came right out of working on a ticket. For others, it wasn’t so easy. When I didn’t see any obvious chances to contribute in my work for the month, I set a practice of searching through the issue queue of any module I was installing and working on one of them. This made me inspect the code, see how it was structured and eventually create a patch for an existing issue.

Working in this manner vastly improved my Drupal knowledge, and cemented my personal resolution to regularly contribute. After each month, I felt like I was helping Drupal (even if it was just a tiny bit) one way or another.

Drupal Patches

I was really happy that I could complete the challenge. Some team members joined during the year and that made the challenge more fun and encouraged me to carry on. Also, as team lead, I had already agreed with some of my team members to set this challenge for them as well for 2020. We have a Slack channel where we share the patches, ask questions, encourage each other, etc.

So if you’re using Drupal and you’d like to contribute more, maybe this could be a challenge that you could also take for 2020.

The Patches


In case you were wondering which patches were submitted, here is the full list:

January

February

March

April

May 

June

July

August

September:

October 

November

December

Happy coding!
 

Dec 10 2019
Dec 10

Web components are a collection of web standards allowing you to create new HTML tags with custom names, reusability and full encapsulation on styles & markup. Because they are included in the HTML spec, they are compatible with the big frameworks. None of the big frameworks can avoid supporting HTML (as this is required to render in a browser) therefore support for web components is guaranteed. 

In this blog, we’ll talk about the advantages of using Web Components as well as how to avoid common problems.

Basics
 

Web Components consist of four main standards which can be used independently or all together:

HTML Templates: necessary for writing reusable code and declaring how it should look
HTML Imports: these let you import HTML code and reuse your components in other pages
Shadow DOM: the rules on how to create a unique DOM encapsulated by HTML markup
Custom elements: needed for adding new HTML elements into the DOM

This DOM addition gives us the ability to “componentize” the web into small, reusable, modular containers that fit into web apps. Best of all, they’re purely built with HTML, CSS, and JAVASCRIPT. 

Challenges 
 

Some of the most common challenges are:
           
Code complexity: building web components can be complex and developers often think they will require writing a large amount of code to implement simple functionality.            
Shared resource: A web component has its own scoped resources. There may be cases where some of the resources between the components are common.                
Polyfill size: The polyfill are a workaround for a feature that is not currently implemented by the browsers. These polyfill files have a large memory footprint.                
SEO: As the HTML markup present inside the template is inert, it creates problems in the search engine for the indexing of web pages.

Solution
 

Lit-element is a simple base class for creating fast, lightweight web components. Its familiar development model makes it easier than ever to build Web Components. You can express your UI declaratively, as a function of state. No need to learn a custom templating language – you can use the full power of JavaScript in your templates. Elements update automatically when their properties change.                    

LitElement also uses lit-html to define and render HTML templates. DOM updates are lightning-fast because lit- html only re-renders the dynamic parts of your UI – no diffing required.

Check out the examples below to see it in action: 

HTML Code    

CSS Code

JS Code

Code example 
https://codepen.io/mattiasimonato/pen/wvBvLgZ

Dec 04 2019
Dec 04

We need to start somewhere, though, and there is perhaps no more important topic in automation than standardization.

In the Amazee Labs Global Maintenance (ALGM) team we provide long term support for Drupal sites. This includes things like monitoring, updating modules and core, applying security patches, etc. (https://www.amazeelabs.com/en/journal/web-maintenance-service-our-clients). Each ALGM team member will typically work on two or three sites during their day, and over the course of a month we may do work across several dozen different projects.

Modules and core - standardizing structure and versions


Let’s first consider the question of updating, patching, etc. The real bread and butter of maintenance. Here, effectively standardizing what is potentially invariant between sites is crucial.

One of the first major items of work that we do when a project comes into ALGM is to spend time getting the overall structure of the site looking like every other project we have in ALGM. We move themes and modules into standard directories, we make sure that the configuration details are stored where we expect them to be, and so on.

This does a couple of things - firstly, it reduces the cognitive overhead of working with the project. This is a major theme, and I’ll discuss it in more detail later, but if you just know where everything will be in any of the 30 projects you’re going to be working with during the course of a month, you’re going to be saving yourself a lot of time.

Secondly, we know that if we write a script for one of our sites (to, say, pull metrics about the files on disk) we know that anything we do for one site will automatically apply to any of our others, since their structure is normalized.

The other big task in onboarding is assessing the state of the project, what kinds of modules have been installed, are there any alpha modules? Are there any patches being applied to contrib modules or to core?

Bleeding edge modules and ad-hoc patches might be okay if you’re looking after one or two sites, but when you scale to any reasonable number, they can spell disaster.

Consider alpha modules, for example - they may provide precisely the functionality you’re after, but there are no guarantees that the module is going to provide a working upgrade path between versions. When it comes to upgrading the system, say, to patch a security vulnerability, you may not be able to automatically upgrade because of the lack of upgrade path.

This is, of course, your bad, since using experimental and early-stage developed modules are bad practice.

Considered from a maintenance perspective, choosing to use modules with no guaranteed upgrade path is a problem because for each of these modules, upgrading may require human intervention. And when you’re patching 80 sites to deal with, for example, a major security vulnerability, human intervention translates directly into the amount of time our sites will be down until they’re patched.

A similar argument applies to patches and forking modules (but these cases aren’t as clear cut).

The take-away here, though, is, try every other solution before using patched, forked, or unstable modules. It’s not just about getting the project over the line, it’s about making sure that it can thrive after it has been launched.

Standardizing workflow


In ALGM we work on sites developed at all different times over the last decade. In that time we’ve seen massive changes to the way sites are built – everything from how dependencies are managed (the whole site checked into Git, submodules, composer), to how the frontend is built. Again, if you’re only working on a handful of sites, you may get away with a README to remind you how to get the site working locally, or how to compile your SASS. But for any reasonably large set of sites, this kind of ad hoc work becomes unmanageable.

Part of our standardization process addresses exactly this. Where there is variation in the build process, we try and abstract these differences away.

Say you have two sites, one whose frontend is built in SASS and Babel, the other built with LESS and uglify. From the maintenance developer working on updating the site’s modules, for instance, the difference between these two frontend builds is irrelevant. And yet, if she wanted to test the site locally, she’d need to build the frontend out to CSS and JS.

How we abstract these is by having a single command, across all sites, that builds the frontend. That way, the developer knows that to build any of our sites, she just has to run a command like “ahoy build-fe” and the front-end assets will be built.

Beyond the convenience of this, there’s another upshot. The code wrapped inside these commands is really the only documentation you need about your site’s front-end build. It’s often said about comments in code that they are lies waiting to happen. For the most part, this will also be true of any documentation you write about your build process. The code that actually builds the process can be trusted to not tell you any lies since it’ll never be out of date, and you know it works because, well, it actually does the job it says it does.

There are a few ways of doing this kind of wrapping. Bash scripts work, as does the trusty Makefile. My own preference is to use Ahoy (https://github.com/ahoy-cli/ahoy).

Let what’s unique shine bright


I remember reading a story about one of the modern Zen masters (for the life of me, I can’t recall who it was, possibly Seung Sahn) that always struck me as pretty insightful. A student came to the master to ask why, when they meditated, they all wore uniforms. Surely, the student asked, when we all wear these kinds of drab sitting robes, we lose our individuality? The master said that, in fact, the opposite is true - by standardizing all the irrelevant details, it is what is truly individual in the student that is allowed to shine through.

The same is true for maintenance. By normalizing, standardizing, flattening out all the irrelevant and invariant details of our sites, we can better see and attend to the differences that really make a difference to our sites.

Want to know more about how our dedicated maintenance teams can keep your site secure, updated, and relevant? Check out our services page or get in touch today!

Nov 27 2019
Nov 27

Emerging from test-driven development practices, Behavior-Driven Development is an Agile software development process that supports collaboration among developers and non-technical and business contributors to help formulate and standardize a concrete understanding of how the application should operate.

In our latest webinar, we demonstrated how to use Cypress (and the respective integration module for Drupal) for Behaviour Driven Development (BDD) to elevate the quality of your code and project.
The webinar covered a brief introduction to BDD and testing in general, an introduction to Cypress, how to install and use the Cypress module for Drupal, adding E2E tests to a custom module, and testing a full Drupal project. 

If you’re curious about how Behavior-Driven Development and Test-Driven Development with Drupal & Cypress.io could improve your next project, watch the full Webinar below.

[embedded content]

Nov 12 2019
Nov 12

In our upcoming webinar – Test-Driven Development with Drupal & Cypress.io – we will demonstrate how to use Cypress (and the respective integration module for Drupal) for Behaviour-Driven Development (BDD) to elevate the quality of your code and project.

Evolving from test-driven development practices, Behavior-Driven Development is an Agile software development process that supports collaboration among developers, stimulating teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.

This webinar will include:

  • A brief introduction to BDD and testing in general
  • An introduction to Cypress
  • Installing and using Cypress module for Drupal
  • Adding E2E tests to a custom module
  • Testing a full Drupal project

Please join us to learn how to get more out of your latest project with Test-Driven Development and Behavior-Driven Development. 

Date: 21 November 2019
Time: 4 - 5pm CEST

REGISTER NOW!
 

Watch our previous Webinars:

Nov 01 2019
Nov 01

After three days of some informative and inspiring talks, it was time for contribution day, so everyone got their editors out, put on their documentation hats, and got those issue queues down!

Amazee Labs Contribution Room

On day four, the contribution events started at 9 am, and folks had a few options: the First-Time Contributor Workshop, Mentored Contribution or General Contribution. The DrupalCon Amsterdam website had a handy little flowchart to help people decide which session would be best for them.

DCA Flow Graph Credit: https://events.drupal.org/amsterdam2019/contribution-events DCA

First-Time Contributor Workshop

This was a fully guided workshop, run by Brian Gilbert and Jordana Fung, as an opportunity for people who hadn’t contributed before to get up and running with the drupal.org issue queue and necessary tools needed to contribute. This seemed like a fantastic opportunity for people working with Drupal that may find the idea of contributing overwhelming or if they were unsure where to start. I spoke to someone that attended the workshop and they said the contribution process was broken down well, but unfortunately they ran into issues getting a development environment working (always the hardest bit!) so they didn’t quite get to solving an issue, but they said the slides provided will be an invaluable resource to refer back to and have more confidence with contributing now. What I’ve been hearing throughout the week at DrupalCon was reiterated in this workshop: “Even if you can’t make a patch, you can still contribute!”, which is a great encouragement for non-developers to contribute by other means such as creating translations, updating drupal.org documentation or volunteering at events, and highlights the diverse community.

Mentored Contribution

This session was aimed at those who were already comfortable with the issue queue and contributing, but still wanted some direction from the mentors that kindly gave up their time to guide groups of around eight. The focus was on Drupal core, where attendees were pointed to issues tagged with “Novice”. There had clearly been some good triage and tagging in preparation for the DrupalCon contribution day, as these issues were ready to go and usually had an additional comment to help clarify the issue. I think for a lot of us in this session, it introduced us to a different type of contribution, where we were working on issues that didn’t directly affect us, or our current project, and it felt good! Hopefully, there are some converted Drupal users that might devote some time to working through the core issue queue.

General Contribution

This was for those with clear intentions and a sense of purpose! This session seemed fairly freeform, but tables were grouped by topic e.g. search, Drupal 9, admin UI and frontend. Having previous experience contributing to a project/topic wasn’t necessary, so as long as you had experience with the issue queue, appropriate skills and an interest in a particular topic, you could rock up and chat to others at that table to get working on an appropriate issue.

Out of these options, I chose to join the Mentored Contribution session and immediately after arriving, I was allocated a table and mentor, got a development environment up and running, and we were tasked with working on Drupal core issues. It was helpful to have the mentor on-hand to discuss possible solutions and it felt great to be part of such a big contribution event - imagine how many comments and commits were made that day!

Amazee Labs Team

We also had an Amazee success in the General Contribution session, with Amazee’s own Philipp Melab releasing a stable 3.0 version of the GraphQL Drupal module, so congratulations to Philipp and everyone else who worked hard at the contribution day to get that finished.

I’m looking forward to contributing more outside my project-specific needs after being inspired to at DrupalCon and the contribution day was a great insight into the effort and hours that go into making Drupal what it is.

Oct 31 2019
Oct 31

After a night full of singing Karaoke with the fellow Amazees, the day started a bit slower and later than usual. I made my way down to the lobby to catch a ride to the venue. 

We arrived just in time for the Dries Q&A, where Drupal founder Dries Buytaert answered the communities questions about future plans, roadblocks in the development, and what the challenges are for open source software to compete with licensed software (basically just because those can offer a wider range of toolsets). He also spent a lot of time emphasizing what makes the Drupal community so special.

amazee.io as a Platinum sponsor had a short Amazecapades performance in the exhibit hall at lunchtime. For a change, this session wasn’t filled with facts about Lagoon, tech talk or sales-y lines, instead was short lightning talks and activities with fun life tips. 

amazee.io Michael Open Mic

Michael Schmid shared his secrets to relax and fall asleep fast, which consists of the 4-7-8 breathing method: four seconds in, hold your breath for seven secs and breath out for eight. After that, try just counting down from one hundred. Sounds too simple, right? You should try it, but maybe not at work. ;-) 

Amazee Labs Felix Open Mic

Felix Morgan spoiled movies for everyone (JK) as she explained every single movie follows the exact same dramatic composition at 25%, 50% and 75% through the movie.

amazee.io Nicole Open Mic

Nicole DeAngelis then finished off with a small Yoga session to help loosen the stiff necks and move the body after the long-time sitting in talks.

Completely relaxed, I headed to a very promising Keynote by Sue Black. Her talk was very inspiring, as she went on about how challenges in her life got her to build a successful career out of it. With dedication, passion and education, everyone can achieve their goals.

After this motivating session, we took a short stroll to the park behind the RAI for a quick moment to enjoy the Sun and get some fresh air.

The afternoon was mostly spent with the Amazee team; getting to know each other better and in person. I had a great rap with a lot of folks and also learned about rubber duck debugging as well as actually solving a client issue by implementing it - double success!!! :celebrate:

The end of the conference day concluded with Trivia night. After being in the Drupal community for my second year now, I felt confident enough to join a team and compete for the cool prizes.

Quiz Night

Quiz Night Q&A

Sadly, my input didn’t make the difference as we came in at rank 33 out of at least 50. Nonetheless, it was a lot of fun. Besides the friendly competition, I gained more background knowledge about the CMS and Community in which I’ve been working with for some time now.

All in all, being at a Conference with +/- 1600 like-minded people broadened my horizon about the culture that can stand behind such a framework and how everything clips together within the open source community.

I’m already looking forward to attending next years DrupalCon!

P.S. #thanksdan for supporting my poor blog writing!
 

Oct 30 2019
Oct 30

Let's take a glimpse into the second day of DrupalCon Amsterdam 2019.

We started the day with a short walk from our hotel to the venue while dodging thousands of cyclists during rush hour. Once at the RAI, we promptly entered the auditorium to start the day.

After kickstarting the conference on Monday with the first keynote from the Drupal initiative leads, we now had the delight to savour the “Driesnote” in full on Tuesday morning.

Welcome to DrupalCon
 

Dries announced that the Drupal 9 development branch is available and that 16% of the top 200 modules are already Drupal 9 compatible.

He then pointed out that the future will need to adapt to billions of more internet-enabled devices as the world will gain further access to the internet. Dries mentioned that in the future you need to:

  • Be really good at structured data
  • Manage more diverse data
  • Manage 100x the amount of data
  • Integrate easily with other platforms

What does this mean for the future of Drupal?
 

Looking forward, we’re almost at the end of the track for Drupal 8, so we need to start planning for the next summit. Dries asked us which initiatives should we, as a community, work together on for Drupal 9 and gave us his suggestions.

Group photo

Directly after the informative Driesnote, we were then shepherded outside for the group photo. From the registration desk, I was informed that we have at least 1,400 attendees so it took a few moments before we could all throw our hands up for the official snap.

Before lunch, I caught up with some of the volunteers involved in the Admin UI initiative. I sat and listened to Sascha, Christina, and Archita iron out the last details for their talk on Wednesday. While I began to dip into the Design System on Figma.

Being a Volunteer
 

I find that the best way to experience a conference is to volunteer, therefore I had volunteer duties in which I was a session monitor for two talks held in the G106 room:

  • “Before decoupling, understand JS. JavaScript for Drupalers: Let’s learn this” presented by Ashraf Abed
  • “Storybook and Drupal: Seamless frontend integration for decoupled sites.” presented by Jamie Hollern and Mattia Simonato.

Both talks were at over-capacity with people sitting on the floor as well as standing at the back. I thoroughly enjoyed them.
 

Hallway interviews

A meal with friends
 

Later in the evening, I attended the official Drupal Switzerland dinner which was held at an Italian restaurant near to the conference venue. It was a memorable evening in which people from all across Switzerland as well as friends from Sweden attended to share and enjoy a meal together.

We ended the evening with a party hosted by Pantheon, which continued late into the night. Looking forward to another great day at DrupalCon.
 

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.
 

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