DrupalCamp Lutsk 2017: Impressions from Speed & Function’s Drupal Lead

This month I attended a DrupalCamp in Lutsk in western Ukraine. I would like to share my impressions of the conference.

Typically, the common way to hold Drupal Camps in Ukraine is a bit boring.  I presented there myself and noticed there was little interaction with the audience and not much feedback.

But Slava Merezhko had a great idea, turning his presentation “Let’s resolve a SOW” into a practical seminar. First, the audience was split in several different teams.

Each team developed their vision of the SOW indicating the main points that should be included. Our team decided that our SOW should include expectations, limitations and assumptions. After all the teams finished their SOW vision, Slava told us what we can do in the case of poor project specifications. The main advice proposed by him: ask the client all the obvious and not so obvious questions. I can to add the idea that we have to provide several solutions for each problem so that the client makes the choice. In that way we can delegate a bit of responsibility to the client.

You can see the results of our team on the image below:

But I learned more than Slava’s practice, and walked away with a number of Drupal impressions. The most important take-away was that there were a lot of new faces, many junior level developers taking part in the conference. On the other hand many well known Ukrainian Drupal developers (I won’t mention their names) ignored the event. Maybe they have a lot of projects, maybe they learn some other technologies, I don’t know.

There were many discussions about the future of Drupal. Some people talked about how Drupal is not perceived to be enough by itself so it is packaged together with the other technologies. There were very important roundtable discussion led by Andrii Podanenko and Oleksandr Schedrow about Drupal decoupling. On the one hand Drupal decoupling is the main direction of the Drupal evolution but on the other hand it’s a pain in the ass for developers. Many developers still perceive Drupal as a separate self-sufficient product. Developers are used to using drush and not familiar enough with composer that is now an industrial development standard for php.

In Drupal 8 architecture we have ‘/core’ folder where the Drupal 8 core is located. We have ‘/vendor’ that includes 3rd party libraries and frameworks. Sometimes in real projects the size of ‘/vendor’ folder can be a lot bigger than the size of ‘/core’ folder. The main idea is that the Drupal core can be the same library and it should be moved inside the folder ‘/vendor’. In that case Drupal will be a small part of the other system compiled by composer on the basis of Drupal, Symfony, ZendFramework, etc.

And finally Andrey Postnikov, a famous developer from Russia, spoke about backward compatibility and regression in the Drupal core. The changes in the Drupal API became more significant during the single branch evolution in 8.x branch if we compare it with 7.x or 6.x. Now it is a good practice for the module contributors to follow a version name convention for the Drupal core versions. For example, your module with version 8.4.x should be compatible to Drupal 8.4 API, and if Drupal 8.5 released you have to release 8.5.0 version of your module and remove all elements deprecated in Drupal 8.5 API from your module.

Here’s a photo of the speakers. Yes, I’m in there. I gave a presentation “Folk tale called axe porridge: back side of out-of-the-box solutions”. If you’re curious about my talk, take a look at my presentation slides here

Altogether, it was a great event. Very informational and a great opportunity for experts to come together and learn how to improve.

And at the end of this gathering of tech experts, we were able to nerd out over the history and architecture of this beautiful ancient castle– the location of our very lively afterparty!

Vas Jaremchuk is a Senior Drupal Developer and Drupal Practice Lead at Speed & Function.

* Some photos from were used in this post.